Boot issues encountered on RHEL 8.10 provisioned by Satellite 6.15 server

Solution Verified - Updated

Environment

  • Red Hat Satellite 6.15

Issue

  • After being deployed via PXE from the Red Hat Satellite server, the first reboot of the provisioned system goes correctly as expected because it boots the local HDD. However, any subsequent reboot thereafter results in no boot at all (as if the HDD is not detected after the PXE timeout), and the system is stuck there.

Resolution

For more KB articles/solutions related to Red Hat Satellite 6.x Provisioning Issues, please refer to the Consolidated Troubleshooting Article for Red Hat Satellite 6.x Provisioning related Issues

Root Cause

In the grub.cfg file generated by Satellite, there is a search for shimx64.efi in various places, depending on the operating system, for example:

 39 menuentry 'Chainload Grub2 EFI from ESP' --id local_chain_hd0 {
 40   echo "Chainloading Grub2 EFI from ESP, enabled devices for booting:"
 41   ls
 42   echo "Trying /EFI/fedora/shim.efi "
 43   unset chroot
 44   # add --efidisk-only when using Software RAID
 45   search --file --no-floppy --set=chroot /EFI/fedora/shim.efi
 46   if [ -f ($chroot)/EFI/fedora/shim.efi ]; then

There is also a RHEL snippet in the file:

 63   unset chroot
 64   # add --efidisk-only when using Software RAID
 65   search --file --no-floppy --set=chroot /EFI/redhat/shim.efi
 66   if [ -f ($chroot)/EFI/redhat/shim.efi ]; then
 67     chainloader ($chroot)/EFI/redhat/shim.efi
 68     echo "Found /EFI/redhat/shim.efi at $chroot, attempting to chainboot it..."
 69     sleep 2
 70     boot
 71   fi
 72   echo "Trying /EFI/redhat/grubx64.efi "
 73   unset chroot
 74   # add --efidisk-only when using Software RAID
 75   search --file --no-floppy --set=chroot /EFI/redhat/grubx64.efi
 76   if [ -f ($chroot)/EFI/redhat/grubx64.efi ]; then
 77     chainloader ($chroot)/EFI/redhat/grubx64.efi
 78     echo "Found /EFI/redhat/grubx64.efi at $chroot, attempting to chainboot it..."
 79     sleep 2
 80     boot
 81   fi

The searching is not for the proper Shim executable, which is /EFI/redhat/shimx64.efi, not /EFI/redhat/shim.efi.

Then, depending on the hardware, especially with PXE boots, it is necessary to make sure that the EFI firmware initializes the entire SCSI chain, or else it may see the files but not read them. This is done by uncommenting line 37:

 25 echo "VMWare hosts with QuickBoot feature enabled may not find the local ESP"
 26 echo "partition due to not initializing all the EFI devices. To workaround, upgrade"
 27 echo "to the latest grub2 (*) and uncomment "connectefi scsi" statement in the"
 28 echo "grub2_chainload template."
 29 echo
 30 echo "Virtual or physical hosts using Software RAID for the ESP partition may try"
 31 echo "booting on the Software RAID, which will fail. To workaround, upgrade to the"
 32 echo "latest grub2 (*) and add "--efidisk-only" argument to the "search" command in"
 33 echo "the grub2_chainload template."
 34 echo
 35 echo "(*) grub2-efi-x64-2.02-122.el8 (upstream doesn't have the patches yet)"
 36 echo
 37 #connectefi scsi

Diagnostic Steps

  1. Verify whether the BIOS/EFI boot order configuration is configured with PXE as the first boot device and HDD as the second.

  2. Grab the PXE snippet from the Satellite server used for provisioning for review. It should be a grub.cfg file on the PXE server (or a grub.cfg-xxx machine specific file).

SBR
Product(s)
Components
Category
Tags

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.