Necessity of `mountpoint` and `dev` settings about snapper-rollback HOT 1 OPEN

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.

from snapper-rollback.