On 10/12/20 10:52 PM, daggs wrote:
Greetings,
I have the following machine:
https://dpaste.com/5BPA3F77F which I'm trying to boot
in uefi.
/etc/libvirt/qemu.conf looks like this:
https://dpaste.com/B3SFHUY6R and the ovmf files
exists in the path, see:
# ll /usr/share/edk2-ovmf/OVMF_CODE.fd /usr/share/edk2-ovmf/OVMF_VARS.fd
/usr/share/edk2-ovmf/OVMF_CODE.secboot.fd /usr/share/edk2-ovmf/OVMF_VARS.secboot.fd
-rw-r--r-- 1 root root 1966080 Aug 21 14:32 /usr/share/edk2-ovmf/OVMF_CODE.fd
-rw-r--r-- 1 root root 1966080 Aug 21 14:32 /usr/share/edk2-ovmf/OVMF_CODE.secboot.fd
-rw-r--r-- 1 root root 131072 Aug 21 14:32 /usr/share/edk2-ovmf/OVMF_VARS.fd
-rw-r--r-- 1 root root 131072 Aug 21 14:32 /usr/share/edk2-ovmf/OVMF_VARS.secboot.fd
when I try to start the machine, I get this error:
error: Failed to start domain vm1
error: operation failed: unable to find any master var store for loader:
/usr/share/edk2-ovmf/OVMF_CODE.fd
libvirt version is 6.7.0 and qemu version is 5.1.0
any idea how to fix this issue?
Hey,
I'll paste the interesting part of domain XML here so that it doesn't
get lost:
<os>
<type arch='x86_64' machine='pc-q35-5.0'>hvm</type>
<loader readonly='yes'
type='pflash'>/usr/share/edk2-ovmf/OVMF_CODE.fd</loader>
<nvram>/var/lib/libvirt/qemu/nvram/vm1_VARS.fd</nvram>
<boot dev='hd'/>
</os>
And then in qemu.conf you define the pair:
nvram = [
"/usr/share/edk2-ovmf/OVMF_CODE.fd:/usr/share/edk2-ovmf/OVMF_VARS.fd",
"/usr/share/edk2-ovmf/OVMF_CODE.secboot.fd:/usr/share/edk2-ovmf/OVMF_VARS.secboot.fd"
]
But as the comment in qemu.conf (just above your line) says, this is
ignored if FW metadata files exist which is exactly your case and this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1763477
For your convenience you can switch to <os firmware='efi'/> (the
<loader/> element will be removed automatically) or if you insist on
using the old style then provide @template attribute to <nvram/>:
<nvram
template="/usr/share/edk2-ovmf/OVMF_CODE.fd">/var/lib/libvirt/qemu/nvram/vm1_VARS.fd</nvram>
There is an internal list that is still consulted when finding matching
_VARS fails, but your path is not on it:
https://gitlab.com/libvirt/libvirt/-/blob/master/src/qemu/qemu_conf.c#L98
But it exists mostly to give distros enough time to switch to FW
descriptors.
Michal