Btrfs Assistant - No boot option for snapshots

I would like to have an option to boot a specific snapshot, like on openSUSE.

I use Btrfs Assistant on Fedora 43 KDE (full disk encryption; Secure Boot is disabled in case it matters).

I attached some screenshots of my settings below.

In my GRUB menu, I only have 5 options: 3 kernels, one “emergency mode” boot option and UEFI. But no option to boot a snapshot. I’m not 100% sure, but I think I had an option in the past.

My /etc/default/grub:

GRUB_TIMEOUT=2
GRUB_TIMEOUT_STYLE=menu
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="rd.luks.uuid=luks-c8c8762a-ff5c-4fb0-8c3b-c03fef298df4 rhgb quiet resume=UUID=6153a88e-556d-4dc9-a031-327ea83259fd resume_offset=3155200 loglevel=0"
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true

My Btrfs Assistant setting:

If you made a default installation you can not use the Btrfs Assistant for that. Because the /boot partition is still on ext4.

If you want to have it as on other distributions, you need to manually configure it.

Btw. it is Snapper which makes to snapshots. Here an example, without any guarantee :stuck_out_tongue:

1 Like

Okay, makes sense. Thank you!

But I could still roll back my root partition manually, e.g. when an update didn’t work properly? I don’t think anything broken would be stored on /boot, right? (besides kernels, but 3 of them are saved, shouldn’t really matter).

/dev/nvme0n1p3: UUID="c8c8762a-ff5c-4fb0-8c3b-c03fef298df4" TYPE="crypto_LUKS" PARTUUID="fe521dfa-9c8f-4d0f-ac8d-01f2ba9d8c4d"
/dev/nvme0n1p1: UUID="1414-88CD" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="cb896b75-f1e2-4b91-93fe-74ac57e1b176"
/dev/nvme0n1p2: UUID="d09647cb-7b32-4890-8b0e-ab2cd71bd18c" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="e41c080d-9b2f-4975-8f46-c14f49b56ef9"
/dev/mapper/luks-c8c8762a-ff5c-4fb0-8c3b-c03fef298df4: LABEL="fedora" UUID="6153a88e-556d-4dc9-a031-327ea83259fd" UUID_SUB="8c221345-3765-4974-a2ec-4fc5a71ea9c2" BLOCK_SIZE="4096" TYPE="btrfs"
/dev/zram0: LABEL="zram0" UUID="0b48bfca-97e9-4e56-852a-5450ef7a44c3" TYPE="swap"

Yes, you can absolutely roll back the root subvolume manually, and for most cases it works well.

The main thing to understand is what actually lives where. Your /boot is on the ext4 partition and is not included in any Btrfs snapshot. So when you roll back the root subvolume, you are restoring /usr, /etc, /var (to whatever your subvolume layout covers), but not the kernels or initramfs in /boot. This is fine for most update problems.

The scenario where it gets tricky is if you roll back through a kernel update. If you restore a snapshot from before, say, kernel 6.19 was installed, but /boot still has 6.19’s initramfs as the default entry, GRUB will load that kernel but the modules it needs (/lib/modules/6.19.x) are back in the snapshot. The kernel and modules need to match. In that case, pick an older kernel from the GRUB menu when booting, not the newest one.

For everything else like a bad DNF update to user packages, libraries, or configs, rolling back is straightforward:

Boot a live system or a known-good kernel. Then:

sudo mount /dev/mapper/luks-... /mnt
sudo btrfs subvolume list /mnt

Find your current root subvolume (likely @) and the snapshot you want to restore. Then:

sudo mv /mnt/@ /mnt/@.broken
sudo btrfs subvolume snapshot /mnt/snapshots/2026-04-01_00:00:01/snapshot /mnt/@
sudo umount /mnt
reboot

After rebooting into the restored snapshot, run grub2-mkconfig to make sure the GRUB config reflects any package state differences. You can delete @.broken once you confirm things are working.

So yes, the lack of GRUB boot-from-snapshot integration is inconvenient, but it does not prevent manual rollbacks. It just takes a couple of commands instead of a menu click.

1 Like

There’s a lot more to it than just installing btrfs assistant. Here is an article I saved that shows all the steps necessary to make this work:

2 Likes