Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1691661 - livemedia-creator doesn't work in UEFI mode
Summary: livemedia-creator doesn't work in UEFI mode
Status: POST
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: lorax
Version: 8.0
Hardware: x86_64
OS: Linux
Target Milestone: rc
: 8.0
Assignee: Brian Lane
QA Contact: Release Test Team
Depends On:
TreeView+ depends on / blocked
Reported: 2019-03-22 07:55 UTC by Renaud Métrich
Modified: 2019-03-25 17:16 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:
Type: Bug
Target Upstream Version:

Attachments (Terms of Use)
qemu patch (deleted)
2019-03-22 17:54 UTC, Brian Lane
no flags Details | Diff

Description Renaud Métrich 2019-03-22 07:55:23 UTC
Description of problem:

When trying to create an image in UEFI mode ("--virt-uefi" flag), livemedia-create doesn't work for several reasons:
- it fails to find the OVMF firmware
- after fixing the OVMF firmware filename, it spawns qemu-kvm with invalid flags causing the VM to spin on the CPU

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Execute livemedia-creator

 # livemedia-creator --make-disk --ks=/root/rhel7-minimal.ks --iso=/root/rhel-server-7.6-x86_64-boot.iso --image-name=rhel76efi.img --virt-uefi

Additional info:

Issues happen with Upstream lorax also.

Comment 3 Brian Lane 2019-03-22 17:54:28 UTC
Created attachment 1547041 [details]
qemu patch

Found the patch.

Comment 4 Brian Lane 2019-03-22 17:56:21 UTC
Oh, and I just noticed your cmdline is using a rhel7 iso, that is not supported. It *may* work but there is no guarantee.

Comment 5 Brian Lane 2019-03-22 21:34:38 UTC
rhel8-branch PR for this -

Comment 6 Laszlo Ersek 2019-03-23 11:11:33 UTC

(In reply to Brian Lane from comment #5)
> rhel8-branch PR for this -

I've now checked
It looks good to me, I'd just like to highlight a fact that may not be

"OVMF_CODE.secboot.fd" is the firmware executable. We do not provide
"OVMF_CODE.fd" for the reasons I described to Renaud in email.
Therefore, unconditionally using "OVMF_CODE.secboot.fd", with the
related QEMU flags, is correct in the patch.

"OVMF_VARS.secboot.fd" is a variable store template file. The method the
actual variable store file (a temporary file) is created from the
template is correct (in the pre-patch code already). This is where I'd
like to mention "OVMF_VARS.fd" -- because we still ship "OVMF_VARS.fd".
Let me explan why:

- "OVMF_VARS.secboot.fd" is a variable store template that has the
  Microsoft certificates pre-enrolled, and the Secure Boot operational
  mode pre-enabled. Therefore, if you create the varstore file from this
  template, then the virtual UEFI firmware will only boot such OS boot
  loaders that are appropriately signed. For example, it will boot all
  released Windows OSes from the Windows 8 family upward, it will boot
  all Fedora GA and RHEL GA releases, and so on. It will reject Beta
  builds of RHEL however -- for example.

- "OVMF_VARS.fd" is a variable store template that is logically empty.
  It has no certificates enrolled and the SB operational mode is not
  enabled. Therefore, if you create the varstore file from this
  template, the virtual firmware will accept & launch all UEFI OS boot
  loaders, without SB verification.

Both use cases are valid (that's why we provide both varstore templates,
to accompany the sole "OVMF_CODE.secboot.fd" firmware executable); it
depends on the user / utility which varstore template is the right
choice, for creating the varstore file.

See bug 1561128 for more details.


By the way: we are implementing automatic UEFI firmware selection in
qemu, edk2, and libvirt. This feature is supposed to eliminate the
"traditional" need for applications launching QEMU with UEFI firmware to
open-code the firmware binary and varstore template pathnames.


Comment 7 Brian Lane 2019-03-25 17:16:01 UTC
Thanks for the clarification. I think it's best to use the one with the pre-enrolled keys unless someone can thing of a good reason not to -- not to mention it works, so why not use it :)

I'm looking forward to automatic firmware selection, that'll make things simpler and more reliable.

Note You need to log in before you can comment on or make changes to this bug.