Package: qemu-efi-aarch64 Version: 2025.02-4 Severity: important X-Debbugs-Cc: debian-...@lists.debian.org, noisyc...@tutanota.com User: debian-...@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
