Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Necessity of mountpoint and dev settings #10

Open
david-cortes opened this issue Mar 5, 2023 · 1 comment
Open

Necessity of mountpoint and dev settings #10

david-cortes opened this issue Mar 5, 2023 · 1 comment
Labels
enhancement New feature or request

Comments

@david-cortes
Copy link
Contributor

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.

@david-cortes david-cortes added the enhancement New feature or request label Mar 5, 2023
@jrabinow
Copy link
Owner

jrabinow commented Mar 5, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants