FS#76466 - [edk2-ovmf] 202208-2 "guest has not initialized the display (yet)" in virt-manager

Attached to Project: Arch Linux
Opened by John Doe (rgfx81wcc2) - Monday, 07 November 2022, 10:01 GMT
Last edited by Toolybird (Toolybird) - Saturday, 02 September 2023, 22:51 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To Anatol Pomozov (anatolik)
David Runge (dvzrv)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No


I have an Arch Linux VM in virt-manager. After updating edk2-ovmf to 202208-2, when starting the VM, all I get is a black screen with the following message: "guest has not initialized the display (yet)"

Downgrading edk2-ovmf to 202208-1 solves the issue.

Attached the VM xml content from virt-manager.
This task depends upon

Closed by  Toolybird (Toolybird)
Saturday, 02 September 2023, 22:51 GMT
Reason for closing:  None
Additional comments about closing:  Affected folks should use the workarounds detailed in the comments.
Comment by Toolybird (Toolybird) - Monday, 07 November 2022, 22:13 GMT
@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.
Comment by John Doe (rgfx81wcc2) - Monday, 07 November 2022, 22:29 GMT

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.
Comment by Toolybird (Toolybird) - Tuesday, 08 November 2022, 00:24 GMT
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">

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

<loader readonly="yes" secure="yes" type="pflash">/usr/share/edk2-ovmf/x64/OVMF_CODE.secboot.fd</loader>

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
Comment by Toolybird (Toolybird) - Tuesday, 22 November 2022, 07:50 GMT
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.
Comment by David Runge (dvzrv) - Sunday, 27 November 2022, 16:36 GMT
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
Comment by Terry (Terry-512) - Sunday, 27 November 2022, 19:04 GMT
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'/>

Changing it to the following allowed me to workaround the issue:
<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>
<boot dev='hd'/>
Comment by David Runge (dvzrv) - Sunday, 27 November 2022, 20:59 GMT
I struggle to understand why that would happen.
Does "firmware auto-selection" now just select the 4MB files by default?
Comment by Toolybird (Toolybird) - Sunday, 27 November 2022, 21:21 GMT
@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:


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

[1] https://gitlab.com/libvirt/libvirt/-/issues/410
Comment by David Runge (dvzrv) - Sunday, 27 November 2022, 21:52 GMT
Okay, thanks. I have also commented there.
Comment by Toolybird (Toolybird) - Monday, 28 November 2022, 05:55 GMT
@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
Comment by Toolybird (Toolybird) - Saturday, 03 December 2022, 22:23 GMT
Dupe  FS#76732   FS#76760 
Comment by A de Beus (mostlyharmless) - Saturday, 03 December 2022, 23:21 GMT
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
Comment by David Runge (dvzrv) - Saturday, 02 September 2023, 13:43 GMT
I don't think there is anything actionable here for me and I'd rather close this ticket now.