On Wed, 2025-04-23 at 22:01 -0600, dann frazier wrote: > > Please see NEWS.Debian: > https://salsa.debian.org/qemu-team/edk2/-/blob/08d4411d458eefc4df5d48acce4f995d4ae6087d/debian/qemu-efi-aarch64.NEWS
Thanks for pointing that out; since the NEWS entry is specific to arm64 it hadn't popped up as something important to me when that update came through on my various amd64 systems. Would it be possible to roll this back for the trixie release, then re-enable it early in forky development? The set of affected VM images is unknown, and since they're older most likely it wouldn't be feasible to backport whatever changes are needed to fix their bootloaders. The alternative is trying to update all the software launching VMs to automagically detect and then modify the qemu arguments. That seems like a fragile approach and unlikely to complete before the hard freeze starts. If this change remains, I expect a lot of people will be caught by surprise when they update to trixie, which will result in a long tail of bugs and the need for individuals to manually apply configuration changes to fix their VMs. Reverting the change and applying it early in forky would give a full development cycle to absorb the change, and then by release bookworm VMs would be oldoldstable. For some broader context, I did a quick search to see how other distros/packagers are handling this. Ubuntu hasn't yet pulled in the updated src:edk2 with the removal. As best as I can tell, Fedora appears to have that workaround still enabled[0]. Lastly, the Zabbly- provided packaging of Incus also carries that patch[1]. Mathias [0] -- https://src.fedoraproject.org/rpms/edk2/blob/rawhide/f/edk2-build.fedora#_58 [1] -- https://github.com/zabbly/incus/blob/daily/patches/edk2-0005-Revert-ArmVirtPkg-make-EFI_LOADER_DATA-non-executabl.patch
signature.asc
Description: This is a digitally signed message part
