Using Refind-Btrfs After Rollback

[nalin29]

I have completed a successful rollback of my BTRFS sub-volume @ from a snapper snapshot. I followed the guide on the arch wiki where I delete the original @ subvolume and set @ as a new subvolume that is a read-write snapshot of one of the snapper snapshots. As a result refind-btrfs no longer works since it complains:

Initializing the block devices using lsblk. Initializing the physical partition table for device '/dev/nvme0n1' using lsblk. Initializing the live partition table for device '/dev/nvme0n1' using findmnt. Initializing the physical partition table for device '/dev/nvme1n1' using lsblk. Initializing the live partition table for device '/dev/nvme1n1' using findmnt. Found the ESP mounted at '/boot/efi' on '/dev/nvme1n1p1'. Found the root partition on '/dev/nvme1n1p5'. Searching for snapshots of the '@' subvolume in the '/.snapshots' directory. Found subvolume '@' mounted as the root partition. ERROR (refind_btrfs.state_management.refind_btrfs_machine/refind_btrfs_machine.py/run): Subvolume '@' is itself a snapshot (parent UUID - 'a9e20879-1b4b-f44b-b4ad-81f9ef6b9802'), exiting... So this seems like intended behavior. Is there a way I can rectify this so refind-btrfs will continue to happily generate its own read-write snapshots from snapper snapshots of @ either ignoring that @ is a snapshot or by changing @ to no longer be a snapshot.

[nalin29]

My bad I missed that the config file can be specified to allow refind-btrfs to work even if the specified sub-volume is a snapshot. However, there are warnings stating that this is incorrect and possibly unstable behavior. Why is this the case and what is the expectation if a user was to do a rollback to avoid setting this config flag?

[Venom1991]

Like it says in the comment, I haven't really tested that feature thoroughly enough. If it works for you then great. I personally don't have a need for it but the option is there should someone, like you, want to try it out. Turning it off shouldn't really break anything.

The problem with the current implementation is that the process starts anew when you boot a snapshot, creating snapshots from the "new" root subvolume (the snapshots which you've just booted into) while disregarding snapshots which were created for what is by that point the "previous" root subvolume ('@').
It'd be better to somehow combine these two (or possibly even more) branches of snapshots into a single one and present them in the generated boot stanza. However, this is not a trivial thing to accomplish and I simply cannot find the time to work on it right now.

[nalin29]

Yeah, that makes sense looking at the code all it may do is delete and add boot stanzas and rw subvolumes that are snapshots of the booted subvolume. I guess a trivial way of preventing this would be to just disable the check that a snapshot is a snapshot of the current root and instead consider all snapshots.

How do you if it is possible rollback without creating a snapshot of a snapshot as root?

[Venom1991]

I guess a trivial way of preventing this would be to just disable the check that a snapshot is a snapshot of the current root and instead consider all snapshots.

The problem with this approach is that snapshots in Btrfs are not recursive which means that nested subvolumes are not taken into consideration whilst creating a snapshot of the parent subvolume.
I've personally isolated Snapper's snapshot output directory into a separate subvolume which means that it is not trivial to discern the actual, system-wide number of snapshots without regard for the currently booted subvolume (it being a snapshot or a "proper" subvolume).

How do you if it is possible rollback without creating a snapshot of a snapshot as root?

Could you perhaps rephrase this question? I don't quite understand what you're asking here.

[nalin29]

Could you perhaps rephrase this question? I don't quite understand what you're asking here.

The standard procedure of rolling back the root requires deleting the old root (@) and replacing it with a rw snapshot of a previous root snapshot.

I am asking if there is an alternative to this procedure for rolling back that you specifically utilize in order to prevent the issue where (@) is a snapshot?

[Venom1991]

In that case, starting from scratch actually makes sense because you most probably want to "forget" about the original root subvolume's snapshot, altogether. This use-case should be covered as-is and the config warning is then perhaps unnecessary altogether.

I've personally never had to recover the root subvolume from a snapshot and start anew from that point onward. All I was forced to do a few times was to mount the problematic root subvolume by booting into a snapshot and performing manual work on said mounted root subvolume after which I could boot into it instead of its snapshot.

[nalin29]

Got it. Thank you.