Is there a "plan" to integrate BTRFS snapshots in Fedora ( that appear in bootloader / grub )?

I manage a quite a few Fedora Linux systems and (in the last five’ish years), I only had one case where I really needed to boot from a recovery snapshot of a Fedora Linux OS. Thankfully I had ZFS on root configured and I was able to rollback the root file system. The workstation had been hacked. There was some sort of elaborate self-spawning executable that would rename and respawn itself if you tried to stop/delete it. it was transmitting data to China. It got in due to a misconfigured PAM stack and an SSH port that was not properly firewalled. To separate the data we wanted to recover from the system from the virus/malware, it was a simple matter to rollback the root file system.

I’ve also seen many posts here on ask.fp.o where dnf updates have gone wrong (e.g. here and here) and being able to rollback the installation would have been much easier than the alternative of trying to get all the packages resynchronized. It is rare, but it can really be a lifesaver when you need it.

1 Like

It is also trivial to increase that number should you want to. It is the installonly_limit setting in /etc/dnf/dnf.conf. However, you will be limited by the size of the ESP as to how many kernels/recovery points you can keep. On my PC, I currently have this set to keep recovery snapshots for the last six kernels/OSs and that is using 334M.

[/home/gregory]$ df -h /boot
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1      1022M  334M  689M  33% /boot

I have mine set to 4 but I have two kernels installed

df -h /efi                                                                                                                            
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p1  949M  661M  288M  70% /efi

I don’t know why 2 kernels would use more than six, but FWIW, here is a more detailed look at my ESP:

[/root]# find /boot -printf '%p %s\n' | numfmt --field=2 --to=si
/boot 4.1K
/boot/8c76d196c474411a85814e376f2c30c4 4.1K
/boot/8c76d196c474411a85814e376f2c30c4/5.12.13-300.fc34.x86_64 4.1K
/boot/8c76d196c474411a85814e376f2c30c4/5.12.13-300.fc34.x86_64/initrd      48M
/boot/8c76d196c474411a85814e376f2c30c4/5.12.13-300.fc34.x86_64/linux      11M
/boot/8c76d196c474411a85814e376f2c30c4/5.12.12-300.fc34.x86_64 4.1K
/boot/8c76d196c474411a85814e376f2c30c4/5.12.12-300.fc34.x86_64/initrd      48M
/boot/8c76d196c474411a85814e376f2c30c4/5.12.12-300.fc34.x86_64/linux      11M
/boot/8c76d196c474411a85814e376f2c30c4/5.12.14-300.fc34.x86_64 4.1K
/boot/8c76d196c474411a85814e376f2c30c4/5.12.14-300.fc34.x86_64/initrd      48M
/boot/8c76d196c474411a85814e376f2c30c4/5.12.14-300.fc34.x86_64/linux      11M
/boot/8c76d196c474411a85814e376f2c30c4/5.12.15-300.fc34.x86_64 4.1K
/boot/8c76d196c474411a85814e376f2c30c4/5.12.15-300.fc34.x86_64/initrd      48M
/boot/8c76d196c474411a85814e376f2c30c4/5.12.15-300.fc34.x86_64/linux      11M
/boot/8c76d196c474411a85814e376f2c30c4/5.12.17-300.fc34.x86_64 4.1K
/boot/8c76d196c474411a85814e376f2c30c4/5.12.17-300.fc34.x86_64/initrd      48M
/boot/8c76d196c474411a85814e376f2c30c4/5.12.17-300.fc34.x86_64/linux      11M
/boot/8c76d196c474411a85814e376f2c30c4/5.12.11-300.fc34.x86_64 4.1K
/boot/8c76d196c474411a85814e376f2c30c4/5.12.11-300.fc34.x86_64/initrd      47M
/boot/8c76d196c474411a85814e376f2c30c4/5.12.11-300.fc34.x86_64/linux      11M
/boot/efi 4.1K
/boot/efi/boot 4.1K
/boot/efi/boot/bootx64.efi   92K
/boot/efi/syslinux 4.1K
/boot/efi/syslinux/ldlinux.e64   148K
/boot/efi/syslinux/libcom32.c32   186K
/boot/efi/syslinux/libutil.c32   25K
/boot/efi/syslinux/syslinux.efi   197K
/boot/efi/syslinux/vesamenu.c32   40K
/boot/efi/systemd 4.1K
/boot/efi/systemd/systemd-bootx64.efi   92K
/boot/efi/efi 4.1K
/boot/efi/efi/boot 4.1K
/boot/efi/efi/fedora 4.1K
/boot/loader 4.1K
/boot/loader/entries 4.1K
/boot/loader/entries/8c76d196c474411a85814e376f2c30c4-5.12.15-300.fc34.x86_64.conf 351
/boot/loader/entries/8c76d196c474411a85814e376f2c30c4-5.12.13-300.fc34.x86_64.conf 351
/boot/loader/entries/8c76d196c474411a85814e376f2c30c4-5.12.14-300.fc34.x86_64.conf 351
/boot/loader/entries/8c76d196c474411a85814e376f2c30c4-5.12.17-300.fc34.x86_64.conf 351
/boot/loader/entries/8c76d196c474411a85814e376f2c30c4-5.12.11-300.fc34.x86_64.conf 351
/boot/loader/entries/8c76d196c474411a85814e376f2c30c4-5.12.12-300.fc34.x86_64.conf 351
/boot/loader/random-seed 512
/boot/loader/loader.conf 55
/boot/grub2 4.1K
/boot/grub2/themes 4.1K
/boot/grub2/themes/system 4.1K
/boot/syslinux.cfg 957

Because I have 4 versions of each kernel.

On that machine, I am also dual-booting Arch out of a single zpool but that is a different story…


Out of frustration due to the lack of btrfs integration, I wrote a little tool called btrfs-upgrade-snapshot-service. It comes with an rpm package that you just have to install, then it’ll try to find your btrfs root filesystem and set up a service that automatically creates a snapshot whenever the system is upgraded to the next release. So if you’re experiencing difficulties after an upgrade (something is broken or disappeared), you’d run btrfs-os-snapshot restore <NAME> and after a reboot, you’d have your old system back.

To install it, download and install the rpm file and run btrfs-os-snapshot list once just to make sure it found your btrfs filesystem. It would complain if your system isn’t compatible. If it doesn’t complain, it’s installed and ready.

You can also use it to create snapshots manually as described here:

It only handles snapshots of the root filesystem and it includes and restores /boot which is usually a separate ext partition that’s sometimes forgotten. It doesn’t do much more but I hope it helps someone out there. I also hope this doesn’t count as spam.