Unfortunately this documentation is the only piece of information about BLS, and it’s not very comprehensive.
If have now gotten my old boot loader setup to work with GRUB_ENABLE_BLSCFG=false.
But when I set GRUB_ENABLE_BLSCFG=true in /etc/default/grub, then run grub2-mkconfig -o /boot/grub2/grub.cfg, the boot entries for fedora disappear, and only the Windows boot entry remains.
This is despite being available in /boot/loader/entries:
[root@desktop-fedora ~]# ls /boot/loader/entries/
6.0.12-300.fc37.x86_64
8d7c20f2c693476db7244e29389ae9a2-0-rescue.conf
8d7c20f2c693476db7244e29389ae9a2-6.0.12-200.fc36.x86_64.conf
8d7c20f2c693476db7244e29389ae9a2-6.0.12-300.fc37.x86_64.conf
8d7c20f2c693476db7244e29389ae9a2-6.0.8-200.fc36.x86_64.conf
I am currently running Fedora 37, but these issues occured in Fedora 36 and before as well.
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:
insmod blscfg
blscfg
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/
No, I’m looking at the actual GRUB menu. It does not have entries for Fedora.
After running grub2-switch-to-blscfg and grub2-mkconfig -o /boot/grub2/grub.cfg, this is the contents of my /boot/grub2/grub.cfg: https://paste.centos.org/view/b3d52413
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.
First of all thanks to everyone who participated, I was able to figure out the issue.
You are correct, it was a cpio file and I do not know what or who put it there. May have been me with a rogue command. It was not the (only?) source of the problem, however.
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!!!
blsdir=/root/boot/loader/entries
save_default=true
saved_entry=8d7c20f2c693476db7244e29389ae9a2-6.0.15-300.fc37.x86_64
boot_success=1
boot_indeterminate=0
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!
I’m sorry I didn’t mention read requires a variable name. The documentation
Command: read [var]
Read a line of input from the user. If an environment variable var is given, set that environment variable to the line of input that was read, with no terminating newline.
says the variable name is optional. But in all my attempts, it works with a variable name and not without. So I’m guessing you tried without a variable, so it didn’t work.
Good job substituting sleep for read (in Linux, there is always another way to do whatever you are trying to do).
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.
