Necessity of `mountpoint` and `dev` settings

[david-cortes]

Looking at this blog post: https://www.jwillikers.com/btrfs-snapshot-management-with-snapper

It seems it should be possible to determine the /dev file where the root partition is mounted by issuing this command:

df --output=source / | tail -n 1

And consequently something like this for snapper-rollback:

sudo mkdir -p /btrfsroot
sudo mount $(df --output=source / | tail -n 1) /btrfsroot

(or a different folder that's like to exists such as /mnt or /tmp to be safer on a read-only snapshot)

Not sure if it's guaranteed to work though.

[jrabinow]

Thanks for bringing up these issues. I've wanted to improve the UX from the start, but I haven't found a way to cover all cases: in case the system is completely borked, it should be possible to boot from a liveCD/liveUSB and run the script from there.

On dev config file entry:

Auto-detecting the right device is a lot harder in the liveCD scenario, so I think it's best to keep the dev entry in the config file. There's no reason to not do some form of autodetect if rolling back the / partition though.

On mountpoint config file entry:

As you pointed out, / might be mounted read-only, so the mountpoint entry is to cover that scenario. Mounting on /mnt might not be an option if the operator already mounted something there, and mounting directly on /tmp is inadvisable as other processes might try to use it for their own purposes, but a directory under /tmp could work.

On UX improvements in general:

I want to consider the tradeoff between ease of use and code complexity: this tool must work if the system is in a bad state, so it has to be robust and avoid "magic" if it can. The least magic approach is having the operator specify everything themselves through a config file or command-line parameters. That being said, adding support for the common usecase(s) is definitely something worthwhile. I won't be implementing this in the near future unfortunately, my system is offline at the moment so I can't test anything. Contributions are always appreciated, but I'll get to it myself at one point.