Are you determining you have a problem by booting and looking at the menu? Or only by looking at /boot/grub2/grub.cfg?
I think you are misunderstanding how it works (the documentation is missing many important aspects).
/boot/grub2/grub.cfg is not supposed to contain menuentrys for Fedora nor anything else following the boot loader spec. Instead, it should contain the lines:
Those represent the point in the menu being constructed (usually first) where the contents of /boot/loader/entries/ will be inserted. grub2 itself does that insertion at boot time when constructing the menu (rather than the prior design in which mkconfig did that directly into grub.cfg).
If you only thought you had a problem (without testing) I hope the above cleared it up. If you tested and it really doesn’t work, first verify that those two lines really are in /boot/grub2/grub.cfg, and assuming they are, the question would be why the /boot/loader/entries location that is mounted during your normal use of Fedora is not the same location that is searched for loader/entries during the actual boot time.
I like the following command for getting a good understanding of which partitions are what: lsblk -o NAME,FSTYPE,SIZE,LABEL,FSSIZE,FSUSE%,MOUNTPOINTS,UUID
Then you might want to verify the UUID that is typically in /boot/efi/EFI/fedora/grub.cfg that tells where to look for /boot/grub2/grub.cfg (to make sure you’re really using the grub.cfg you think you are) and verify the UUID in the search --no-floppy --fs-uuid --set=root command inside /boot/grub2/grub.cfg that should overwrite the previous set root and give the starting point to find loader/entries/
insmod blscfg and blscfgare present, but there is much more content.
Here is the grub2 command prompt, when using the blscfg: (imgur DOT com SLASH GL52znY)
I can locate and open the loader/entries directory just fine, but then nothing happens. This is confirmed when setting debug=blscfgand running blscfg again:
(sry can’t add more than 2 links)
imgur DOT com SLASH CEE2ECv
imgur DOT com SLASH SlmuTtM
Looks to me like it can find everything just fine, but after that nothing at all happens. No menu is shown, no entries are created.
Everything looks correct. I don’t even have a decent guess why it might be not working.
I don’t know the rules for getting a changed menu to display once grub2 has displayed the menu once. My attempts have generally failed, so I’m not surprised you couldn’t get a menu after manually rerunning blscfg (If someone knows how to do that, I wish they’d tell me).
If I were in your situation, one long shot test I’d try would be to add that debug=blscfg command in your actual grub.cfg before the blscfg line and add a read command after the blscfg so you get to see any output before normal operation of grub2 erases it (when using it, press enter to get past the read step and let grub2 continue).
I don’t know what might be different from the output you saw when giving the commands manually. But if it was different, that would be a giant step toward understanding.
I also would put in an echo command before that to find out what $root really is. I checked: your search command that sets root is exactly right, so I don’t expect $root could be wrong. But by that logic, nothing can be wrong, so you need to check individual things that logically can’t be wrong.
I also just now tried my own debug=blscfg … read suggestion on my own system to see if there were any surprises (such as some extra line of debug output that appears on my working system that you didn’t get). Nothing looked different other than what is different because my /loader/entries/ are different.
I wonder if that is the cause. The kernel file that is not a .conf file and that does not match the fedora standard naming convention in that listing.
I suspect that if the 6.0.12-300.fc37.x86_64 file were removed from the /boot/loader/entries/ directory that grub would be able to properly populate the grub menu for you.
In my system all files in that directory start with the UUID and end with .conf
In your listing that is not the case for that one file.
Running sudo file /boot/loader/entries/* and ls -l /boot/loader/entries/ may also give you a clue.
This is an example of the first line in one of the .conf files on my laptop and is the name used to create the grub menu entry title Fedora Linux (6.0.11-200.fc36.x86_64) 36 (Workstation Edition)
All the files there have similar starting lines.
It was looking in the wrong place for the entries files! There’s no /boot/boot or /boot/root/boot directory obviously. Note that this behaviour is for some reason different from my previous post, where it seemingly loaded all entries from the right location but the menu was still missing. I have no explanation for the difference, maybe the previous steps like deleting the non-.conffile also helped.
The reason turned out to be my /boot/grub2/grubenv:
[root@desktop-fedora ~]# cat /boot/grub2/grubenv
# GRUB Environment Block
# WARNING: Do not edit this file by tools other than grub-editenv!!!
Note that for some reason, grubenv containted the blsdir variable which matched the wrong location from the output. Removing that line caused everything to be loaded correctly.
I don’t know if the line ended up there from a buggy package script or my own personal incompetence, but thanks again to everyone who gave input on this issue!
OK, so I think I figured out the original issue and thought I’d post it in case anyone from the future comes to visit here.
The exact same issue happened on another machine, and in this case I was repairing the boot loader using a live system. I accidentally forgot to chroot into my persistent system, and ran grub2-mkconfig from the live system instead.
This apparently causes the mkconfig script to add the path of the entries directory relativ to the system root to be written to grubenv.
So grub2-mkconfig should only be run from the system or from a chroot of the system, not from any other system that happens to be running on the machine. If you ran it accidentally, delete the line blsdir= from the file /boot/grub2/grubenv.