Usable with /@ root volume?

[geckolinux]

Hi there, first of all thanks very much for making this very useful tool!

I'm considering integrating this tool with a distribution, but I can't seem to make it work with this subvolume layout (I'm using the Calamares installer, which doesn't support volumes starting with @ and so I have to preface them with a / )

UUID=2da1548b-529e-4110-a55b-f7e7fa67e797 /              btrfs   subvol=/@,subvolid=5,defaults,noatime,space_cache,autodefrag 0 0
UUID=2da1548b-529e-4110-a55b-f7e7fa67e797 /.snapshots    btrfs   subvol=/@snapshots,defaults,noatime,space_cache,autodefrag 0 0
UUID=2da1548b-529e-4110-a55b-f7e7fa67e797 /home          btrfs   subvol=/@home,defaults,noatime,space_cache,autodefrag 0 0
UUID=2da1548b-529e-4110-a55b-f7e7fa67e797 /root          btrfs   subvol=/@root,defaults,noatime,space_cache,autodefrag 0 0
UUID=2da1548b-529e-4110-a55b-f7e7fa67e797 /var           btrfs   subvol=/@var,defaults,noatime,space_cache,autodefrag 0 0
UUID=2da1548b-529e-4110-a55b-f7e7fa67e797 /tmp           btrfs   subvol=/@tmp,defaults,noatime,space_cache,autodefrag 0 0

ID 257 gen 145 top level 5 path @
ID 258 gen 137 top level 5 path @snapshots
ID 259 gen 138 top level 5 path @home
ID 260 gen 139 top level 5 path @root
ID 261 gen 136 top level 5 path @var
ID 262 gen 145 top level 5 path @tmp
ID 273 gen 43 top level 257 path .snapshots
ID 275 gen 46 top level 258 path @snapshots/1/snapshot
ID 276 gen 74 top level 258 path @snapshots/2/snapshot
...

In the snapper-rollback.conf file I tried:

subvol_main = @   #also tried /@
subvol_snapshots = @snapshots  #also tried /@snapshots
mountpoint = /      #also tried /tmp/whatever

But it throws CRITICAL - Missing /@: Is /dev/sda1 mounted with the option subvolid=5?

However, if I change it to:

subvol_main = /@
subvol_snapshots = /@snapshots
mountpoint = /tmp/whatever
dev = /dev/sda1

... it successfully does a rollback. The problem is that I'm interested in including this for the end-user and I don't want to have to explicitly define the root device. (Unfortunately /dev/root no longer exists). Is there any way to make this work within the limitations I have?

Thanks in advance for your time.

[jrabinow]

Hey there, thanks for reaching out, glad you appreciate the tool and honored to hear you're considering it for a distro.

I'm afraid I have zero bandwidth until June to help you figure this out.

To make sure I understand the problem: you're looking to either let the user define the btrfs root through some GUI in settings, or better yet, have some automatic detection mechanism that magically identifies the btrfs root?
I'm afraid I'm not familiar with /dev/root - if you're aiming to auto-fill the config file, I thought about that but the code can become complex quite quickly - it's not an issue as long as the code is well structured, I just didn't have the time back then.
On the other hand, if this is just about adding a few slashes to the config file, that can be done easily enough but I would like to make sure it works across distros (at least archlinux and openSUSE).

If you're aiming for magic autodetect, I'd want to make sure a couple edge cases are considered (dual-boot, rolling back from a live boot usb), even if that means those edge cases can use command-line flags to override autodetect. Would that work for you?

As I mentioned, I don't have much bandwidth these days, but I'm always happy to look at and give feedback on PRs!

[jrabinow]

Also if Geckolinux has its own package repo, editing the config file to your needs and creating a new package might potentially be another option?

[geckolinux]

Hi there, really appreciate the fast response!

So yes, first of all I'd like to confirm that I'm not doing something wrong or misunderstanding some core concept. I've worked through a lot of intricacies in testing GeckoLinux with Btrfs and Snapper and openSUSE's Snapper/GRUB integration scripts, but I'm still a bit shaky with some of the core Btrfs concepts. While testing the last GeckoLinux release I was hitting an edge case that exposed a bug in openSUSE's GRUB scripts, but I eventually found a hacky but effective way to work around it, and I ended up using openSUSE's standard GRUB integration with Btrfs snapshots and Snapper for rollbacks. Now I'm working on an additional new project based on Debian, and no native Debian blessed methods exist for working with Btrfs snapshots. For the GRUB integration I'll be using https://github.com/Antynea/grub-btrfs, but after a huge amount of testing in both GeckoLinux and in Debian I can't find a workaround for this issue when doing rollbacks with Snapper. (Basically after the first Snapper standard snapper --ambit classic rollback, the grub-btrfs snapshots list stops updating until after running another grub-install. For some reason snapper-rollback doesn't cause this problem, so it's looking like a good candidate.

Do I understand correctly that the reason snapper-rollback doesn't work out-of-the-box for me is due to the /@ and /@ subvolumes that are relative to the filesystem root? If I were to have the subvolumes outside of the root filesystem and then mounted into / then it would work without specifying a /dev/... device? So far I can't find a way to do that with the Calamares installer; the only other option it gives me is to not create a subvolume at all for the / part of the filesystem.

To make sure I understand the problem: you're looking to either let the user define the btrfs root through some GUI in settings, or better yet, have some automatic detection mechanism that magically identifies the btrfs root?

Ideally auto-detection. Calamares takes care of installing the system and the bootloader, and I don't really want the end user to have to deal with any intricacies of the filesystem, especially for an emergency tool like snapper-rollback that might need to be used when the system is really messed up.

Also if Geckolinux has its own package repo, editing the config file to your needs and creating a new package might potentially be another option?

For both GeckoLinux and the additional new distro I'm working on, I always make a point of sticking to upstream package repos so that the installed system isn't dependent on me for maintenance. However I'm happy to simply include a modified version of snapper-rollback directly on the ISO filesystem, as it's very simple and seems like fairly static code. The only thing I can't pre-configure is the dev = value because that depends on the user's partition layout.

So if you confirm that this subvolume scheme that I need to deal with via Calamares will require specifying a /dev = value, then I can think of a few workarounds to fill it automatically. I'm not a good coder, especially not with Python, but I know it's possible to run shell commands from within a Python script. The most parsable methods for finding the root /dev/... seem to be:

• findmnt /
• mount
  Meanwhile, I could probably temporarily use a systemd service/script to link to set the dev = .... device in the snapper-rollback config file. Can you think of any disadvantages of doing it that way? Another option that would work at least for the initial installation would be to set it via a Calamares custom script during installation too.

If you're aiming for magic autodetect, I'd want to make sure a couple edge cases are considered (dual-boot, rolling back from a live boot usb), even if that means those edge cases can use command-line flags to override autodetect. Would that work for you?

Yep, definitely!

Another small improvement I could suggest would be to make it work like the standard Snapper snapper rollback command where, if no snapshot number is specified it simply performs a rollback to the number of the booted RO snapshot.

Thanks again for your time and for the friendly help!

[geckolinux]

Hi again, I was looking at xerolinux-rollback which doesn't seem to work well, but it does have a python function that properly identifies the root partition:
https://github.com/theduckchannel/xerolinux-rollback-git/blob/main/xerolinux-rollback

    def getRootPartition():
        partitions = psutil.disk_partitions()
        print('Querying root partition...')
        retValue = None
        for partition in partitions:
            if partition.mountpoint == '/':
                print('Found!')
                retValue = partition.device

        return retValue

[jrabinow]

I'm afraid I have zero bandwidth until June to help you figure this out.

Apologies, it looks like I grossly underestimated what this year had in store for me.

Thinking about autodetect, the options I can think of involve looking at every disk available on the system, which could be rather brittle. Finding the linux rootfs is straightforward, but here we need to fill the config file with the btrfs root - it's not quite the same thing. Not impossible, my personal system has had to take a backseat and I'm almost exclusively on apple mac these days though 🥲 just a heads up

Do I understand correctly that the reason snapper-rollback doesn't work out-of-the-box for me is due to the /@ and /@ subvolumes that are relative to the filesystem root?

I'm afraid I have no idea about that one, but I tried playing with grub-btrfs a while back and may have run into the same problem, where new snapshots don't show up until grub-install is rerun. Did you ever figure that one out? I'd be curious to learn what the fix was.

For both GeckoLinux and the additional new distro I'm working on, I always make a point of sticking to upstream package repos so that the installed system isn't dependent on me for maintenance

Hmm, could you bundle some custom scripts though? I feel like the simplest approach here would be using something like sed -i -E 's/@/\/@/' /etc/snapper-rollback.conf Of course, this does mean potential maintenance if the config file were to change. I consider that quite unlikely though. The custom calamares script option you mention sounds like it might have potential as well.

Another small improvement I could suggest would be to make it work like the standard Snapper snapper rollback command where, if no snapshot number is specified it simply performs a rollback to the number of the booted RO snapshot.

It's quite possible the system isn't booted into a snapshot though. I could look into making this option happen. My system is offline and I have some work to bring it back so I will eventually look into this, but please don't expect anything soon on that front.

[jrabinow]

@geckolinux I see things seem to be moving towards Spiral Linux, which seems to have snapper-rollback baked in. I'm assuming that the GeckoLinux distro will stick around for some time in maintenance mode, but active development will continue on the Spiral Linux side of things.

Is it safe to assume that everything on the Spiral Linux side is working as intended? If so, can I close this issue? If not, I still can't promise fast resolution but if there's any relevant improvements still to be made, please let me know.

Congrats on the new release!