with pkgs: - app-emulation/qemu-4.2.0-r1 - app-emulation/libvirt-6.0.0-r1 - app-emulation/virt-manager-2.2.1-r1 run: virt-install --connect qemu:///system --print-xml --boot uefi got: ERROR Did not find any UEFI binary path for arch 'x86_64' info: . qemu seems to have installed edk2-ovmf firmware correctly .... /usr/share/qemu/edk2-i386-vars.fd /usr/share/qemu/edk2-x86_64-code.fd /usr/share/qemu/edk2-x86_64-secure-code.fd /usr/share/qemu/firmware/50-edk2-x86_64-secure.json /usr/share/qemu/firmware/60-edk2-x86_64.json .... . virt-install use a different name schema to match the firmware: in /usr/share/virt-manager/virtinst/domcapabilities.py: uefi_arch_patterns use *ovmf* rather than *edk2* that qemu used 177 _uefi_arch_patterns = { 178 "i686": [ 179 r".*ovmf-ia32.*", # fedora, gerd's firmware repo 180 ], 181 "x86_64": [ 182 r".*OVMF_CODE\.fd", # RHEL 183 r".*ovmf-x64/OVMF.*\.fd", # gerd's firmware repo 184 r".*ovmf-x86_64-.*", # SUSE 185 r".*ovmf.*", ".*OVMF.*", # generic attempt at a catchall 186 ], 187 "aarch64": [ 188 r".*AAVMF_CODE\.fd", # RHEL 189 r".*aarch64/QEMU_EFI.*", # gerd's firmware repo 190 r".*aarch64.*", # generic attempt at a catchall 191 ], 192 "armv7l": [ 193 r".*arm/QEMU_EFI.*", # fedora, gerd's firmware repo 194 ], 195 } Reproducible: Always
It should be note that the recommend UEFI setup, as said in virt-install manual page, is to declare the params explicitly, which is much more reliable. .... --boot loader=$OVMF_CODE,nvram.template=$OVMF_VARS,loader.readonly=yes,loader.type=pflash,loader_secure=no ....
Created attachment 683305 [details] virt-manager log I hit the same problem. libvirt fails to see the edk2 firmware installed by QEMU. I'm unable to use the virt-manager's wizard to create a new UEFI VM.
anton@PF16W6Y2 ~ $ equery f qemu|grep edk /usr/share/qemu/edk2-aarch64-code.fd /usr/share/qemu/edk2-arm-code.fd /usr/share/qemu/edk2-arm-vars.fd /usr/share/qemu/edk2-i386-code.fd /usr/share/qemu/edk2-i386-secure-code.fd /usr/share/qemu/edk2-i386-vars.fd /usr/share/qemu/edk2-licenses.txt /usr/share/qemu/edk2-x86_64-code.fd /usr/share/qemu/edk2-x86_64-secure-code.fd /usr/share/qemu/firmware/50-edk2-i386-secure.json /usr/share/qemu/firmware/50-edk2-x86_64-secure.json /usr/share/qemu/firmware/60-edk2-aarch64.json /usr/share/qemu/firmware/60-edk2-arm.json /usr/share/qemu/firmware/60-edk2-i386.json /usr/share/qemu/firmware/60-edk2-x86_64.json
As of libvirt-7.0.0 and qemu-5.2.0-r1 there is a mismatch about the paths to edk2-ovmf files The json files indicate the location of the file without the /usr prefix: { "description": "UEFI firmware for x86_64", "interface-types": [ "uefi" ], "mapping": { "device": "flash", "executable": { "filename": "share/qemu/edk2-x86_64-code.fd", "format": "raw" }, "nvram-template": { "filename": "share/qemu/edk2-i386-vars.fd", "format": "raw" and this leads to libvirt not seeing these files. Once I change these to { "description": "UEFI firmware for x86_64", "interface-types": [ "uefi" ], "mapping": { "device": "flash", "executable": { "filename": "/usr/share/qemu/edk2-x86_64-code.fd", "format": "raw" }, "nvram-template": { "filename": "/usr/share/qemu/edk2-i386-vars.fd", "format": "raw" the loaders become visible in livirt, however the new VM creation procedure doesn't put the <nvram template="/usr/share/qemu/edk2-i386-vars.fd">/var/lib/libvirt/qemu/nvram/guest_VARS.fd</nvram> into the VM's <os> section resulting in failed VM startup. Adding <nvram> tag manually during every VM creation works around the problem.
I'm on libvirt-6.8.0-r2 which is stable and I have the same issue. virt-manager does not see any UEFI firmware.
-libvirt-6.8.0-r2 -qemu-5.2.0-r1 -edk2-ovmf-201905 -virt-manager-3.10 Like Anton, I had to add /usr/ to the beginning of the file names in the json files for them to show up. However, virt-manager did add the nvram tag when creating a VM.
The same here, I had to modify the json files at "/usr/share/qemu/firmware/" in order to add "/usr/" to the firmware images paths; after that and a libvirtd restart, uefi was detected by virt-manager. Best regards.
This was a bug in qemu and is fixed in 5.2.0-r2, can you please test again?
I confirm qemu-5.2.0-r3 works for me.
as the issue seems to be resolved at the time, I'll close it