Bug 1691661
| Summary: | livemedia-creator doesn't work in UEFI mode | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Renaud Métrich <rmetrich> | ||||
| Component: | lorax | Assignee: | Brian Lane <bcl> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Release Test Team <release-test-team-automation> | ||||
| Severity: | medium | Docs Contact: | Eliane Ramos Pereira <elpereir> | ||||
| Priority: | medium | ||||||
| Version: | 8.0 | CC: | atodorov, elpereir, lersek, pholica, tbowling | ||||
| Target Milestone: | rc | Flags: | pm-rhel:
mirror+
|
||||
| Target Release: | 8.0 | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | lorax-28.14.27-1.el8 | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2019-11-05 20:42:41 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Created attachment 1547041 [details]
qemu patch
Found the patch.
Oh, and I just noticed your cmdline is using a rhel7 iso, that is not supported. It *may* work but there is no guarantee. rhel8-branch PR for this - https://github.com/weldr/lorax/pull/658 Hi, (In reply to Brian Lane from comment #5) > rhel8-branch PR for this - https://github.com/weldr/lorax/pull/658 I've now checked <https://github.com/weldr/lorax/pull/658/commits/c4342f8f83c9f41b48b57624d42378db82de1fb2>. It looks good to me, I'd just like to highlight a fact that may not be obvious. "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. - https://bugzilla.redhat.com/show_bug.cgi?id=1546084 - https://bugzilla.redhat.com/show_bug.cgi?id=1600230 - https://bugzilla.redhat.com/show_bug.cgi?id=1564270 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. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:3328 |
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): lorax-28.14.23-1.el8.x86_64 How reproducible: Always 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.