Public bug reported: 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 ** Affects: linux (Ubuntu) Importance: Undecided Status: New -- 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: New 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
