Bug 2101818
| Summary: | Create /EFI/redhat symlinks in TFTP directory | |||
|---|---|---|---|---|
| Product: | Red Hat Satellite | Reporter: | Marek Hulan <mhulan> | |
| Component: | Installation | Assignee: | satellite6-bugs <satellite6-bugs> | |
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Satellite QE Team <sat-qe-bz-list> | |
| Severity: | high | Docs Contact: | Marie Hornickova <mdolezel> | |
| Priority: | high | |||
| Version: | 6.11.0 | CC: | ahumbe, akjha, ehelms, ekohlvan, gsulliva, ldelouw, osousa, pmendezh, saydas, smallamp, vijsingh | |
| Target Milestone: | Unspecified | Keywords: | Regression, Triaged, WorkAround | |
| Target Release: | Unused | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | Known Issue | ||
| Doc Text: |
Provisioning of `Grub 2 UEFI` host fails with Capsule Servers running on RHEL 8.5 and later versions
Due to changes in the `grub2-efi` package, the base directory where `Grub 2` searches for configuration files has changed. Consequently, attempts to provision a `Grub 2 UEFI` host from Capsule Servers running on RHEL 8.5 or later versions of RHEL 8 fail.
To work around the issue, create relative symlinks in the `/var/lib/tftpboot` directory as follows:
* /var/lib/tftpboot/EFI/redhat -> ../../grub2
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 2103104 (view as bug list) | Environment: | ||
| Last Closed: | 2024-04-04 13:54:42 UTC | Type: | --- | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
|
Description
Marek Hulan
2022-06-28 12:54:08 UTC
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 |