A few more observations below. Running the file command on both gives us:
linux/arch/arm64/boot$ file Image.gz Image.gz: gzip compressed data, max compression, from Unix, original size modulo 2^32 63220224 linux/arch/arm64/boot$ file vmlinuz.efi vmlinuz.efi: PE32+ executable (EFI application) Aarch64 (stripped to external PDB), for MS Windows, 2 sections This change does not change the binary size: -rw-r--r-- 1 user ubuntu 19M Feb 18 12:34 Image.gz -rwxr-xr-x 1 user ubuntu 19M Feb 16 16:16 vmlinuz.efi Compared to the uncompressed image: -rw-r--r-- 1 user ubuntu 61M Feb 16 16:16 Image As described in the initial report, Image.gz compresses the whole binary, vmlinuz.efi only compresses the payload to be decompressed by the stub. The stub code size is negligible so they are roughly the same size. Heinrich mentioned that there was a similar with Risc-V kernels in the past where they tried to run the kernel directly from u-boot EFI. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2098111 Title: arm64: kernel image cannot be booted in UEFI despite EFI stub and ZBOOT Status in linux package in Ubuntu: Confirmed Bug description: The arm64 kernel image enables the EFI stub and ZBOOT options, among others, that should allow booting the kernel in a UEFI environment, as a signed PE binary. But the package ships the kernel image as a compressed gzip file, which UEFI cannot understand. I received a suggestion that this is down to having CONFIG_EFI_ZBOOT enabled but running "make install" instead of "make zinstall" (which is am arm specific thing and would do the right thing) at package build time, with some reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4c7be57f2772c8ce4e1e43c6a79b8f8d401a4795 The vmlinuz in https://ports.ubuntu.com/pool/main/l/linux- signed/linux-image-6.12.0-15-generic_6.12.0-15.15_arm64.deb $ file vmlinuz-6.12.0-15-generic vmlinuz-6.12.0-15-generic: gzip compressed data, max compression, from Unix, original size modulo 2^32 60844424 $ sbverify --list vmlinuz-6.12.0-15-generic Invalid DOS header magic Can't open image vmlinuz-6.12.0-15-generic After using gunzip on it: $ gunzip < vmlinuz-6.12.0-15-generic > unzip $ file unzip unzip: Linux kernel ARM64 boot executable Image, little-endian, 4K pages $ sbverify --list unzip signature 1 image signature issuers: - /C=GB/ST=Isle of Man/L=Douglas/O=Canonical Ltd./CN=Canonical Ltd. Master Certificate Authority image signature certificates: - subject: /C=GB/ST=Isle of Man/O=Canonical Ltd./OU=Secure Boot/CN=Canonical Ltd. Secure Boot Signing (2022 v1) issuer: /C=GB/ST=Isle of Man/L=Douglas/O=Canonical Ltd./CN=Canonical Ltd. Master Certificate Authority On the other hand, a Debian arm64 kernel: $ file vmlinuz-6.12.13-arm64 vmlinuz-6.12.13-arm64: Linux kernel ARM64 boot executable Image, little-endian, 4K pages $ sbverify --list vmlinuz-6.12.13-arm64 signature 1 image signature issuers: - /CN=Debian Secure Boot CA image signature certificates: - subject: /CN=Debian Secure Boot Signer 2022 - linux issuer: /CN=Debian Secure Boot CA Fedora: $ file vmlinuz vmlinuz: PE32+ executable (EFI application) Aarch64 (stripped to external PDB), for MS Windows, 2 sections I noticed this because I maintain the mkosi package in Debian, and I recently added autopkgtest, which is failing in Ubuntu Plucky: https://autopkgtest.ubuntu.com/results/autopkgtest- plucky/plucky/arm64/m/mkosi/20250212_040016_2ebac@/log.gz The autopkgtest uses mkosi to build a UKI using the kernel package, and boot it with EDK2 + systemd-boot, and fails because the kernel format is not recognized. Autopkgtest script: https://salsa.debian.org/systemd- team/mkosi/-/blob/debian/sid/debian/tests/mkosi?ref_type=heads To reproduce the failure with autopkgtest on x86-64: $ autopkgtest-buildvm-ubuntu-cloud -a arm64 -r plucky --timeout 7200 <wait for image to be built> $ autopkgtest -s --pin-packages=plucky-proposed=mkosi --add-apt-source='deb http://ports.ubuntu.com plucky-proposed main universe' --timeout-factor=1000 mkosi -B --test-name mkosi -- autopkgtest-virt-qemu --cpus 4 --ram-size 4096 ./autopkgtest-plucky-arm64.img --qemu-architecture=aarch64 --timeout-reboot 9000 This will fail with: BdsDxe: starting Boot0001 "UEFI Misc Device" from PciRoot(0x0)/Pci(0x8,0x0) ../src/boot/linux.c:120@linux_exec: Bad kernel image: Load error ../src/boot/boot.c:2640@image_start: Failed to execute Ubuntu Plucky Puffin (development branch) (\EFI\Linux\ubuntu-6.12.0-15-generic.efi): Load error To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2098111/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
