👋 Welcome to the BootPrep Community

[mcsgeek]

👋 Welcome to the BootPrep Community

Welcome, and thanks for your interest in BootPrep!

BootPrep is the activation layer for systems using a default nested Btrfs subvolume layout. It prepares the boot environment so a selected writable Snapper snapshot can become the next bootable system while preserving the existing filesystem layout.

This is the place to:

• Ask questions about BootPrep or its companion utilities.
• Discuss ideas and future enhancements.
• Share testing results on different distributions and configurations.
• Share successful deployments and compatibility experiences.
• Discuss Btrfs, Snapper, GRUB, and BootPrep architecture and integration.

Questions about the companion utilities are also welcome here:

• cleanup-bootstrap-root
• add_subvolumes
• add_updategrub-service
• dpkg-pre-post-snapper
• snapshot-chroot

If you've found a reproducible bug or have a specific enhancement request, please open a GitHub Issue instead.

Whether you're here to learn, test, contribute, or simply follow the project's progress, you're welcome here.

I'd especially love to hear about the distributions, nested Btrfs layouts, and configurations you've successfully tested with BootPrep.

[mcsgeek]

Ask me how I got here. 🙂

Debian booted directly into an existing writable Snapper snapshot using bootprep-btrfs activate, without performing a Snapper rollback.

[ruijjmendes-bit]

Hi,
Very nice tool, but I have a question: does it works only with nested subvolumes layout like openSUSE or does it work also with flat layouts like Archlinux?

[mcsgeek]

Hi, thanks!
BootPrep is not limited to nested subvolume layouts. It also works with flat layouts.
I’ve tested it successfully on Debian/Ubuntu-style layouts as well as Arch-based systems including Manjaro, CachyOS, and EndeavourOS using GRUB. It is layout-aware and works from the actual root subvolume in use rather than assuming an openSUSE-style layout.
I have not tested Arch Linux itself yet, so I don’t want to claim Arch compatibility specifically, but flat-layout support has been exercised on other distributions.

[ruijjmendes-bit]

Awesome, that's what I need. I'm gonna try it with Debian Trixie with a flat layout.

[mcsgeek]

Thanks for the detailed test and for posting the before/after state.

This is especially useful because your setup is a flat top-level Btrfs layout: @, @var, @var_lib_bootprep, @home, and @.snapshots are all sibling subvolumes at top level. Even though /var/lib/bootprep is mounted beneath /var in the filesystem namespace, its Btrfs subvolume is not actually nested under @var.

It looks like BootPrep handled the snapshot/rollback/GRUB-default workflow correctly while preserving those independent mounts, which is very useful validation.

I really appreciate you taking the time to test it and document the results.

[ruijjmendes-bit]

No need to thank me: your script solved the problem I was having with Snapper not booting into the default GRUB option.

At work, we’ve recently started testing Snapper following a disastrous upgrade of a Debian server. This prompted us to seriously look into a solution that allows for instant system restoration. I think we’ll migrate to MicroOS in the near future, but for now, we’re sticking with Debian and Ubuntu, which form the foundation of our operations.

Initially, I was thinking of writing a script myself but instead of booting to @.snapshots/5/snapshot it wold rename the '@' subvolume to something like @_old-<timestamp> and create a new rw snapshot from snapper @.snapshots/5/snapshot named @. I don't know what advantages it might offer beyond improved readability in snapshot listings.

Another thing:
Would it be difficult or complicated for "dpkg-pre-post-snapper" to include the subvolid in the "Description" for grub's snapshots menu? At first glance, the place to add another column would be GRUBER-BTRFS, since otherwise we can only modify the description, right?

[mcsgeek]

Your @ rename idea could work, and one advantage would be keeping the active root at the conventional @ path. I considered approaches along those lines, but BootPrep intentionally avoids changing the existing root topology. Instead it prepares the selected writable Snapper snapshot and points GRUB directly at it. That avoids renaming the current root, creating an additional snapshot, and having to reconcile references to the renamed subvolume. It also leaves the original Snapper snapshot itself as the thing being activated.

For the subvolume ID: yes, I think dpkg-pre-post-snapper could add it to the snapshot Description. After Snapper creates the snapshot and we know its snapshot number, the hook could query the Btrfs subvolume ID and update the description.

If you want the subvol ID as a separate column/field in the GRUB snapshots menu, though, I agree that would really be a grub-btrfs change. From dpkg-pre-post-snapper, modifying the Description is probably the practical option.

I actually like the idea of including the subvol ID in the description. It would make it easier to correlate what Snapper shows, what Btrfs shows, and what GRUB is about to boot.

[ruijjmendes-bit]

Thanks for the explanations. Renaming to "@" would indeed entail an extra snapshot, which isn't desirable. Now I'll dig into a solution for synchronizing the ESP partitions, since I'm using Btrfs's native RAID1.

[mcsgeek]

That subvolid idea is interesting. I’m going to take a closer look at dpkg-pre-post-snapper and see if I can add the Btrfs subvolume ID to the snapshot description cleanly, then test how it shows up through grub-btrfs.

While you’re working on the ESP side, I’ll experiment with that here and report back once I’ve had a chance to test it.