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):
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.
One one system (a KVM guest) GRUB requests:
On another (a POWER8 LPAR) GRUB requests:
Previous builds of GRUB would request:
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.
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:
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:
(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.
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:
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.