Arch Linux

@rgfx81wcc2, please see  FS#76238 . You'll probably need to fiddle with "*_VARS.fd" as mentioned by @hardfalcon. Can you give it a try?

This 202208-2 pkg is still lingering in [testing], possibly because it breaks existing setups. I don't know if it's possible to ensure a smooth upgrade without manual intervention.

@Toolybird

Thank you, can confirm the second solution (b) (https://bugs.archlinux.org/task/76238#comment212141) fixes the issue in my case with edk2-ovmf 202208-2.

Thanks for confirming. So the current situation appears to be as follows:

With recent libvirt based VM's you can have either "firmware auto-selection" or older style manual path based selection [1].

If setting up a new VM with virt-manager and you simply choose "UEFI", you end up with auto-selection which equates to:

<os firmware="efi">
<...>
</os>

If you choose an actual path based firmware, you end up with for example:

<os>
<...>
<loader readonly="yes" secure="yes" type="pflash">/usr/share/edk2-ovmf/x64/OVMF_CODE.secboot.fd</loader>
<nvram>/var/lib/libvirt/qemu/nvram/my-vm_VARS.fd</nvram>
</os>

It seems to me those VM's with "firmware auto-selection" will be the ones that are most likely to have boot failure with the new edk2-ovmf pkg. If this is true then maybe an Arch front page news item might be warranted? Dunno.

[1] https://libvirt.org/formatdomain.html#operating-system-booting

Ok, just confirming my hypothesis above is correct. After upgrading to edk2-ovmf-202208-3, some of my VM's no longer boot :(

In particular, it's only the ones that employ "firmware auto-selection" that have issue. I'm surprised more folks have not come forward with problems. Maybe I'm one of the few crazy persons who have set up VM's with EFI auto-selection... Luckily, it's quite easy to fix as outlined above.

Can you check whether this is still an issue with 202211-2 in [testing]?

@Toolybird The default should still be 2MB files. We've added additional files, that use 4MB though.

Meh, I just now saw that there's a little bug: /usr/share/edk2-ovmf/x64/MICROVM.4m.fd/MICROVM.fd should be /usr/share/edk2-ovmf/x64/MICROVM.4m.fd

I believe I am affected by the same issue, I just upgraded to edk2-ovmf-202208-3 and my three Debian VMs that I created with firmware auto-selection all failed to boot or display anything. An older Arch Linux VM that had manual firmware definitions booted successfully. Changing the firmware selection on the three problematic VMs to the older style selection lets them boot successfully, as well as autostart successfully on full host reboot. Downgrading to edk2-ovmf-202208-1 lets me use auto-selection.

Old XML of one VM:
<os firmware='efi'>
<type arch='x86_64' machine='pc-q35-7.1'>hvm</type>
<boot dev='hd'/>
</os>

Changing it to the following allowed me to workaround the issue:
<os>
<type arch='x86_64' machine='pc-q35-7.1'>hvm</type>
<loader readonly='yes' secure='no' type='pflash'>/usr/share/edk2-ovmf/x64/OVMF_CODE.fd</loader>
<nvram>/var/lib/libvirt/qemu/nvram/sev-bas-005_VARS.fd</nvram>
<boot dev='hd'/>
</os>

I struggle to understand why that would happen.
Does "firmware auto-selection" now just select the 4MB files by default?

@dvzrv, yes, that is the crux of the issue. I'm not sure how libvirt decides the ordering but it could be a simple lexicographical order. i.e:

50-edk2-ovmf-x86_64-secure-4m.json
50-edk2-ovmf-x86_64-secure.json

PS - here's another upstream report from an Arch user with more info [1]

[1] https://gitlab.com/libvirt/libvirt/-/issues/410

Okay, thanks. I have also commented there.

@dvzrv, on second thoughts, another option is we just do nothing and leave it as is. The fallout hasn't been as bad as feared, and in actual fact this has come up before in  FS#57825 .

There is also an existing Wiki entry [1] from last time this happened. It just needs a minor touch-up to make it current (any takers?)

Any new VM's created from this point onward (employing the auto-selection) will get the 4M file and that's probably a good thing. But a key difference from last time this happened is we are still shipping the 2M files. Ditching the 2M files some time in the future will cause similar issues.

Options to fix non-booting VM's (as long as nothing important is in the virtual NVRAM like manually enrolled secure boot keys, etc):
1. rm the VM's *_VARS.fd in /var/lib/libvirt/qemu/nvram/
2. pass '--reset-nvram' flag to 'virsh start ...'
3. switch to path based firmware in the VM's XML (i.e. 'virsh edit ...' the XML)

[1] https://wiki.archlinux.org/title/PCI_passthrough_via_OVMF#Cannot_boot_after_upgrading_ovmf

Dupe  FS#76732   FS#76760 

A few remarks for the naive, like me.
Don't rm your VARS.fd files: back them up somewhere first.
To get rid of "auto-selection" change <os firmware='efi'> to <os> Otherwise you can't put in a manual path into the XML

Not sure about this part:

You can't, or rather I couldn't, pick a 4m OVMF_CODE file to replace the 2m version. The VM will refuse to start even with --reset-nvram with this message:
error: operation failed: unable to find any master var store for loader: /usr/share/edk2-ovmf/x64/OVMF_CODE.secboot.4m.fd
This is where saving your old VARS file comes in handy

I don't think there is anything actionable here for me and I'd rather close this ticket now.