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…