Bug 1156201
Summary: | [RFE]Provisioning of RHEL 7 on EFI system should use bootx64.efi (shim.efi) and grubx64.efi | ||
---|---|---|---|
Product: | [Retired] Beaker | Reporter: | Lenny Szubowicz <lszubowi> |
Component: | lab controller | Assignee: | beaker-dev-list |
Status: | CLOSED WONTFIX | QA Contact: | tools-bugs <tools-bugs> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 0.18 | CC: | bpeck, cbouchar, emcnabb, ernunes, fmartine, jaredz, jbastian, jburke |
Target Milestone: | --- | Keywords: | FutureFeature |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Enhancement | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2020-11-19 21:40:07 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: | |||
Bug Depends On: | 1156036 | ||
Bug Blocks: |
Description
Lenny Szubowicz
2014-10-23 19:35:32 UTC
(In reply to Lenny Szubowicz from comment #0) > My understanding is that other architectures have a similar need now, where > the network boot loader has to vary based on the OS version that is being > provisioned. No, that requirement doesn't exist for any other arch/loader at present. And this is not totally trivial since Beaker does *not* control DHCP config for the systems it manages. Is GRUB2 a supported netboot method for RHEL6? Can we instead switch to using GRUB2 for all x86 EFI? (In reply to Dan Callaghan from comment #1) > (In reply to Lenny Szubowicz from comment #0) > > My understanding is that other architectures have a similar need now, where > > the network boot loader has to vary based on the OS version that is being > > provisioned. > > No, that requirement doesn't exist for any other arch/loader at present. And > this is not totally trivial since Beaker does *not* control DHCP config for > the systems it manages. Oh sorry, I guess you were talking about bug 1156036 which is another RFE that was only just filed overnight too :-) (In reply to Dan Callaghan from comment #1) > (In reply to Lenny Szubowicz from comment #0) > > My understanding is that other architectures have a similar need now, where > > the network boot loader has to vary based on the OS version that is being > > provisioned. > > No, that requirement doesn't exist for any other arch/loader at present. And > this is not totally trivial since Beaker does *not* control DHCP config for > the systems it manages. > > Is GRUB2 a supported netboot method for RHEL6? Can we instead switch to > using GRUB2 for all x86 EFI? Netbooting RHEL6 via GRUB2 is not supported. It might be made to work, but we don't even provide a grub2 package with RHEL6, so it's nothing that our customers would do. A solution that attempts to use the same binary boot loader for all versions of a distro is not going to work in the general case with secure boot. If the network boot loader is shim.efi it can carry distro and version specific public keys that are uniquely tied to that distro and shim.efi might be signed with different private keys. -Lenny. I agree that this is a non-trivial request since the DHCP config specifies the network boot program and Beaker does not today have a way to dynamically change that. As a short term solution, would it be possible for every EFI system to have it own host-specific entry in the DHCP config file? Each of these entries would need to specify the boot file name as something like <hex ip address>/network_boot.efi. Then on the tftp server, Beaker could set <hex ip address>/network_boot.efi based on the provisioned distro version or set it back to a default entry via a symlink. This would make the DHCP config file more cumbersome. But at this point the majority of the systems in Beaker are still legacy BIOS systems. There are probably on the order of 2 dozen systems which would require this treatment. -Lenny. The configurable boot loader support which landed in Beaker 20 [1] will let us set the DHCP config for a system once, and then change boot loaders on a per-recipe basis. In 20.0 we are using that to boot GRUB2 for ppc64 RHEL7.1+ and yaboot for ppc64 on older distros. We can use the same support to achieve the same thing for x86. I've successfully booted GRUB2 for x86 BIOS and EFI by passing netbootloader= to point at the images produced by grub2-mknetdir (modulo another GRUB config path problem, bug 1211101). However that is just a regular unsigned GRUB2, the Secure Boot stuff is an extra complexity on top. For that we probably need to use the exact shim.efi and grubx64.efi images from the distro being provisioned, which means we will have to make Beaker start managing those images because doing it by hand will be an nightmare. [1] https://beaker-project.org/docs-develop/whats-new/release-20.html#configurable-netboot-loader I never realised before, because it's not hinted at in the installation guide, but RHEL and Fedora trees already have the necessary images split out in the install tree so that beaker-provision can grab them the same way it grabs kernel+initrd. For example here are the F22 Server x86_64 GRUB images: http://dl.fedoraproject.org/pub/fedora/linux/releases/22/Server/x86_64/os/EFI/BOOT/ Similarly there is /EFI/BOOT in the aarch64 trees, and /boot/grub in the ppc64(le) trees. How do we get this open issue prioritized? It was opened six years ago. It's become pretty important to fix in order for engineering and QA better handle bootloader related work and hopefully prevent, say, bad regressions like we saw with Red Hat's BootHole response. |