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…