Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
GRUB2 sometimes looks in the wrong place for its config file when netbooting on ppc64.
Version-Release number of selected component (if applicable):
grub2-2.02-0.8.fc21.ppc64
How reproducible:
easily enough, in this exact configuration with specific systems...
Steps to Reproduce:
1. Create a TFTP tree with: grub2-mknetdir --net-directory=/var/lib/tftpboot
2. Create a symlink /var/lib/tftpboot/ppc/<hexip>-grub pointing at ../boot/grub2/powerpc-ieee1275/core.elf
(Beaker does this symlinking so that it can *remove* the symlink after installation and cause the system to fall back to booting from hard disk.)
3. Set up some ppc64 systems to netboot with "ppc/<hexip>-grub" as the DHCP filename
4. Boot the systems and try to guess where GRUB will load its config from.
Actual results:
One one system (a KVM guest) GRUB requests:
/ppc/grub.cfg-01-52-54-00-c7-c2-2d
/ppc/grub.cfg-0A1043F9
On another (a POWER8 LPAR) GRUB requests:
//grub.cfg-01-92-8a-e0-af-1a-04
//grub.cfg-0A1043DF
...
Previous builds of GRUB would request:
/boot/grub2/grub.cfg-<...>
Expected results:
I have no idea, that's part of the problem :-) but it needs to at least be consistent, and ideally documented! (bug 1148650)
I guess the desired behaviour is to look in ppc/ since that is relative to the boot filename.
Additional info:
We ran up against this in Beaker bug 1144106 where we are trying to get ppc64 systems consistently booting with GRUB2.
Andrew, can you please confirm that the description in comment 0 is right?
I also noticed that grub2-mknetdir takes a --subdir= option, it's not documented anywhere except this random man page from the internet:
http://www.linuxhowtos.org/manpages/8/grub2-mknetdir.htm
so I don't know if it is expected to have any influence over the paths used in GRUB.
Andrew, can you confirm that you didn't use --subdir when you produced any of the netboot trees? Or maybe you used --subdir=ppc/ which is what gave us the ppc/ directory in the config paths in the working case?
Just adding a note here for docs to find as to what the currently defined order *is*. This is assuming:
1) 7726a678-7fc0-4853-a4f6-c85ac36a120a <-- client uuid. Each nic has one of these, and they're not ever this particular value
2) 52:54:00:ec:33:81 <-- random mac address I've chosen.
3) fw_path is the grub-style path of where grub got loaded from, i.e.
(tftp)/some/directory/ . If it starts with (tftp), it'll try:
$(fw_path)/grub.cfg-7726a678-7fc0-4853-a4f6-c85ac36a120a
$(fw_path)/grub.cfg-01-52-54-00-ec-33-81
$(fw_path)/grub.cfg-0A000082
$(fw_path)/grub.cfg-0A00008
$(fw_path)/grub.cfg-0A0000
$(fw_path)/grub.cfg-0A000
$(fw_path)/grub.cfg-0A00
$(fw_path)/grub.cfg-0A0
$(fw_path)/grub.cfg-0A
$(fw_path)/grub.cfg-0
$(fw_path)/grub.cfg
(If you're using IPv6, it'll just try the whole IPv6 address once; it won't try one character shorter at a time.)
If $fw_path and $prefix are different, and it still hasn't found anything, it'll try all that again with $(prefix) _if_ it starts with (tftp).
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://rhn.redhat.com/errata/RHBA-2015-0492.html
Peter, I'm trying out a similar setup on x86_64 EFI and I am seeing this same (buggy) behaviour. To produce the TFTP netboot tree I ran:
grub2-mknetdir --net-directory=/var/lib/tftpboot
with:
grub2-2.02-0.16.el7.x86_64
grub2-efi-modules-2.02-0.16.el7.x86_64
Shouldn't this bug be fixed in that package? Does x86_64 EFI need to be fixed separately? Should I open a new BZ, or am I doing something wrong?
(In reply to Dan Callaghan from comment #16)
Seems like fw_path on EFI is being set incorrectly (too many path components stripped) which is causing GRUB to use the wrong config path. I've filed a separate bug about it: bug 1211101.