Re: unable to find any master var store for loader error

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/13/20 2:25 PM, daggs wrote:
Greetings Michal,

Sent: Tuesday, October 13, 2020 at 2:51 PM
From: "Michal Privoznik" <mprivozn@xxxxxxxxxx>
To: "daggs" <daggs@xxxxxxx>, libvirt-users@xxxxxxxxxx
Subject: Re: unable to find any master var store for loader error

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



thanks for the detailed explanation, I wanted to be sure I understand. the following is needed to be done:
1. replace this:
<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>
to this:
<os firmware='efi'/>
   <type arch='x86_64' machine='pc-q35-5.0'>hvm</type>
   <boot dev='hd'/>
</os>

Here, nvram will be generated, but if you want some other path than libvirt would generate you can provide it under <nvram/>. Yes. But you're using the default path anyway.

2. patch qemu_conf.c to include the custom paths of my fd files?


There is a third option. Save the following under /etc/qemu/firmware/50-my-ovmf.json:

{
    "description": "UEFI firmware for x86_64",
    "interface-types": [
        "uefi"
    ],
    "mapping": {
        "device": "flash",
        "executable": {
            "filename": "/usr/share/edk2-ovmf/OVMF_CODE.fd",
            "format": "raw"
        },
        "nvram-template": {
            "filename": "/usr/share/edk2-ovmf/OVMF_VARS.fd",
            "format": "raw"
        }
    },
    "targets": [
        {
            "architecture": "x86_64",
            "machines": [
                "pc-i440fx-*",
                "pc-q35-*"
            ]
        }
    ],
    "features": [
        "acpi-s3",
        "amd-sev",
        "verbose-dynamic"
    ],
    "tags": [

    ]
}



Michal




[Index of Archives]     [Virt Tools]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux