Hello, We have found the same issue in Ubuntu, which we fixed by reverting some upstream commits.
Upstream bug report here: https://github.com/tianocore/edk2/issues/10881 Ubuntu upload here: https://launchpad.net/ubuntu/+source/edk2/2025.02-3ubuntu1 Mate Kukri On Mon, Mar 24, 2025 at 12:39 AM NoisyCoil <noisyc...@tutanota.com> wrote: > > 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 >
