Grub not rebuilding after kernel update

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

@vgaetera, are you sure you can (or should) remove grubby (I’m not talking about grubby-deprecated here)?

I have it installed on my clean F30 installation (i.e. not upgraded from previous Fedora), and I didn’t install it manually. Are you sure it isn’t used, for example, by postinst script of the kernel package?

I’m pretty sure there’s no harm as the there’re no mandatory dependencies, in addition I have none of those packages and it works fine.

Ok, thanks for the info, I’ll keep it in mind.

Still, grubby (not deprecated version) proves useful in troubleshooting grub/boot issues.

I used to run rpmconf after every system-upgrade but I realize I have become more lazy and actually a bit forgotten about this topic, which, as we can see now, is an important one when it comes to upgrading the release. (I am usually upgrading, not reinstalling both my notebook and desktop since it has become so easy and reliable.)

2 Likes

so, whatever grub2-switch-to-blscfg does, the output isn’t verbose enough to understand what went wrong.

/usr/bin/grub2-editenv: error: invalid environment block.
Generating grub configuration file ...
/usr/bin/grub2-editenv: error: invalid environment block.
Updating /boot/efi/EFI/fedora/grub.cfg failed

after running the script, still GRUB_ENABLE_BLSCFG=false. So, will change that manually and rebuild grub.cfg manually as well.

So at this point, GRUB_ENABLE_BLSCFG is true but when I execute
grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg, the following (same error) occurs:

/usr/bin/grub2-editenv: error: invalid environment block.
Generating grub configuration file ...
/usr/bin/grub2-editenv: error: invalid environment block.

Any insights on the meaning of that?

grub2-editenv list returns

grub2-editenv: error: invalid environment block.

Any ideas what that means and how to fix it? Is it time for fsck (see https://bugzilla.redhat.com/show_bug.cgi?id=1336942)?

FYI: I reverted to GRUB_ENABLE_BLSCFG=false and ran grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg again. That way at least I didn’t lose the ability to boot my system)

Try to back up and reset it:

sudo cp -f /boot/grub2/grubenv{,.bak}
sudo cp -f /boot/efi/EFI/fedora/grubenv{,.bak}
sudo grub2-editenv create

I guess that’s the root cause of this thread.

2 Likes

Thanks for you help! I will give it try and report back. Though I am a bit scared touching that grub stuff.

Any idea what could have invalidaded or corrupted my environment block?

Why are there two grubenvs? One in /boot/grub2, one in /boo/efi/EFI/fedora. Isn’t one simply a smylink to the other location?

On my F30 (freshly-installed, no version upgrades) /boot/grub2/grubenv is just a symlink to /boot/efi/EFI/fedora/grubenv.

/boot/grub2 is the location used by default in non-UEFI (i.e. legacy/BIOS) systems, the second location is used on UEFI systems. I think (I don’t know for sure) that symlink is there just in case, for compatibility reasons.


Also if you haven’t run the commands @vgaetera provided, can you post here the contents of your OLD grubenv?

sudo less /boot/efi/EFI/fedora/grubenv

If you already did replace yours, then just look at it (no need to post it here). It’s just a text file with some grub saved settings, nothing scary or extraordinary.

Edit:

And the reason I ask you to post the contents here is for us to see if we can spot something specific in the old grubenv file which could make grub2-mkconfig to behave correctly in non-BLS mode but error out with BLS mode turned on.
It can be useful… if it’s some pitfall in grub behaviour, especially when updating from non-BLS configuration to a BLS-enabled one.


I second @vgaetera’s suggestion, you should regenerate your grubenv. I’m also quite sure (though I’ve not checked it and I can be wrong, of course) that if you just delete grubenv file then reboot, you’ll boot as usual and grub will recreate grubenv in the process. Still @vgaetera offers a safer way.

Also please check if /boot/grub2/grubenv is a symlink or not:

[user@host ~]# sudo file /boot/grub2/grubenv
/boot/grub2/grubenv: symbolic link to ../efi/EFI/fedora/grubenv

Also ls -lh shows clearly if a file’s a symlink or not.

If it already is, then you don’t need to run this command:

Skip it and move to the next one.

If it isn’t a symlink but an ordinary file, then you can delete it an make a symlink in it’s place (to correspond to clean Fedora installation):

sudo ln -s /boot/efi/EFI/fedora/grubenv /boot/grub2/grubenv
2 Likes

I guess one issue could be that that the menuentry grubenv is terribly old…

ppy --fs-uuid --set=root --hint-bios=hd0,gpt5 --hint-efi=hd0,gpt5 --hint-baremetal=ahci0,gpt5  41e507d5-6d33-4eda-9de2-ce3c235de62b
	else
	  search --no-floppy --fs-uuid --set=root 41e507d5-6d33-4eda-9de2-ce3c235de62b
	fi
	linuxefi /vmlinuz-4.10.17-200.fc25.x86_64 root=/dev/mapper/fedora00-root ro rd.lvm.lv=fedora00/root rd.luks.uuid=luks-3667a487-2cde-4f4c-b35a-5225ca21f846 rhgb quiet 
	initrdefi /initramfs-4.10.17-200.fc25.x86_64.img
}
menuentry 'Fedora (4.10.16-200.fc25.x86_64) 25 (Workstation Edition)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-4.10.16-200.fc25.x86_64-advanced-521483f4-c7c6-416a-8637-8ac781e642e4' {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_gpt
	insmod ext2
	set root='hd0,gpt5'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt5 --hint-efi=hd0,gpt5 --hint-baremetal=ahci0,gpt5  41e507d5-6d33-4eda-9de2-ce3c235de62b
	else
	  search --no-floppy --fs-uuid --⏎    

Also, I am wondering what the ‘⏎’ does there (last character of the file) - something wrong there?!

(the ⏎ appears when I do a cat …, when I do a less it is not shown).

When I compare that grubenv to the one on my other machine (running F30 as well), it shows that something along the way really went wrong. The other grubenv is looking completely different:

# GRUB Environment Block
saved_entry=4987cf6957c14e259dcb95cb73abc04c-5.2.6-200.fc30.x86_64
boot_success=1
boot_indeterminate=0
kernelopts=root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/root rd.luks.uuid=luks-1bfe4e4e-b485-4efa-a129-00299538d194 rhgb quiet 
############################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################
/boot/efi/EFI/fedora/grubenv (END)

As a matter of documentation, here is what I did:

1.) Backup the existing grubenv file, then create new one (I have verified that /boot/grub2/grubenv is simply a symlink to /boot/efi/EFI/fedora/grubenv):

sudo cp -f /boot/efi/EFI/fedora/grubenv{,.bak}
sudo grub2-editenv create

After that, grubenv looks pretty empty (just filling up the 1024 bytes of pre-defined length with “#”) :

# GRUB Environment Block
#######################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################

2.) Now, I am setting GRUB_ENABLE_BLSCFG=true (/etc/default/grub)

3.) Then, I am going to re-generate my grub.cfg:
sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

Output:

Generating grub configuration file ...
Found Windows Boot Manager on /dev/sda2@/EFI/Microsoft/Boot/bootmgfw.efi
Adding boot menu entry for EFI firmware configuration
done

I am missing my Fedora kernels here… (this will turn out to be fine, grubby --info ALL has them all)

4.) I use sudo dnf update --exclude="iwl*" to install the latest kernel (5.2.6)

5.) I can confirm that I am seeing something similar now in my /boot/efi/EFI/fedora/grub.cfg

6.) I have verified what was recommended here and it looks good to me. So, I am going to reboot.

Probably the file is damaged.
Unmount the filesystem, perform block-level backup and force error check.

I guess re-creating the grubenv file fixed the problem and grub2 with enabled blscfg seems to work fine.

I am not familiar with both block level back-up (dd?) or error check (fsck on fat?), so I am going to start a new topic…

Thanks for you help!

1 Like

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.