[WIP] Configurable Btrfs subvol names

[fused0]

Here's the start of configurable subvolume names, to support non-ubuntu layout (at least layouts that only have different names, not nested ones).

It's functional, but I'm sure some (small?) issues are remaining.

Advice and suggestions appreciated.

See issues #368, #405, #266, etc

Best,
fused0

[ygerlach]

Nice! i just ran into this issue today, as i tried to run timeshift on debian in btrfs mode (I had to manually rename @rootfs to @ and fix my grub for it to work)

I think in the long term we should allow an arbitrary amount of subvolumes for backups. I believe some distros allow /boot or /etc to be their own subvolume. But i guess that would be a bigger topic.

I think there is some room to improve add_opt_btrfs_subvolume_names :

• it seems the code for creating home and root text box is quite similar. maybe we could create a function like create_btrfs_subvolume_selection to de-duplicate this.
• There should be some kind of guard against entering a wrong subvolume names. Maybe even use a select box instead of a text box
• the boxes should be hidden or greyed-out when btrfs mode is inactive
• i think the home subvolume selection could be moved to the thing where it asks to backup @home at all (see screenshot). I am thinking a selection box with the options: "Disabled", @home, @boot, ...)
• selecting the same subvolume twice should also be guarded against.

Some other thing: i don't know if we need to care about changes of names in the config. What if i configure @rootfs, make some snapshots, rename it to @ maybe fuck up my system some time later, want to restore my old @rootfs snapshot, but because i changed the name in the timeshift config its now failing.

The question is: should we use the configured btrfs subvolume, or just restore all subvolumes in the snapshot folder or use the information from info.json? Im not sure how it is currently handled. (Enable and Disable backup of @home could have a similar problem)

[fused0]

Thanks for the quick review, I'll get to the improvement suggestions soon :)

Regarding:

I am thinking a selection box with the options: "Disabled", @home, @boot, ...)

What would "Disabled" do?

selecting the same subvolume twice should also be guarded against.

Thanks, definitely, that seems like it could fail spectacularly.

[ygerlach]

What would "Disabled" do?

the same as not selecting the checkbox seen in the screenshot. (I would replace the checkbox with the dropdown)

[fused0]

I put the option into the backup type page, because it depends on the type of backup used. Selecting rsync is the equivalent of the option being disabled.

To me, it would be a little confusing to have it on the users page, but I'm also not super familiar with the full functionality of this page, because I saw it allows selecting home directories in cases where multiple users exist on the system.

Please let me know what you think.

[fused0]

I've turned the subvolume name selection into a combo box, which should address almost all of the issues you had, except the one about the location of the option

Not entirely sure what the common options are (please let me know) and if there should be a "custom" option as well. The custom option would make it tricky in terms of making sure the config is valid.

[fused0]

Actually, I went and change the two comboboxes into a single one, to select a predefined layout. Hopefully I left some room to add a "custom" option (implementation would be similiar how the custom date format is done, presumably).

The current state would be more than sufficient for my - and probably most users - needs.

Still not sure about the debian layout/subvolume names.

Also, I'd like to change some of the messages in the UI, but I'm not sure how to proceed in regards to the translation, example:

status_details = _("Select BTRFS system disk with root subvolume" + @" ($(App.root_subvolume_name))");

[fused0]

@ygerlach apologies for the ping, but any advice or suggestions how to proceed from here?

[ygerlach]

apologies for the ping

@fused0 no problem, the PR looks fine to me.

Not entirely sure what the common options are (please let me know) and if there should be a "custom" option as well.

i think we will get issues if people miss some layout. so we can add it then, if we miss it here.

Actually, I went and change the two comboboxes into a single one, to select a predefined layout.

i think that is reasonable

Just checked the ui again on debian. Here how it looks (for others interested in this PR):

I think it looks nice. Making it "disabled" when rsync is active is nice.

Just a thought: do we really need a selection? Can't timeshift find the correct layout itself? Because usually there should only be one valid layout possible and if the user fucks up the selection, timeshift behaves badly. So best keep the user out of this decision? And if a user has a layout that matches multiple layouts, with subvolumes like @rootfs, @, @homefs and @home, the user will be proficient enough to edit the timeshift config himself.

So if we have some detection what subvolumes are existing and choose the correct layout and maybe display the chosen selection like: "Using subvolume layout: Ubuntu (@, @home)" would be fine i guess.

Do all systems always have a seperate home subvolume? (EDIT: No, my debian test vm aparently only has @rootfs)

When i try to create a snapshot i get:

(timeshift did not exit)

Maybe you should run some tests with your branch on some different systems/vms (debian, fedora, linuxmint, ...)

P.S: im not a timeshift maintainer, just an contributor, so my opinion is not binding :)

[fused0]

@fused0 no problem, the PR looks fine to me.

Thanks, but after your reply, there is more to consider.

Just a thought: do we really need a selection?

The layout actually is auto detected for the intial config values, based on the distro name. I wondered the same, when I added it. I suppose one could parse the fstab to find what subovlumes (if any) root and home map to... Seems like a simple enough solution for the entire problem. It would catch all reasonable user-defined layouts.

the user will be proficient enough to edit the timeshift config himself.

Unfortunately, due to how the timeshift handles the settings and wizard dialogs - more or less immediately overwriting the config - there can only be two options: Having no option in the UI at all, or supporting "custom" layouts with settings in the UI. Otherwise, the edited config would be overwritten when you accidentally (or not) open the settings or wizard.

I think I'll go for it and add the custom layout option.

Do all systems always have a seperate home subvolume? (EDIT: No, my debian test vm aparently only has @rootfs)

Now I know why I couldn't find anything on the name of the home subvolume in Debian. :)

I'm wondering if timeshift would work if you configure it to not backup the home subvolume and leave the home subvolume option blank or wiht a dummy value - or if supporting layouts without a separate home would imply more work. I would very much appreciate if you could give it a try.

Maybe you should run some tests with your branch on some different systems/vms (debian, fedora, linuxmint, ...)

Unfortunately I'm on a rather limited and flaky internet connection at the moment.

P.S: im not a timeshift maintainer, just an contributor, so my opinion is not binding :)

Seems I wrongfully assumed you to be a maintainer :) Thank you for your detailed reply and suggestions, much appreciated.

I suppose it would be good to get a maintainer to weigh in on the issue.

Thanks,
fused0

[fused0]

@ygerlach Interestingly, timeshitft handles leaving the home subvolume name empty somewhat gravefully. I've made some more tweaks to make it work on debian without a separate home subvolume - it feels a bit hacky, but it works!

Now I'm wondering if this solution is adequate, or if parsing fstab and adding a custom input group is even needed.