https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault
1 Like
Hi @gobigobi66! Welcome to the community! Please have a look at the introductory posts in the #start-here category if you haven’t had a chance to do so.
The big grub related change to F30 was about using BLS by default.
This may be what’s biting you (but it maybe something else, we’ll have to check).
To begin with can you please post the contents of your /etc/default/grub and output of
sudo dnf list installed 'grubby*'
1 Like
Thanks for your quick replies @vgaetera and @nightromantic, I am not near my desktop machine but I will check and post /etc/default/grub conf and installed grubby* packages tonight and report back.
Cheers!
grubby is
grubby.x86_64
8.40-31.fc30
@updates
/etc/default/grub is:
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="rd.lvm.lv=fedora00/root rd.luks.uuid=luks-3667a487-2cde-4f4c-b35a-5225ca21f846 rhgb quiet"
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=false
cat /etc/default/grub.rpmsave:
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="rd.lvm.lv=fedora00/root rd.luks.uuid=luks-3667a487-2cde-4f4c-b35a-5225ca21f846 rhgb quiet"
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true
So, BLSCFG seems to be turned off still: GRUB_ENABLE_BLSCFG=false
You have new BLS-compatible grubby installed, but BLS feature disabled in grub config. I second @vgaetera, enable BLS
GRUB_ENABLE_BLSCFG=true
then regenerate grub.cfg and either wait for kernel to update to verify grub menu updating correctly – or just manually remove oldest kernel.
The second option – which I don’t recommend – would be to install grubby-legacy (and remove grubby?), legacy is old variant which isn’t BLS-aware and works without it. But again, I don’t recommend going this route, I can see absolutely no reason to do so, and you’d end up with non-standard configuration (which can confuse you in the future).
1 Like
Setting GRUB_ENABLE_BLSCFG=true and regenerating grub using grub2-mkconfig does take care of it, right? Or would you say I rather run the script grub2-switch-to-blscfg?
What can go wrong? Does this have the potential to break my grub and dual boot capabilities so that I spend hours fixing it? What would be wrong running with BLSCFG=false? Or there is simply no way in F30 to automatically repopulate the grub list after kernel updatewithout BLSCFG?
Many thanks for your kind help!
1 Like
Yes, you should try it first, as the officially recommended method.
1 Like
And I’d regenerate grub.cfg manually without using grub2-switch-to-blscfg – though this is my personal gut feeling.
I guess you can go both ways )
If you’re unsure (which is a good thing to be), we can make additional checks and preparations before you reboot to test it ) As it’s a good thing to be prepared and know how to troubleshoot the grub issue (and it’s quite easy generally) – I’d do it here – just in case.
I can elaborate on this a bit, if you want, though this will be just my thoughts, I’m no expert.
1 Like
I would love to do that - how would those checks look like? What should I look for?
We can check the contents of your grub.cfg after updating it and before rebooting.
Also we can check the list of all the kernels you should see in your boot menu. I’ll provide details in a bit.
This is for a new grub.cfg with BLS enabled.
In /boot/efi/EFI/fedora/grub.cfg search for a line
## BEGIN /etc/grub.d/10_linux ###
That’s the section that is responsible for menu entries for your Fedora system (in general, Linux system which current instance of grub is installed in).
Skip several lines and you should see this block:
# This section was generated by a script. Do not modify the generated file - all changes
# will be lost the next time file is regenerated. Instead edit the BootLoaderSpec files.
#
# The blscfg command parses the BootLoaderSpec files stored in /boot/loader/entries and
# populates the boot menu. Please refer to the Boot Loader Specification documentation
# for the files format: https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/.
set default_kernelopts="root=/dev/mapper/vg_ssd-lv_fedora_root ro resume=/dev/mapper/vg_ssd-lv_swap rd.lvm.lv=vg_ssd/lv_fedora_root rd.lvm.lv=vg_ssd/lv_swap vconsole.font=latarcyrheb-sun16 rhgb quiet "
insmod blscfg
blscfg
### END /etc/grub.d/10_linux ###
Comment and default_kernel_opts is self-explanatory, insmod loads grub module, and blscfg executes command which will make boot menu entries with BLS enabled.
2 Likes
And to check for BLS boot entries themselves you can do
sudo ls /boot/loader/entries/
Each file in this directory corresponds to one boot menu entry you’ll see upon booting. These are simple text files, you can view them, they are easy to understand. They contain boot parameters for each entry.
There’s also a command to see BSL entries list, but I don’t remember it from the top of my head, need to search for it.
The command is:
sudo grubby --info ALL
It outputs the list of all the entries that would be in your boot menu, it corresponds to files in /boot/loader/entries/
If your grub.cfg doesn’t contain what I’ve posted or you don’t have entries under /boot/loader/entries/ then don’t reboot for now, something isn’t right.
2 Likes
One more general thought. When troubleshooting grub issues, it’s very useful to have a Fedora Live USB (or DVD) handy. If something doesn’t work and you can’t boot into your system (doesn’t happen often, but sometimes… ) – you can boot into Live session from USB, connect to the Internet and look for troubleshooting steps, and make all the necessary corrections form the live session or by chrooting into your installation.
This Fedora quick doc contains useful info about grub in general and restoring it specifically (but doesn’t say anything about BLS specifically, if I remember correctly).
P.S. @gobigobi66, hope I haven’t overwhelmed/confused you with things to check… It’s easy really 
harder – and longer – to write down what to look for than to do the actual check )
2 Likes
[quote=“nightromantic, post:15, topic:75948”]
P.S. @gobigobi66, hope I haven’t overwhelmed/confused you with things to check…
Not at all. Thanks a lot for your help - very much appreciated. I will look into it tonight and report back. Once I am done, we can discuss if it’s worth reporting a bug because something went wrong (Grubby requires BLSCFG but it wasn’t turned on, instead only saved a .rpmnew config. Not sure grubby-deprecated was installed automatically.
That I can’t tell, I generally don’t upgrade my installation, I reinstall (saving all my data and settings. of course, I find it cleaner).
That’s the default behavior for rpm package updates, as far as I know – but maybe only if you have original config file changed in some way. It’s up to user then to compare his version and rmpnew version and incorporate any changes he deems necessary (if any) into his config.
But for upgrading from F29 to F30 it sure looks like it should not have happened, though. Are you sure you haven’t manually set GRUB_ENABLE_BLSCFG=false? Because in F29 there was no such option at all, as far as I know. So either something went wrong during the upgrade process and upgrade script set this variable to false or… you did) there’s no other logical explanation.
It was not, if it were, then sudo dnf list installed 'grubby*' would list it as installed.
100% sure. I usually try to stay away from Grub configs as long as everything is working, especially in my dual-boot env.
Yes, of course, we checked for that.
Does the fact that I have used os-prober before and added the Win10 installation to Grub in the past maybe triggered the behaviour of saving a new config file instead of replacing the previous one?
Then I’d say something went wrong during update process, and set this parameter to false. That’s just the assumption, though.
I’d say it should not, though I don’t know for sure. By the way, grub itself should have found your Win10 installation, without you adding it manually. It usually does for me. It basically runs os-prober each time you rebuild grub.cfg or – at least previously – after each new kernel installation, and adds all the systems it can find (Windows, other Linux installations if you have any, etc.,) to the menu. That’s default configuration in Fedora. grub’s call for os-prober can be disabled in a couple of ways, but it’s enabled by default.
1 Like
@gobigobi66, just in case.
To add any kernel you already have installed to /boot/loader/entries/ (if it’s not there already) you can use the following command:
sudo grubby --add-kernel /boot/vmlinuz-5.1.20-300.fc30.x86_64 --title="Fedora (5.1.20-300.fc30.x86_64) 30 (Thirty)"
Title can be anything you want, as you understand. You can see all the kernel versions you have installed now with
sudo dnf list installed kernel
or just do ls for any vmlinuz* file in your /boot:
sudo ls -1 /boot/vmlinuz*
2 Likes
Please, note that grub-switch-to-blscfg is the officially recommended method.
Also note that grubby and grubby-deprecated are not mandatory dependencies, so you can safely remove them if you don’t need their functionality.
On the other hand it is assumed that all the .rpmnew files should replace or be merged with the original configurations either manually or with rpmconf, as new versions of packages may depend on new configuration parameters.
1 Like