How to Rollback Grub boot menu after Btrfs root rollback?

So, I installed btrfs-assistant and setup / (root) and /home subvolume snapshots, and took a snapshot of the / subvolume.

Then, to test Btrfs rollback, I upgraded to Fedora 41 (from 40), rebooted, verified I was in Fedora 41 by cat /etc/os-release.

Then, I went into btrfs assistant, and rolled back to the snap I created before the upgrade, and rebooted.

Now, the boot entry for Fedora 41 kernel version is still in Grub2 boot menu, and I can’t figure out how to regenerate the Grub entries so that F41 is no longer in the list?

The first thing I tried was:

# grub2-mkconfig -o /boot/grub2/grub.cfg

Then after that completed, rebooted, but no change.

I then tried deleting all the fedora 41 entries under /boot (since that’s a separate partition, and I figured maybe the grub2-mkconfig stuff might scan /boot to find entries to add, then re-running grub2-mkconfig, but that didn’t change anything, either.

I’ve tried web searches and searching the forums here and not finding anything related to this. What is the ‘correct’ way to re-build the grub boot menu after rolling back a snapshot of a btrfs root filesystem, so that it once again matches the root filesystem state?

On my system, those menu entries are stored under /boot/loader/entries:

[/home/gregory]$ sudo ls /boot/loader/entries

Does deleting the fc41 files from there clear them from the GRUB boot menu?

As far as I know, Btrfs Assistant is based on snapper, and snapper is a tool developed by openSUSE. In openSUSE the /boot directory is set to be a Btrfs subvolume. I think this must be the reason why rollbacks in Fedora can’t restore the GRUB menu. I’m not sure, but you can make any edits you want with applications like grub-customizer.

It’s also worth making sure that you mount /.snapshots directory with the subvolume root/.snapshots created by Btrfs-Assistant (snapper) root config.

Thanks. But I have a question - shouldn’t those entries be automatically managed by. . . something in Fedora? What is that thing, and how do I re-run it to get it to update the entries?

Snapper is included as part of it …

But you don’t know and are recommending to someone to try something you yourself admit to not understanding. Please refrain from offering non-help.

1 Like

The problem is that Fedora by default creates a separate “/boot” partition. You can read more about it here: BTRFS restore with ext4 formatted /boot - #2 by chrismurphy

Yes, I’m well aware. There’s multiple reasons to have /boot on a separate, non-btrfs volume. But, at the same time, if I rollback the btrfs root, I need a way to regenerate the stuff on /boot to make it once again correspond to what’s installed in the current version of /.

When dnf or the Gnome “Software” app install kernel updates, they add new entries and remove old entries. I’m looking for a command to run to have the boot entries regenerated based upon what is actually, currently installed, in terms of kernel versions, for the version of / that I have switched to.

Of particular interest is setting the ‘default’ kernel to boot to the correct kernel so that after a rollback, I don’t have to forever afterwords manually changed to a different kernal on reboot.

The content of /boot/loader/entries is managed by the script found at /usr/lib/kernel/install.d/90-loaderentry.install. The script is called whenever a kernel-core package is installed or removed. When a kernel is installed, it is called with parameters add <kver> ... and when a kernel is removed it is called with remove <kver> ....

You could run, e.g., kernel-install remove 6.8.4-200.fc39.x86_64 if you wanted to remove the kernel content related to a given kernel version under /boot. kernel-install is the higher-level script that, in turn, calls the various scripts under /usr/lib/kernel/install.d. See the man page for further details (man kernel-install).

Thank you. I will give this a try.

So, I ended up going ahead and manually removing the entry for the f41 kernel under the dir:


then re-running grub2-mkconfig (not sure if the latter step was necessary).

This is because, I couldn’t actually run kernel-install remove, I don’t think, because the kernel had already been removed (I got some error, anyhow, not sure if that was because the rpm wasn’t present, or some other reason).

I think if Fedora Workstation wants to be a system built on btrfs, it needs a better, fully automated, answer for allowing people to automatically fix up /boot and grub after a rollback or roll-forward to a given snapshot. That answer can’t depend on uninstalling rpms, because once the root fs has been rolled back, effectively all the rpms have been uninstalled or downgraded to previous versions.

1 Like