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

Project Discussion
1

Hi!
I am posting here in discussions, to complete the answers from ask.fedoraproject.
I wondered if there was already an official roadmap/will towards the idea of integrating system snapshots in the bootloader in the next fedoras, based on btrfs?
Opensuse has a clear way of implementing system snapshots appearing in the bootloader / grub.
Fedora Silverblue, in its own style also has something similar (picking the branch in grub at boot)
That is very precious to recover the distribution when graphics failed after an update… Just reboot in a read only snapshot selected from the bootloader…
Is there any wish/plan/roadmap towards such an (optional) easy implementation in Fedora (with eventually the tweaking of timeshift or snapper?) in a simplistic way for most users?
There has been some hints of such plan here:
https://fedoraproject.org/wiki/Changes/BtrfsWithFullSystemSnapshots
and here:

I am still wondering if snapshots reachable in grub (à la Silverblue, or Opensuse) are considered by the main Devs team as a short term target?

2 Likes
2

Would be very useful!

3

Some folks might find this video tutorial useful for setting it up with the dnf snapper plugin with fairly minimal changes, i.e. it’s not invasive.

There are some gotchas to be aware of with the current layout and doing rollbacks. It rolls back anything in the root subvolume, which includes /var/lib/libvirt/images (your VM images) and your logs.

If you don’t like that idea you can retrofit the layout, example fstab:

UUID=$btrfsuuid  /                         btrfs   compress=zstd:1   0 0
UUID=$btrfsuuid  /home                     btrfs   subvol=home       0 0
UUID=$btrfsuuid  /var/log                  btrfs   subvol=logs       0 0
UUID=$btrfsuuid  /var/lib/libvirt/images   btrfs   subvol=libvirtimages     0 0

The reason this works is because a snapshot of subvol=root will no longer include /var/log or /var/lib/libvirt/images. This is the case whether using the flat layout described above and in the video, or using the nested layout. Snapshots are not recursive, they stop at subvolume boundaries.

The high level overview of how you do it is:

mount /dev/vda3 /mnt
cd /mnt
btrfs sub create log
chcon "system_u:object_r:var_log_t:s0" log
cp -a root/var/log/* log/
btrfs sub create libvirtimages
chcon "system_u:object_r:virt_image_t:s0" libvirtimages
chattr +C libvirtimages
cp -a root/var/lib/libvirt/images/* libvirtimages/
nano /etc/fstab
reboot

After the reboot you can check df and/or mount that all the new subvolumes are mounted onto their respective mount points as you defined in fstab. Next comes cleanup of the old stuff.

mount /dev/vda3 /mnt
cd /mnt
rm -rf /mnt/root/var/lib/libvirt/images/*
rm -rf /mnt/root/var/log/*

Now those are just empty dirs used as mount points for their respective subvolumes.

Note 1: If you’re using swapfiles, use the same concept as for VM images. Create a swaps subvol, chattr +C, mount it at /var/swap and create the swapfiles per man 5 btrfs swapfiles section. Instead of copying an existing swapfile, delete it, and create new.

Note 2: The / mount point in fstab is special. In effect it’s a “remount” command. It’s not possible to remount and change subvolumes. The default fstab shows subvol=root but this can only be informational and is something of an artifact of the installer. It doesn’t hurt anything to leave it there, but it might be confusing. Conversely, the compress mount option can be set with remount. And it’s a file system wide mount option, not per subvolume.

4

Nice informations, thank you to take the time to detail it!
Does these instructions make the snapshots available at boot in Grub?

5

No. That’s trickier because right now we can’t startup while read-only. There are too many services that expect /var to be writable and due to the read-only snapshot, it won’t be writable. We could use overlayfs to make it read-write using /run as a volatile upperdir, similar to a Live OS boot.

2 Likes