Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1782778 - virt-install unable to find any master var store for loader
Summary: virt-install unable to find any master var store for loader
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: rawhide
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Michal Privoznik
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F32BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2019-12-12 10:29 UTC by Sampson Fung
Modified: 2020-02-03 17:44 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-02-03 17:44:31 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1776949 0 unspecified CLOSED Regression: unable to find any master var store for loader 2022-05-16 11:32:56 UTC

Description Sampson Fung 2019-12-12 10:29:48 UTC 
Description of problem:
Cannot install a guest using UEFI bios.

Version-Release number of selected component (if applicable):
libvirt 5.10.0-1.fc32
virt-install 2.2.1-2.fc31

How reproducible:
Everytime

Steps to Reproduce:
1. Fresh Install Fedora 32 (rawhide) Server
2. dnf install @virtualization
3.  
virt-install --name f31-uefi \
    --ram 2048 --disk size=10 \
    --boot uefi \
    --location https://dl.fedoraproject.org/pub/fedora/linux/releases/31/Server/x86_64/os/


Actual results:
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.

Expected results:
Guest installation OK

Additional info:
using virt-manager having the same error
Comment 1 Pavel Hrdina 2019-12-12 14:43:39 UTC 
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.
Comment 4 Michal Privoznik 2019-12-17 17:25:50 UTC 
Patches proposed on the upstream list:

https://www.redhat.com/archives/libvir-list/2019-December/msg01076.html
Comment 5 Fedora Blocker Bugs Application 2019-12-28 23:44:55 UTC 
Proposed as a Blocker for 32-beta by Fedora user chrismurphy using the blocker tracking app because:

 Beta:
"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.
Comment 6 Chris Murphy 2019-12-30 20:16:19 UTC 
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.
Comment 7 Chris Murphy 2020-01-07 04:08:29 UTC 
Patches mentioned in comment 4 are for qemu, should the bug component be changed to qemu so this can get fixed?

qemu-kvm-4.2.0-2.fc32.x86_64
libvirt-daemon-kvm-5.10.0-2.fc32.x86_64
Comment 8 Michal Privoznik 2020-01-07 13:46:00 UTC 
(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:

https://www.redhat.com/archives/libvir-list/2020-January/msg00231.html
Comment 9 Michal Privoznik 2020-01-07 16:11:16 UTC 
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()

v5.10.0-507-g8e1804f9f6
Comment 10 Cole Robinson 2020-01-13 18:28:50 UTC 
The root issue is in f31 libvirt packages, but it was only exposed by:

commit 5a5e92000d12a671f491c5fb90677f63b1ae7e75
Author: Jim Fehlig <jfehlig>
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
Comment 11 Paul Whalen 2020-01-29 19:48:49 UTC 
This is fixed on aarch64 with libvirt-6.0.0-1.fc32
Comment 12 Chris Murphy 2020-02-03 03:15:20 UTC 
UEFI VMs are working for me.
libvirt-daemon-6.0.0-1.fc32.x86_64
qemu-kvm-4.2.0-2.fc32.x86_64
Note You need to log in before you can comment on or make changes to this bug.