Configurable Btrfs subvol names by fused0 · Pull Request #480 · linuxmint/timeshift

fused0 · 2025-11-23T16:44:19Z

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

Save and load config for btrfs subvolume names. Added variables for home and root subvolumes to Main.

…e as system subvolume name

ygerlach · 2025-11-23T17:42:13Z

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)

src/Core/Main.vala

fused0 · 2025-11-23T18:01:01Z

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 · 2025-11-23T18:04:08Z

What would "Disabled" do?

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

fused0 · 2025-11-23T18:18:50Z

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.

Also deduplicated the subvolume ui selection code

fused0 · 2025-11-24T07:59:11Z

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.

into a single combobox to select a predefined layout

fused0 · 2025-11-24T09:46:23Z

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))");

on first launch of timeshift, based on distro id

fused0 · 2025-11-30T09:16:59Z

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

ygerlach · 2025-11-30T11:55:30Z

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 · 2025-11-30T13:42:03Z

@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

empty home subvolume name and force include_btrfs_home_for_backup to false

fused0 · 2025-11-30T14:48:16Z

@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.

When root subvolume name is misconfigured to empty string, don't early out, but treat it the same as empty home subvolume name

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

fused0 · 2025-12-09T08:23:55Z

@mtwebster I suppose one could sum up Copilot's micro-issues as:

Subvolume names should be validated before taking any snapshot create and restore actions.

Taking a look how it can be done in a sensible way. :)

…re snapshot create and restore actions

fused0 · 2025-12-09T08:56:40Z

@mtwebster I've addressed most of the issues by making sure Main::check_btrfs_layout_system is called before restore and create actions in the UI as well as the console.

The question now is: Is this enough or should all these small issues be addressed separately, even though values are validated before action is taken and the code isn't reachable?

in case the root subvolume is misconfigured to empty string

fused0 · 2025-12-18T10:01:41Z

Just an update, I'm reading, documenting and trying to understand much of the code base pertaining to btrfs - I haven't given up yet :)

fused0 · 2025-12-18T12:00:02Z

@mtwebster Basically, the logic around checking the btrfs configuration is a bit fuzzy and split between Main and SubvolumeRepo - I'm trying to unify it in a sensible way, so that it can be easily checked before taking any action (restore, create, delete).

It proves a little tricky, but I'm getting there. And sorry for the ping.

…ig is valid Main: change check_btrfs_volume to take an array of subvolume names SnapshotRepo: get rid of default mount_paths SnapshotRepo: add check_config to validate btrfs config and give appropriate error messages

…any action taken

fused0 · 2026-01-06T10:55:43Z

Hey @mtwebster, would you mind running Copilot again on the latest changes to this branch?

I've resolved most of it's complaints by making sure the code paths can not be reached without checking the validity of the btrfs config before taking any action (create, restore, delete) either from the console or the UI.

I suspect it will still flag some of the occurrences of App.root_subvolume_name and App.home_subvolume_name, so I'm happy to take any advice on how to deal with it. I was thinking of simply adding asserts where they are used?

Happy new year,
fused0

* Mounting of btrfs devices * UI lables * Log messages and errors * Parsing of fstab and crypttab

ygerlach · 2026-01-16T17:21:52Z

I tried it on my debian. I configured my debian to use @ but @rootfs still exists. If i configure timeshift to use @rootfs it shows, the subvolume to be missing?

Here i put it to Ubuntu (but disabled home directoy). I still get the @home missing error.

fused0 · 2026-01-18T12:25:14Z

Heya, thanks for giving it a try.

I tried it on my debian. I configured my debian to use @ but @rootfs still exists. If i configure timeshift to use @rootfs it shows, the subvolume to be missing?

The first issue is easily explained, I think. Timeshift parses the fstab and mounts the subvolume only if it's actually used as the root subvolume (same for the home subvolume), but the error message doesn't reflect that (also not before my changes).

Here i put it to Ubuntu (but disabled home directoy). I still get the @home missing error.

This, depending on what you mean exactly, could be the intended behaviour. You specified a home directory by setting the dropdown to 'Ubuntu', but you disabled 'Include home subvolume in backups'?

One could argue that the config should reflect the subvolume layout you have ('@' and ''), as well as, if the home subvolume is not used, it shouldn't matter what it's set to.

KyleRConway · 2026-01-20T03:42:36Z

Thank you for your work on these. Just wondering if there's a difference in the subvolume layouts for the increasingly popular immutable systems (Fedora Silverblue, Bazzite, NixOS, etc. -- Appreciate the work here! Thanks so much!

mtwebster · 2026-02-17T17:23:30Z

src/Core/SnapshotRepo.vala

 		//log_debug("checking selected device");

+		// Snapshot repo is available if the config is valid.
+		bool ok = check_config(out status_message, out status_details, out status_code);


status_message is never set in rsync mode or in certain btrfs scenarios

** (timeshift-gtk:42712): CRITICAL **: 12:21:56.663: tee_jee_logging_log_debug: assertion 'message != NULL' failed D: is_available: ok

mtwebster · 2026-02-17T17:25:34Z

src/Core/SnapshotRepo.vala

+			// home_path can be null if mount_paths[App.home_subvolume_name] doesn't exist.
+			var home_path = path_combine(mount_paths[App.home_subvolume_name], App.home_subvolume_name);
+			var home_subvolume_configured = App.home_subvolume_name != "";
+			var has_home_mount_path = mount_paths.has_key(App.home_subvolume_name);


Shouldn't you be checking mount_paths.has_key() before using App.home_subvolume_name in the preceding lines?

mtwebster · 2026-02-17T17:32:06Z

src/Core/SnapshotRepo.vala

+			if (!has_home_mount_path || (home_subvolume_configured && !dir_exists(home_path))) {
+				title = _("Home subvolume configuration is invalid");
+				msg = _("Home subvolume is configured but the path does not exist") + " (" + App.home_subvolume_name + ")";
+				code = SnapshotLocationStatus.NO_BTRFS_SYSTEM;
+				return false;
+			}


Has this PR been tested on a debian system?

It looks like you skip adding "" (the debian 'home_subvolume_name') to mount_paths.

mtwebster · 2026-02-17T17:34:19Z

src/Core/SnapshotRepo.vala

+			// !has_root_mount_path.
+			if (!has_root_mount_path || !dir_exists(root_path)){
+				title = _("Root subvolume configuration is invalid");
+				msg = _("Root subvolume is configured but the path does not exist. Select BTRFS system disk with root subvolume ") + " (" + App.home_subvolume_name + ")";


Should use App.root_subvolume_name maybe?

mtwebster · 2026-02-17T17:43:51Z

src/Core/Main.vala

+				dst_path = dst_path.replace(nested_home_subvol, @"/$(home_subvolume_name)");
 			}

 			string cmd = "btrfs subvolume snapshot '%s' '%s' \n".printf(src_path, dst_path);


Since we're now letting arbitrary strings into our shell commands, i think how we run these commands needs to change, and we need to sanitize these names we're accepting.

Granted, this is all running as root, but the plain shell command format here has bothered me for a long time, and this is a good reason to move away from it.

We should switch to a format that accepts an argument vector, not a single string with quotes, etc...

exec_sync should use Process.spawn_sync() instead of spawn_command_line_sync()

fused0 added 4 commits November 23, 2025 15:53

Added ui for btrfs subvolume names

4d528da

Save and load config for btrfs subvolume names. Added variables for home and root subvolumes to Main.

Merge branch 'linuxmint:master' into btrfs_subvol_names

85efc0b

Improve subvolume name option layout

6cf8745

early out of subvolume listing if configured subvolume is not the sam…

bd54ed4

…e as system subvolume name

ygerlach reviewed Nov 23, 2025

View reviewed changes

src/Core/Main.vala Outdated Show resolved Hide resolved

fix add missing return value in Main.query_subvolume_id

f3e3bc8

Subvolume selection is now a combobox

52b7cf4

Also deduplicated the subvolume ui selection code

fused0 added 2 commits November 24, 2025 10:23

improved subvolume selection by adding a distribution hint

9cc883b

combine subvol comboboxes

0ebe92a

into a single combobox to select a predefined layout

fused0 added 5 commits November 24, 2025 13:18

detect subvolume layout

4e13156

on first launch of timeshift, based on distro id

Merge branch 'linuxmint:master' into btrfs_subvol_names

69b8468

cleanup create_btrfs_subvolume_selection

04bfffd

call init_backend on layout change

dd769f5

also call type_changed on subvol layout change

d7b5070

mtwebster changed the title ~~Configurable Btrfs subvol names~~ [WIP] Configurable Btrfs subvol names Nov 27, 2025

fused0 added 2 commits November 30, 2025 15:41

Disable "include home subvol" option when home subvolume name is empty

0e71046

fix for debian style layout

7f55d83

empty home subvolume name and force include_btrfs_home_for_backup to false

fused0 added 2 commits November 30, 2025 20:14

added ui for custom subvolume layout

aaccff3

Merge branch 'linuxmint:master' into btrfs_subvol_names

a1f3892

fused0 marked this pull request as ready for review December 8, 2025 06:48

fused0 and others added 3 commits December 8, 2025 18:12

Properly fix query_subvolume_id

6a0240f

When root subvolume name is misconfigured to empty string, don't early out, but treat it the same as empty home subvolume name

Simplify vbox_subvolume_custom.visible assignment

216393b

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Fix typo in comment

59339bb

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Making sure to consistently call Main::check_btrfs_layout_system befo…

b32ac4e

…re snapshot create and restore actions

fused0 added 2 commits December 9, 2025 10:30

fix null pointer exception in query_subvolume_quota

4b5cf13

in case the root subvolume is misconfigured to empty string

Merge branch 'linuxmint:master' into btrfs_subvol_names

01f0445

ygerlach mentioned this pull request Dec 9, 2025

Bug: Timeshift BTRFS mode fails to recognize standard Fedora Subvolume layout (root/home) #487

Closed

fused0 added 3 commits December 10, 2025 08:55

document and fix query_subvolume_id

3ceb27d

document and fix query_subvolume_quota

4031b17

Added comments to SnapshotBackendBox

4630806

fused0 added 3 commits January 6, 2026 11:30

AppConsole: make sure App.check_btrfs_layout_system is called before …

0611f62

…any action taken

Merge branch 'linuxmint:master' into btrfs_subvol_names

7d29174

fused0 added 2 commits January 9, 2026 11:35

Fix more occurences of @ and @home in:

3228362

* Mounting of btrfs devices * UI lables * Log messages and errors * Parsing of fstab and crypttab

AppConsole: Don't call check_btrfs_layout_system before device selection

aefb4e4

ygerlach mentioned this pull request Jan 16, 2026

Full Fedora support (BTRFS snapshots) #9

Open

clefebvre changed the title ~~[Next] Configurable Btrfs subvol names~~ Configurable Btrfs subvol names Jan 22, 2026

mtwebster reviewed Feb 17, 2026

View reviewed changes

Conversation

fused0 commented Nov 23, 2025

Uh oh!

ygerlach commented Nov 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

fused0 commented Nov 23, 2025

Uh oh!

ygerlach commented Nov 23, 2025

Uh oh!

fused0 commented Nov 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fused0 commented Nov 24, 2025

Uh oh!

fused0 commented Nov 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fused0 commented Nov 30, 2025

Uh oh!

ygerlach commented Nov 30, 2025

Uh oh!

fused0 commented Nov 30, 2025

Uh oh!

fused0 commented Nov 30, 2025

Uh oh!

fused0 commented Dec 9, 2025

Uh oh!

fused0 commented Dec 9, 2025

Uh oh!

fused0 commented Dec 18, 2025

Uh oh!

fused0 commented Dec 18, 2025

Uh oh!

fused0 commented Jan 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ygerlach commented Jan 16, 2026

Uh oh!

fused0 commented Jan 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

KyleRConway commented Jan 20, 2026

Uh oh!

mtwebster Feb 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mtwebster Feb 17, 2026

Choose a reason for hiding this comment

Uh oh!

mtwebster Feb 17, 2026

Choose a reason for hiding this comment

Uh oh!

mtwebster Feb 17, 2026

Choose a reason for hiding this comment

Uh oh!

mtwebster Feb 17, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

4 participants

Comments

ygerlach commented Nov 23, 2025 •

edited

Loading

fused0 commented Nov 23, 2025 •

edited

Loading

fused0 commented Nov 24, 2025 •

edited

Loading

fused0 commented Jan 6, 2026 •

edited

Loading

fused0 commented Jan 18, 2026 •

edited

Loading

mtwebster Feb 17, 2026 •

edited

Loading