Quite often we get issues with people having strange errors after doing something, wanting to rollback a bad update, or generally issues with a “leading edge” distro like Fedora.
OpenSUSE Tumbleweed and SlowRoll also use BTRFS, and it’s potential to help in such cases.
Fedora uses BTRFS for quite a while, but only having kernel backups make it lack behind a lot. Many use atomic desktops because of that issue, while a middle-way could be possible.
What stands in the way to implement automatic BTRFS system snapshots into dnf? Does dnf5 introduce something new here?
on the whole, I think what ‘stands in the way’ is we’ve mostly decided to put the ‘doing new stuff’ engineering capacity into ostree/immutable/atomic/whatever we’re calling it this week. if someone wanted to work on this, though, I don’t think anyone would be yelling no! don’t do that!
I have used automated BTRFS snapshots with both Debian (Timeshift, no GRUB integration) and Tumbleweed (Snapper), and it is very helpful indeed! Even if the system does not break you sometimes want to roll back after trying stuff out.
People have done this on Fedora 40, e.g. the guide below, but I have not tried it myself yet (so I do not know if the guide is good/safe!).
My Timeshift / Debian installation did not have any GRUB integration and until I did install an apt hook, I just used the Timeshift boot / daily / weekly / … schedule. Still very useful to have “safe points” to revert to. And before “experiments”, I would just do a manual timeshift snapshot.
My point is: even without GRUB integration and dnf hook, timeshift / snapper could be very useful. Of course the full setup would be the ultimate goal.
A Fedora “pitfall” is the separate boot partition. Not good if that goes out of sync with the root fs… Should be doable to move the /boot to the root partition though…
I share this from time to time. I’ll do it again for those who might find this thread.
The above post doesn’t provide any instructions about automating anything, but I think it is probably good for people to learn the lower-level commands that are involved anyway so they can potentially restore their system even if the automation fails.
For automation, I know several of the existing tools are not designed for Fedora Linux, but if someone were determined, they could write their own shell script to take or restore snapshots from Dracut. You could place such a script in one of Dracut’s hooks to automate making snapshots on system startup.
P.S. Looking back at that post, I see that I showed using a systemd-boot path when generating an updated initrd. Most users will need to adapt that path to point to whereever GRUB puts the initramfs image.
So the Fedora BTRFS layout does not just have different names but also prevent functionalities? I didnt know that.
This would mean that Fedora → CentOS → RHEL would need to change the partition layout to have that everywhere? Well, Fedora is the only one using BTRFS, that would be easier.
I agree with enabling snapshot support by default. I’m willing to help with testing in my own small way… One of the issues to address with Fedora’s partition layout is the separate “/boot” partition in ext4. Personally, I resolved this by using advanced partitioning and created a single Btrfs partition with EFI. Currently, I am happily using Btrfs Assistant. Unfortunately, the DNF plugin for creating post- and pre-update snapshots is broken: snapper: creating pre_snapshot failed: error.unknown_config: org.freedesktop.DBus.Error.Failed As far as I remember, the other issue is if updates are initiated via PackageKit.
Another GTK software for snapshot management: Butter
It is an unfortunate problem that is caused by the grub bootloader. Ideally, the bootloader, /loader/entries configuration snippets, kernel, and initramfs would all be on the ESP, but grub does not support such a configuration. Note that trying to put the kernel and initramfs on the Btrfs filesystem is going the wrong way. The kernel should be together with the config snippets (which, on UEFI systems must be on the ESP). Also, if the initramfs is to contain software for decrypting the root filesystem, it obviously cannot be on the encrypted root filesystem. sd-boot (as well as syslinux, refind, ipxe, etc.) will work on a single FAT32-formatted EFI system partition. It is just grub that cannot work within the confines of a single partition. (And being spread across multiple partitions is one of the causes of grub’s fragility. It has to track the different partitions that its pieces are spread across and if those links break for some reason (e.g. a partition was moved and its UUID changed), then the user’s system is rendered unbootable.)
Yeah, anaconda specifically does not require a separate /boot any more (it might warn you about not having one, but it should allow it). If you find any path where it seems to be hard requiring a separate /boot, please report it as a bug.
One thing to note is there is already some work done in this area for other purposes. There’s a thing that marks a boot as being ‘successful’ or ‘not successful’, and this is used for deciding whether to show the grub menu on boot, IIRC. That mechanism could potentially also be used for this (offer a snapshot menu during boot if the previous boot is not marked as successful, or something).
I have not tried that yet. The “problem” is that my standard install of Fedora 40 KDE spin has been so rock solid that I do not want to reinstall - so maybe I will try a custom install of 41, but for now everything just works
Actually, the reason we didn’t do anything was because all the existing strategies were incompatible with the Bootloader Spec. However, the openSUSE folks started working on it a couple years ago, and finally imported our GRUB BLS patches into their GRUB package. As a consequence, they’ve been building a boot-to-snapshot implementation that is compatible with BLS.
The Red Hat solution (boom) has been in a weird maintenance state for a few years now, so we (the Btrfs SIG) hadn’t been able to make progress on an implementation based on it.
At some point, the SIG will have to examine the openSUSE implementation and see how we can port it over to Fedora.
@ngompa when you say “the bootloader spec” do you mean the actual Boot Loader Specification or the thing we use under the name “BLS” which is not really that at all?
There is some awkwardness with the specification itself, but yes even our “BLS” thing too. Though GRUB’s BLS should be much more in-line with the spec these days than it was when it was first introduced in Fedora 30.
