Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#64175 - Libvirt fails to detect OVMF/UEFI firmware (regression)

Attached to Project: Arch Linux
Opened by Jaume Delclòs Coll (cosarara) - Saturday, 19 October 2019, 09:40 GMT
Task Type Bug Report
Category Packages: Extra
Status Unconfirmed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 13
Private No

Details

Description:
The behaviour is described in detail in this forum post: https://bbs.archlinux.org/viewtopic.php?id=250066
In short, even when ovmf is installed and /etc/libvirt/qemu.conf is properly configured, libvirt cannot find the ovmf images.

Additional info:
* The bug happens with libvirt-5.8.0-1
* Disappears when downgrading to libvirt-5.6.0-1

Steps to reproduce:
From https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF#Setting_up_an_OVMF-based_guest_VM

* After installing qemu, libvirt, ovmf, and virt-manager, add the path to your OVMF firmware image and runtime variables template to your libvirt config so virt-install or virt-manager can find those later on.

/etc/libvirt/qemu.conf

nvram = [
"/usr/share/ovmf/x64/OVMF_CODE.fd:/usr/share/ovmf/x64/OVMF_VARS.fd"
]

* You can now enable and start libvirtd.service and its logging component virtlogd.socket.

* Add your user to the libvirt user group to ensure authentication.

* Run virt-manager and create a new VM with the System kvm/qemu connection.

* When the VM creation wizard asks you to name your VM (final step before clicking "Finish"), check the "Customize before install" checkbox.

* In the "Overview" section, set your firmware to "UEFI". Except you can't because the option is grayed out (this is the bug).
This task depends upon

Comment by Joshua Marsh (icub3d) - Saturday, 19 October 2019, 14:52 GMT
I noticed in the qemu.conf that the config for nvram was "obsolete". It looks like they are expecting JSON configs like in /usr/share/qemu/firmware/ to find firmware (see: https://git.qemu.org/gitweb.cgi?p=qemu.git;a=blob_plain;f=docs/interop/firmware.json;hb=HEAD).

If you install extra/qemu-arch-extra, it will populated some of the firmwares that are already setup in /usr/share/qemu/firmware/. Those will then show up in the virt-manager firmware drop-down list.

I'm wondering if we need such a config for ovmf?

Comment by Julian Phillips (chr0mag) - Saturday, 19 October 2019, 17:08 GMT
I just tried this by copying the '60-edk2-ovmf.json' example located here: https://src.fedoraproject.org/rpms/edk2/c/674b3c8a27a8 -- to '/etc/qemu/10-ovmf.json', changing the paths to match those of the Arch 'ovmf' package and launching virt-manager. It now finds the OVMF firmware. So yes, at least one such config should be included in the 'ovmf' package. The above Fedora link is a good starting point for example configs.

Also note that existing VMs that use the ovmf firmware run just fine, presumably because the nvram tag in the image XML definition points directly to the per-image firmware in /var/lib/libvirt/qemu/nvram/. I suspect it's also possible to create a new VM using 'virsh install' and passing it an XML config pointing directly to the base nvram firmware but I haven't actually tried this.
Comment by loqs (loqs) - Saturday, 19 October 2019, 17:10 GMT Comment by David J. Haines (dhaines) - Saturday, 19 October 2019, 21:17 GMT
This regression presents itself similarly via `virt-install`:

```
$ virt-install --name test --disk size=64 --network network=default --os-variant archlinux --boot uefi --memory 8192 -d
[Sat, 19 Oct 2019 17:15:56 virt-install 8171] DEBUG (cli:208) Launched with command line: /usr/share/virt-manager/virt-install --name test --disk size=64 --network network=default --os-variant archlinux --boot uefi --memory 8192 -d
[Sat, 19 Oct 2019 17:15:56 virt-install 8171] DEBUG (virt-install:207) Distilled --network options: ['network=default']
[Sat, 19 Oct 2019 17:15:56 virt-install 8171] DEBUG (virt-install:139) Distilled --disk options: ['size=64']
[Sat, 19 Oct 2019 17:15:56 virt-install 8171] DEBUG (cli:224) Requesting libvirt URI default
[Sat, 19 Oct 2019 17:15:56 virt-install 8171] DEBUG (cli:227) Received libvirt URI qemu:///system
[Sat, 19 Oct 2019 17:15:56 virt-install 8171] DEBUG (storage:140) Found default pool name=default target=/var/lib/libvirt/images
[Sat, 19 Oct 2019 17:15:56 virt-install 8171] DEBUG (storage:208) refreshing pool=default
[Sat, 19 Oct 2019 17:15:56 virt-install 8171] DEBUG (disk:225) Creating volume 'test.qcow2' on pool 'default'
[Sat, 19 Oct 2019 17:15:56 virt-install 8171] DEBUG (disk:359) disk.set_vol_install: name=test.qcow2 poolxml=
<pool type='dir'>
<name>default</name>
<uuid>a853f421-5115-4559-b757-a85b11dd337e</uuid>
<capacity unit='bytes'>274810798080</capacity>
<allocation unit='bytes'>11137085440</allocation>
<available unit='bytes'>263673712640</available>
<source>
</source>
<target>
<path>/var/lib/libvirt/images</path>
<permissions>
<mode>0755</mode>
<owner>0</owner>
<group>0</group>
</permissions>
</target>
</pool>

[Sat, 19 Oct 2019 17:15:56 virt-install 8171] DEBUG (guest:463) Setting Guest osinfo name <_OsVariant name=generic>
[Sat, 19 Oct 2019 17:15:56 virt-install 8171] DEBUG (installer:396) No media for distro detection.
[Sat, 19 Oct 2019 17:15:56 virt-install 8171] DEBUG (installer:398) installer.detect_distro returned=None
[Sat, 19 Oct 2019 17:15:56 virt-install 8171] DEBUG (guest:463) Setting Guest osinfo name <_OsVariant name=archlinux>
[Sat, 19 Oct 2019 17:15:56 virt-install 8171] DEBUG (osdict:326) No recommended value found for key='ram', using minimum=536870912 * 2
[Sat, 19 Oct 2019 17:15:56 virt-install 8171] DEBUG (cli:263) File "/usr/share/virt-manager/virt-install", line 1012, in <module>
fail(main_e)
File "/usr/share/virt-manager/virtinst/cli.py", line 263, in fail
log.debug("".join(traceback.format_stack()))

[Sat, 19 Oct 2019 17:15:56 virt-install 8171] ERROR (cli:264) Did not find any UEFI binary path for arch 'x86_64'
[Sat, 19 Oct 2019 17:15:56 virt-install 8171] DEBUG (cli:266)
Traceback (most recent call last):
File "/usr/share/virt-manager/virt-install", line 1005, in <module>
sys.exit(main())
File "/usr/share/virt-manager/virt-install", line 993, in main
guest, installer = build_guest_instance(conn, options)
File "/usr/share/virt-manager/virt-install", line 560, in build_guest_instance
installer.set_install_defaults(guest)
File "/usr/share/virt-manager/virtinst/install/installer.py", line 340, in set_install_defaults
guest.set_defaults(None)
File "/usr/share/virt-manager/virtinst/guest.py", line 729, in set_defaults
self._set_default_uefi()
File "/usr/share/virt-manager/virtinst/guest.py", line 787, in _set_default_uefi
path = self.get_uefi_path()
File "/usr/share/virt-manager/virtinst/guest.py", line 559, in get_uefi_path
"arch '%s'") % self.os.arch)
RuntimeError: Did not find any UEFI binary path for arch 'x86_64'
```
Comment by Julian Phillips (chr0mag) - Saturday, 19 October 2019, 23:00 GMT
Sorry, I conflated 'virt-install' with 'virsh create/define'. The latter 2 accept as arguments a domain XML file which you can point directly to the nvram firmware. The following allows you to create a new UEFI/OVMF VM in v5.8:
*virsh dumpxml <existing-uefi-vm-name> virsh-test.xml -- to get a template to work with
*edit virsh-test.xml -- change the name, delete the description, uuid, os/nvram tags and set the only hard disk to the arch iso.
*virsh define virsh-test.xml --validate
*open virt-manager -- the new UEFI/OVMF VM should appear and can be launched successfully

Hand editing XML is awful, but it does work.
Comment by Toolybird (Toolybird) - Sunday, 20 October 2019, 00:01 GMT
This smells like an accidental upstream change (ie: a bug). I doubt that upstream intentionally set out to break existing setups, especially when reading the comments in these commits:

https://www.redhat.com/archives/libvir-list/2019-May/msg00003.html
https://www.redhat.com/archives/libvir-list/2019-September/msg00485.html

The future is clearly the new FW descriptor JSON thing, but existing setups shouldn't just fall over. I might file an upstream bug after some more digging..

Comment by David J. Haines (dhaines) - Sunday, 20 October 2019, 01:50 GMT
The workaround mentioned above is almost, but not quite, correct. Try this instead (as root):

```
mkdir -p /etc/qemu/firmware
sed 's#qemu/edk2-x86_64-code.fd#ovmf/x64/OVMF_CODE.fd#;s#qemu/edk2-i386-vars.fd#ovmf/x64/OVMF_VARS.fd#' < /usr/share/qemu/firmware/60-edk2-x86_64.json > /etc/qemu/firmware/10-ovmf-workaround.json
systemctl restart libvirtd
```
Comment by Jeremy Audet (ichimonji10) - Monday, 21 October 2019, 02:02 GMT
I can confirm that the workaround provided by dhaines works. (Thanks, btw!)
Comment by Toolybird (Toolybird) - Monday, 21 October 2019, 20:21 GMT
Went ahead and filed an upstream bug[1] but no response yet.

We should really just get with the times and provide a JSON file via the ovmf package.

I've tested a patch and submitted it here[2]

It achieves exactly the same effect as the workaround / config edits mentioned above.

1. https://bugzilla.redhat.com/show_bug.cgi?id=1763477
2. FS#64206
Comment by Jeremy Audet (ichimonji10) - Tuesday, 22 October 2019, 17:27 GMT
I can also confirm that the patch provided by Toolybird works. See bug report for details. (Yes, I removed `/etc/qemu/firmware` as part of my testing procedure.)
Comment by Sim Sun (imi415) - Wednesday, 23 October 2019, 07:46 GMT
Added a similar file to /usr/share/qemu/firmware did solved this problem.
Here is my file for testing: /usr/share/qemu/firmware/60-ovmf-x86_64.json
Comment by Cyrus Frost (cyfrost) - Friday, 25 October 2019, 16:44 GMT
Can confirm that the workaround provided by dhaines works, thank you.
Comment by Toolybird (Toolybird) - Sunday, 10 November 2019, 20:13 GMT
Upstream has spoken and the verdict is in - libvirt is working as designed and Arch needs to adapt.

There are 2 problems:

1. qemu defaults to installing pre-built edk2 blobs and JSON files. The mere presence of a Firmware Desciptor JSON file on a system is enough for libvirt to ignore the nvram setting in /etc/libvirt/qemu.conf. This is by design.

2. Arch needs to modernize and ship an appropriate JSON file with the OVMF package.


1. can be fixed by following the Fedora lead in their qemu spec file:

# Provided by package edk2
rm -rf %{buildroot}%{_datadir}/%{name}/edk2*
rm -rf %{buildroot}%{_datadir}/%{name}/firmware/*edk2*.json

2. can be fixed by applying the patch provided in FS#64206

Loading...