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.

I haven't been able to come up with a reproducer. I think a common problem is that people don't build the default PXE config after deploying a Capsule, which is the only reproducer I found.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days