Solution: OVMF 4M-based VMs broken after updating to F39 - users - Fedora mailing-lists

10 Nov 2023


      I had an EFI VM that was configured to use
/usr/share/edk2/ovmf-4m/OVMF_CODE.secboot.fd as its bootloader in F38.
The edk2-ovmf package in F39 no longer installs it. This results in an error  
message starting any VM that uses OVMF 4M images.
The /usr/share/edk2/ovmf-4m directory no longer exists, and  
/usr/share/edk2/ovmf had the following contents in F39:
-rw-r--r--. 1 root root 3678208 Oct 10 20:00 OVMF_CODE_4M.qcow2
-rw-r--r--. 1 root root    1484 Oct 10 20:00 OVMF_CODE_4M.secboot.pcr
-rw-r--r--. 1 root root 3678208 Oct 10 20:00 OVMF_CODE_4M.secboot.qcow2
There was nothing with "4M" and ".fd" in it,
So, I manually edited the XML VM config, but neither  
OVMF_CODE_4M.secboot.qcow2 nor OVMF_CODE_4M.secboot.pcr worked. Attempting  
to boot OVMF_CODE_4M.secboot.qcow2 appeared to be the most promising  
approach except that it failed with a cryptic error message referencing  
qcow2 format and the flash file.
My existing flash file was:
/var/lib/libvirt/qemu/nvram/WINDOWS10-EFI_VARS.fd
After doing some digging I found the solution:
qemu-img convert -f raw -O qcow2 WINDOWS10-EFI_VARS.fd WINDOWS10-EFI_VARS.qcow2
This converted the emulated nvram storage file, apparently, from raw block  
format to qcow2. With that, the VM started successfully. For reference, my  
final settings were:
<loader readonly="yes" secure="yes" type="pflash"  
format="qcow2">/usr/share/edk2/ovmf/OVMF_CODE_4M.secboot.qcow2</loader>
    <nvram template="/usr/share/edk2/ovmf/OVMF_VARS_4M.secboot.qcow2"  
format="qcow2">/var/lib/libvirt/qemu/nvram/WINDOWS10-EFI_VARS.qcow2</nvram>
There used to be release notes packaged with each release that were called  
"Common F# bugs", or something like that. They listed common upgrade issues.  
Not sure where it is these days, a brief search didn't find them. This  
should be mentioned there, wherever it is…