A change in grub2 build config (package grub2-efi file grubx64.efi) changed the base directory where grub2 tries to find configuration files. It used to be the current directory, now it changed to /EFI/redhat (or /EFI/centos or /EFI/fedora etc). While this works fine for local booting, it breaks our PXE/TFTP provisioning. We could start building our grub via `grub2-mknetdir` which has options to configure where grub should load configuration files from, but then the bootloader will not be signed and SecureBoot will not be possible. Therefore I suggest a workaround, let's create a *relative symlinks* in the TFTP directory (/var/lib/tftpboot) as follows: * /var/lib/tftpboot/EFI/redhat -> ../../grub2 * /var/lib/tftpboot/EFI/centos -> ../../grub2 * /var/lib/tftpboot/EFI/fedora -> ../../grub2 Unfortunately every distribution or RH clone has their own ESP EFI subdirectory (which is needed for multi-boot systems), therefore we need to create symlinks for all linux distributions we support. This was reported multiple times, for example: https://community.theforeman.org/t/provisioning-bare-metal-host-over-uefi-client-requesting-grub-cfg-in-wrong-location/29053 Alternative solution would be start building grub2 via the mknetdir and dropping support for SecureBoot for all network booting completely. This is what we do for Debian anyway because the grub2 there is not signed anyway, so we would start doing the same for Red Hat systems. Triage: This is high-impact regression, all Red Hat / clones systems are affected.
Created from redmine issue https://projects.theforeman.org/issues/35101
Upstream bug assigned to None
*** Bug 2103104 has been marked as a duplicate of this bug. ***
Today I spent some time diving into EFI and the grub 2 packaging for an unrelated reason. The grub sources are patched in RPM sources to have: EFIDIR=$(grep ^ID= /etc/os-release | sed -e 's/^ID=//' -e 's/rhel/redhat/' -e 's/\"//g') Then use /EFI/${EFIDIR}. In this path we can find the resulting grubx64.efi as well. Looking at the Foreman source, we have https://github.com/theforeman/foreman/blob/develop/app/views/unattended/provisioning_templates/snippet/pxegrub2_mac.erb as a template. It's quite short, so pasting here for completeness: echo "Trying /httpboot/grub2/grub.cfg-$net_default_mac" configfile "/httpboot/grub2/grub.cfg-$net_default_mac" echo "Trying /grub2/grub.cfg-$net_default_mac" configfile "/grub2/grub.cfg-$net_default_mac" # The following four statements breaks grub2 and it's no # longer able to load any file from the base URL. # Comment them out to be able to use (UEFI/iPXE) HTTP Boot: # https://bugzilla.redhat.com/show_bug.cgi?id=1763216 echo "Trying grub2/grub.cfg-$net_default_mac" configfile "grub2/grub.cfg-$net_default_mac" echo "Trying grub.cfg-$net_default_mac" configfile "grub.cfg-$net_default_mac" I see the bug for the relative config file is resolved. Then looking at the tcpdumps from the upstream community (VERY helpful) we see that it's requesting: /EFI/centos/grub.cfg-01-a4-bb-6d-81-73-3f Which is the net_default_mac. Knowing that normally it it's located in /EFI/centos and it's a relative filename, I suspect this is what's being triggered. From grepping through the grub source I get the impression this isn't generated by grub itself, since grub.cfg- doesn't show up in the source at all. The big question is why it's not requesting the absolute filenames. It would be very helpful to see the generated files in the tftp root. To the workaround: on the DHCP server we instruct to use the grubx64.efi file that we also prepare by copying it form the host in Puppet code: $grub_efi_path = $facts['os']['name'] ? { /Fedora|CentOS|AlmaLinux|Rocky/ => downcase($facts['os']['name']), default => 'redhat', } $efi_lib_dir = "/boot/efi/EFI/${grub_efi_path}" This means we know the path can can create a symlink reliably (otherwise grubx64.efi couldn't have been copied). It should also be sufficient to create a single symlink. So I really wonder what's in the generated grub files in the tftp root and if removing the relative config files would also work/be a solution.
Recently I had a setup where I needed to use this myself in production. I did see it is requesting those files, but it wasn't needed for me. However, for me it was the only thing I saw when I didn't build the default PXE configuration file. That was misleading.