XPost: linux.debian.ports.arm
Package: qemu-efi-aarch64
Version: 2025.02-4
Severity: important
X-Debbugs-Cc:
debian-arm@lists.debian.org,
noisycoil@tutanota.com
User:
debian-arm@lists.debian.org
Usertags: arm64
Dear Maintainer,
You were right in #1099500, my bug has nothing to do with ovmf. After further digging I found out the underlying cause of my issue is qemu-system-aarch64 being unable to directly boot a Debian kernel with the qemu-efi-aarch64 2025.02 firmware (tested with 2025.02-3, but 2025.02-4 mostly introduces doc changes so I'm flagging the latter). What does not work for me is the following:
```
dd if=/usr/share/qemu-efi-aarch64/QEMU_EFI.fd of=vars.fd conv=notrunc
truncate -s 64m vars.fd
qemu-system-aarch64 -enable-kvm -machine virt -cpu host -m 512 -drive if=pflash,format=raw,file=/usr/share/AAVMF/AAVMF_CODE.fd,readonly -drive if=pflash,format=raw,file=vars.fd -kernel kernel -serial stdio
```
Here the `kernel` file passed as argument to the `-kernel` option is the arm64 kernel binary currently in experimental, obtained by downloading and unpacking linux-image-6.13-arm64 (but I also tested linux-image-6.12.19-arm64). The console just remains stuck at the EDK II shell:
```
UEFI Interactive Shell v2.2
EDK II
UEFI v2.70 (Debian distribution of EDK II, 0x00010000)
map: No mapping found.
Press ESC in 1 seconds to skip startup.nsh or any other key to continue.
Shell>
```
Version 2024.11-5, by converse, is able to boot the kernel using the command line above. Moreover, qemu-system-aarch64 is able to boot the kernel without the qemu-efi-aarch64 firmware (i.e. by removing the two pflash drives above). In both cases the kernel obviously panics immediately in the absence of a root, but kernel logs start showing nonetheless.
For context, I came across this while using libguestfs. I am running a test suite
which uses ruby-guestfs to set up some disks in a VM before actually booting it,
and tracing the commands it's using under the hood lead me to the minimal reproducer above. On the other hand (despite my claim in Bug#1099500), booting an image with arm64 unsigned grub on the removable path does seem to work. Previously I had not realized the boot failure happened during the preparatory phases of testing driven by libguestfs.
Cheers!
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: arm64 (aarch64)
Kernel: Linux 6.13.7-asahi (SMP w/8 CPU threads)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
qemu-efi-aarch64 depends on no packages.
qemu-efi-aarch64 recommends no packages.
Versions of packages qemu-efi-aarch64 suggests:
ii qemu-system-arm 1:9.2.2+ds-1+b1
-- no debconf information
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)