FS#57825 - [ovmf] 2MB firmware size causes existing VM not to boot
Attached to Project:
Arch Linux
Opened by Jolan Luff (jolan) - Tuesday, 13 March 2018, 15:05 GMT
Last edited by Anatol Pomozov (anatolik) - Sunday, 08 March 2020, 02:33 GMT
Opened by Jolan Luff (jolan) - Tuesday, 13 March 2018, 15:05 GMT
Last edited by Anatol Pomozov (anatolik) - Sunday, 08 March 2020, 02:33 GMT
|
Details
Description:
Hi, I have a Windows 10 guest that no longer boots after upgrading from ovmf-1:r23112.018432f0ce-1 to ovmf-1:r23518.6d2d2e6e5b-1. Additional info: libvirt 4.0.0-1 linux 4.15.8-1 qemu 2.11.1-2 virt-manager 1.5.1-1 Steps to reproduce: I simply upgraded ovmf and then tried to start up my Windows 10 64-bit VM. The TianoCore splash screen is never reached and the load reported by virt-manager stays constant rather than the normal peaks and valleys of a loading VM. I was unable to trigger a clean shutdown as well. Upgrading ovmf to a newer revision didn't help. Reverting to ovmf-1:r23112.018432f0ce-1 worked. Staying on revision 6d2d2e6e5b and reverting the 2MB change also worked. Is some sort of migration step needed? I haven't been able to find a reference for '2MB firmware size required by QEMU'. |
This task depends upon
if (bios_size <= 0 ||
(bios_size % 65536) != 0) {
goto bios_error;
}
https://github.com/qemu/qemu/blob/master/hw/i386/pc_sysfw.c#L193
The expected file size is multiple of 64KiB.
The flag you mentioned also presents in other distros e.g. Fedora
https://src.fedoraproject.org/rpms/edk2/blob/master/f/edk2.spec#_227
Out of curiosity if you try to copy Fedora's OVMF files, do you still experience problems with Windows booting? http://rpmfind.net/linux/rpm2html/search.php?query=edk2-ovmf
I tried ovmf-1:r23518.6d2d2e6e5b-1-any.pkg.tar.xz with a newly created Windows 10 VM and was able to boot the install media. I then re-tried my existing Windows 10 instance and it still doesn't boot.
I believe I've located the problem. There's some UEFI->NVRAM mapping. In /var/lib/libvirt/qemu/nvram, I see two files:
131072 Mar 13 14:03 win10-2_VARS.fd
540672 Mar 13 13:21 win10_VARS.fd
I renamed win10_VARS.fd to win10_VARS.fd.old and was able to boot my existing VM with 23518.6d2d2e6e5b-1. I guess it was just a mismatch between the two that was causing an error somewhere.
EDIT: Should also mention that I didn't notice any ill effects upon doing so.
I don't see any mismatched vars as Jolan found, and deleting everything in /var/lib/libvirt/qemu/nvram didn't help either.
I can boot again by downgrading to ovmf-1:r23112.018432f0ce-1 or using the method from jolan with ovmf-1:r23518.6d2d2e6e5b-1.