BootPrep 2.0: Making Snapper Rollbacks Bootable on Debian and Arch

[u/mcsgeek]

On many Debian- and Arch-based distributions, Snapper can create rollback snapshots, but the system does not provide openSUSE-style integration to prepare the rollback result as the next writable root. Their common nested Btrfs snapshot layouts require additional boot preparation that Snapper alone does not perform.

BootPrep fills that gap. It provides a Snapper rollback plugin that prepares the resulting writable snapshot for the next boot, plus a direct activation workflow for booting an existing snapshot without performing a rollback. It integrates with the system's existing Btrfs, Snapper, GRUB, and UEFI configuration without requiring a filesystem redesign.

Compatibility testing:

• Debian
• Ubuntu
• Kubuntu
• Manjaro - installed with GRUB
• CachyOS - installed with GRUB
• EndeavourOS - installed with GRUB

For the Arch-based distributions, GRUB was explicitly selected as the bootloader during installation, since BootPrep currently targets GRUB.

The same two test cases were performed on all six distributions: 

1. Direct snapshot activation: I created a Snapper snapshot, used bootprep-btrfs activate <snapshot-number> to activate that existing snapshot directly, rebooted, and verified that / was running from the selected snapshot as a writable Btrfs root.
2. Native Snapper rollback: I performed a normal snapper rollback, allowed the BootPrep Snapper plugin to detect and prepare the resulting writable snapshot, rebooted, and verified that / was running from the expected rollback snapshot and was writable.

So far, both workflows have completed successfully on all six distributions.

How the sausage is made:

• BootPrep no longer patches the 10_linux template and does not directly modify the EFI stub. Instead, BootPrep mounts and chroots into the requested snapshot subvolume, runs grub-mkconfig and grub-install from within that environment, and reconciles the /.snapshots and /home/.snapshots subvolumes to ensure they are mounted correctly on the next boot.
• This prepares the system to boot into the next snapshot selected by either the Snapper plugin or bootprep-btrfs activate <snapshot-number>.
• BootPrep currently targets Btrfs + Snapper + GRUB on UEFI systems. The installer also validates the GRUB configuration it requires and fails safely if a compatible configuration can't be found, rather than completing an installation that will fail later when BootPrep is used.

GitHub: https://github.com/mcsgeek/bootprep

There are still more distributions I'd like to test, so I'm intentionally limiting compatibility claims to configurations I've actually exercised.

I'd be interested in hearing from other Btrfs/Snapper users, particularly about their testing with BootPrep on other distributions with similar Btrfs layouts.

[u/todd_dayz]

You can just do this by creating a read-write snapshot and then use btrfs set-default and reboot 

You mount the drive as / in fstab and the default volume will mount as the rootfs. 

[u/mcsgeek → u/todd_dayz]

That can work depending on the boot configuration, but btrfs subvolume set-default alone may still leave the bootloader pointing to the original root. BootPrep sets the default subvolume, prepares the boot configuration for the selected snapshot, and reconciles /.snapshots and /home/.snapshots for the next boot.

[u/todd_dayz → u/mcsgeek]

And how does the bootloader point at the original root?

[u/mcsgeek → u/todd_dayz]

GRUB points to it through the rootflags=subvol=@ kernel parameter in the normal boot entry. That tells the kernel to mount the @ subvolume as /.

A snapshot boot entry instead uses the snapshot’s subvolume path, for example rootflags=subvol=@/.snapshots/123/snapshot.

So the bootloader isn’t relying on the Btrfs default subvolume to find the original root — the subvolume path is explicitly passed in the kernel command line.

[u/todd_dayz → u/mcsgeek]

Right, I’m saying you don’t need that kernel parameter at all, you can leave it empty because then it falls to the BTRFS default subvolume. 

[u/mcsgeek → u/todd_dayz]

Yes, that would work if GRUB is configured to omit the subvolume and always follow the Btrfs default. BootPrep is designed to work with configurations where GRUB explicitly identifies the root subvolume rather than requiring users to change that configuration.

BootPrep isn't claiming that no possible GRUB configuration can boot a set-default snapshot by itself. It's providing the additional integration needed on the configurations it targets, where grub-mkconfig explicitly identifies the root subvolume.

[u/todd_dayz → u/mcsgeek]

Right, but what I mean is why not just remove the subvol param from the GRUB cmdline? Then you wouldn’t need to rebuild and you could I just poll snapper for the snapshot id and create a r/w copy of it?

[u/mcsgeek → u/todd_dayz]

That would work if the system is intentionally configured to boot from the Btrfs default subvolume, but that would be a different design assumption.

If subvol= is removed and no default subvolume has been explicitly set, Btrfs normally mounts the top-level subvolume (ID 5). On a system where the actual root is something like @, that isn't equivalent to booting @.

One of BootPrep's design goals is not to require changes to the system's normal boot behavior in advance. The existing GRUB/subvolume configuration remains business as usual, and BootPrep only changes what is necessary when a snapshot actually needs to be prepared for boot.

[u/mcsgeek → u/mcsgeek]

In other words, part of BootPrep's design is that it can be installed and simply exist before ever living inside a snapshot. The system can continue booting normally until a default subvolume is selected by a Snapper rollback, a Btrfs command, or bootprep-btrfs activate.

[u/Ok_Pudding3814]

This is actually pretty neat, I always wondered why rollbacks on Debian felt so incomplete compared to openSUSE

The chroot approach for grub-mkconfig makes way more sense than patching templates, that always felt fragile to me

Have you tested with systemd-boot at all or is GRUB a hard requirement for now

[u/mcsgeek → u/Ok_Pudding3814]

I have only tested with GRUB for now, and currently the installer considers GRUB a requirement. I haven't tested systemd-boot yet, but it's something I'd consider for future development.

[u/GreedySecurity8030]

Not fedora?

[u/mcsgeek → u/GreedySecurity8030]

Fedora uses a different Btrfs layout that's similar to openSUSE's. I used Fedora 40 with Snapper previously, and rollback worked without the additional boot preparation BootPrep provides, so Fedora may not need BootPrep for this use case.

[u/TomHale]

Please work with systemd-boot. Grub is like LILO.

[u/mcsgeek → u/TomHale]

I started with GRUB because I personally use grub-btrfs so I can select a snapshot for recovery. It initially boots read-only, but then I can use bootprep-btrfs activate <snapshot-number> to make it the default, writable root and prepare it for the next boot.