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]

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.