Description of problem: For systems that are set up to boot via an EFI network boot method, Beaker provisioning currently assumes that grub.efi (version 0.97) can be used as the network boot program regardless of what OS version is being provisioned. But is no longer a correct assumption. Although the 0.97 version of grub.efi happens to work with RHEL 7 installs on most x86_64 EFI systems, there are some systems that encounter problems with using this version of grub.efi regardless of what is being provisioned: (1) grub.efi fails to network load the RHEL 7 initrd, but grubx64.efi (grub2) can load the RHEL 7 initrd correctly (BZ 1010475). This means that on some systems you cannot install RHEL 7+ via a Beaker provisioning. (2) use of grub.efi to network boot RHEL 7 on a UEFI system is not the supported method. So most of our internal network boot testing of EFI systems is not done in the way that we document for our customers. (3) the use of grub.efi does not work with UEFI Secure Boot enabled while the supported approach does. Today, the DHCP server for these EFI systems specifies a fixed grub.efi (0.97) as the network boot program. Unfortunately, this is going to have to be dynamically changed based on what OS version is being provisioned via Beaker. 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. Version-Release number of selected component (if applicable): How reproducible: 100% on x86_64 EFI systems. Steps to Reproduce: 1. Provision RHEL 7.0+ on a EFI system 2. Boot the system to initiate the provision Actual results: 1. grub.efi is specified as the network boot program to the booting system 2. the booting system gets grub.efi via tftp 3. grub.efi running on the booting system requests grub.conf via tftp 4. grub.conf points to the kernel/initrd to start the install Expected results: 1. bootx64.efi is specified as the network boot program to the booting system 2. the booting system gets bootx64.efi via tftp 3. bootx64.efi running on the booting system requests grubx64.efi via tftp 4. grubx64.efi running on the booting system requests grub.cfg via tftp 5. grub.cfg points to the kernel/initrd to start the install Note that the actual results are correct for RHEL 6 and earlier. Note also that for a RHEL 7+ build, those files are all in ./work/x86_64/buildinstall/EFI/BOOT/ The MokManager.efi program should also be available in the same tftp directory. It's needed in some more unusual circumstances. Finally, note that bootx64.efi is actually shim.efi renamed to use a more generic name. Additional info: Note that the actual results are correct for RHEL 6 and earlier. So that sequence needs to be used when provisioning RHEL 6 or earlier. I'm not sure where the transition is for Fedora. Fedora 18 and newer should use the bootx64.efi sequence, but I'm not sure whether it goes further back in Fedora versions. Note also that for a RHEL 7+ build, those files are all in ./work/x86_64/buildinstall/EFI/BOOT/ The MokManager.efi program should also be available in the same tftp directory. It's needed in some more unusual circumstances. Finally, note that bootx64.efi is actually shim.efi renamed to use a more generic name. -Lenny.
(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.