Description of problem:
Cannot install a guest using UEFI bios.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Fresh Install Fedora 32 (rawhide) Server
2. dnf install @virtualization
virt-install --name f31-uefi \
--ram 2048 --disk size=10 \
--boot uefi \
ERROR operation failed: unable to find any master var store for loader: /usr/share/edk2/ovmf/OVMF_CODE.fd
Removing disk 'f31-uefi.qcow2' | 0 B 00:00:00
Domain installation does not appear to have been successful.
Guest installation OK
using virt-manager having the same error
Hi, thanks for the report. The issue is in libvirt where we introduced firmware autoselection feature which broke this old way of specifying UEFI firmwares that virt-install currently uses. Moving to libvirt to get it fixed there.
Patches proposed on the upstream list:
Proposed as a Blocker for 32-beta by Fedora user chrismurphy using the blocker tracking app because:
"The release must be able host virtual guest instances of the same release.
What does that mean? This rather concise criterion means effectively means that both virtual host and virtual guest functionality must work - it's implied, if you think about it. It also means that there must be no showstopper bugs in the installer when installing to a virtual machine..."
There isn't an explicit UEFI release criterion, but I think it's implied (?) just because we've got openQA tests that depend on it, and at this point it's basic enough I think it's fair to say such breakage should be blocked on until fixed.
Adam Williamson points out Basic Criterion most likely applies here:
"All release-blocking images must boot in their supported configurations." And this has an expanded clarification that includes UEFI.
Patches mentioned in comment 4 are for qemu, should the bug component be changed to qemu so this can get fixed?
(In reply to Chris Murphy from comment #7)
> Patches mentioned in comment 4 are for qemu, should the bug component be
> changed to qemu so this can get fixed?
I don't think they are meant for qemu. They were sent to the libvirt list. True, they mention qemu but that doesn't mean they are meant for qemu. Libvirt is the right component.
In fact, I've sent v2:
I've pushed patches upstream:
8e1804f9f6 qemu_firmware: Try to autofill for old style UEFI specification
7c5264d2be src: Introduce and use virDomainDefHasOldStyleUEFI() and virDomainDefHasOldStyleROUEFI()
57f9067ca3 qemu_firmware: Introduce @want variable to qemuFirmwareMatchDomain()
50d7465f3d qemu_firmware: Pass virDomainDef into qemuFirmwareFillDomain()
The root issue is in f31 libvirt packages, but it was only exposed by:
Author: Jim Fehlig <email@example.com>
Date: Thu Nov 14 09:06:43 2019 -0700
spec: Remove build-time list of edk2 firmwares
Which is not in f31, so things work fine there.
rawhide will be fixed in a few days when libvirt 6.0.0 is out
This is fixed on aarch64 with libvirt-6.0.0-1.fc32
UEFI VMs are working for me.