What documentation and/or forum discussions should I look at to get a better understanding of what should happen up to the point that grub2 processes the correct grub.cfg
Mainly in trying to repurpose obsolete hardware, I have often found myself in the situation of booting up to a grub> prompt and grub2 has not read the correct grub.cfg
There are multiple files grub2 itself might have been loaded from, so I’m never sure whether the correct copy of grub2 has loaded. Is there a way to diagnose where grub2 has loaded from?
Sometimes this has happened and grub doesn’t seem to include the modules needed to read any filesystem, so basically nothing can be done from the grub> prompt.
Other times, grub2 seems to have failed to read grub.cfg for no good reason. So to get to the normal boot menu, I just give the command to source the correct grub.cfg
One system currently in this state (because I don’t visit it very often) unfortunately has a few different people doing admin activities and not talking with each other (not a “mission critical” system for anyone, but I’d like it to be working). On last visit, I found this problem but did not diagnose nor repair it. I only got as far as checking date stamps on all the relevant files, none of which were new dates. So whoever did whatever to break it, did so without changing getting new date stamps on those files.
In the past, efibootmgr on that system gave me results I could not make any sense of. I fixed a failure similar to the current one without learning anything nor understanding what had been wrong nor what I fixed. Next time I’ll try to record more details.
Other than efibootmgr what tools might give me a clue about the early boot process (how the BIOS hands off to what image on the hard drive).? BTW, there is only one drive, a GPT hard drive with many partitions. I set up the Fedora / Windows 10 dual boot to be managed by grub2 (rather than by the BIOS boot menu) because the BIOS boot menu never worked right. I can boot a Ventoy stick containing a Fedora 37 live image if I need a “place to stand” while fixing that hard drive.
I don’t know how to interpret this line from efibootmgr Boot0000* EFI HDD Device PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0,0,0)/HD(3,GPT,2ef0e15c-1784-4910-9ef8-030c747508ec,0x363800,0x82000)RC
That would boot from a PCI connected disk unit with a GPT partition table. The partition with the partition UUID “2ef0e15c-1784-4910-9ef8-030c747508ec” will be the location of the ESP (uefi) file system. In that file system it will boot from the file EFI/BOOT/BOOTX64.EFI
To find the partition UUID run
lsblk -o PATH,PARTUUID,UUID
The partition UUID is in the second column. The UUID in the third column is the file system UUID, which you will find in the /etc/fstab file.
Thanks.
To clarify:
Does the RC effectively mean EFI/BOOT/BOOTX64.EFI? Or RC means something else and that is the default when no filename is given? On other systems I’ve seen /File(filename) where that RC is.
In 3,GPT does the 3 limit it to the 3rd partition, or mean something else? If both partition number and UUID are encoded, I expect that means that if the partition of that number doesn’t have that UUID, that entry isn’t used. Is that correct?
Do the two numbers after the UUID give any important information?
When no file path name is specified it would boot the fall back default file path name, which is EFI/BOOT/BOOTX64.EFI.
What RC means, I don’t know. It is probably just noise.
They are the offset and size of the partition. Perhaps this is used, or perhaps not.
It turns out I was over thinking it while away from that machine and not looking carefully enough while I was there.
The parts of efibootmgr output I didn’t understand weren’t the selected entry anyway.
Back when I installed Fedora with default partitioning, it added another EFI partition, rather than add files to the existing one. (People here keep telling me it does not do that, and I’m not sure what I’m doing differently). On other systems, I removed the extra EFI partition after running the Fedora installer. On this computer, I copied the whole fedora directory from the new EFI partition to the original one, but left the new one in place and left the new one as the selected efi boot entry.
Something (still no clue what) both switched to the original EFI partition (but still the \EFI\FEDORA\SHIMX64.EFI file) as the selected boot entry, but also deleted the grub.cfg file from that directory (the stub one that redirects grub to the real grub.cfg file in the boot partition).
Once I understood that, I just recopied that grub.cfg file from the new EFI partition and left the entry pointing to the old EFI partition (either entry boots into the same grub menu). So until something breaks it again, it is OK.
Unlike most modern BIOSs, this one doesn’t let you modify any of the efi boot choices or sequence from inside the BIOS menu. So all the modifications have been done by automatic things in Windows and/or Linux update and/or repair.