You are not logged in.
Greetings!
As of 30/11/2022 a VM parked on libvirt/qemu stopped booting. The usual TianoCore splash screen did not showed up. Calling snapshots had no effect. Just a black screen and nothing else.
I enabled libvirt logging and no error message appeared. So I gave up and took the rest of the day to rebuilt the Windows 10 VM which I use professionally.
Reading through pacman's logs I found an update for edk2-ovmf
[2022-11-26T15:21:07-0300] [ALPM] upgraded edk2-ovmf (202208-1 -> 202208-3)
Did some research and found that an update to this code can really be the cause although the VM survived two previous updates on august/2022. Built this VM on july.
Can you advise if placing edk2-ovmf into pacman.conf IgnorePkg is a wise decision? As far as I can see just qemu is depending on this package.
Thank you!
Last edited by alex.gt (2022-12-10 23:28:04)
Offline
I'm going to quote a post I made on a similar thread, hoping that it can help you as well.
I had this same issue a while ago and I eventually found my way to this thread on libvirt's gitlab, which also links to two arch bug reports here and here. What I found worked for me was following the instructions of this particular comment.
Offline
PutridPete, thank you so much! It was valuable information. I'm in need to hone my search skills.
Offline
I'm glad it helped. Remember to mark your thread as [SOLVED] if you managed to fix your issue with this information, and perhaps let us know exactly what worked for you.
Last edited by PutridPete (2022-12-11 04:02:54)
Offline
After spending some hours trying to understand the topics presented, thanks to @PutridPete, I concluded that it would be better to handicraft the VM configuration and give the next edk2-ovmf update a try.
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.
Changed from
<os firmware="efi">
<type arch="x86_64" machine="pc-q35-7.1">hvm</type>
</os>
to
<os>
<type arch="x86_64" machine="pc-q35-7.1">hvm</type>
<loader readonly='yes' type='pflash'>/usr/share/edk2-ovmf/x64/OVMF_CODE.4m.fd</loader>
<nvram type='file' template='/usr/share/edk2-ovmf/x64/OVMF_VARS.4m.fd'>
<source file='/var/lib/libvirt/qemu/nvram/win10segunda_VARS.fd'/>
</nvram>
</os>
Since I've erased the former VM, the only thing to say is that the new one still works as expected after the shown changes.
Just a final note, file win10segunda_VARS.fd were in the shown path just before the study so it was created by libvirt / qemu on their own. Sum of the sizes of both files gives us exactly 4 MiB. I don't know for sure if the firmware picked (OVMF_CODE.4m.fd) was the best for the case but it suited very well considering the plane was already flying.
Offline