Support for @rootfs subvolume

[M4rQu1Nh0S]

In Ubuntu and based distros, a BTRFS partition for the system by default uses a subvolume named @ But some distros like Debian Testing use the subvolume @rootfs instead of @

The timeshift app advises about subvolumes like @ or @home as supported, but I would like to suggest the inclusion of subvolume @rootfs too.

I suppose that is not a problem to add one more subvolume supported to the timeshift, with support to @rootfs subvolume the user can use the timeshift early after installation

[werdahias]

+1

[ghost]

The better option is to make subvolume configurable

[bullet64]

same here on Debian Bookworm 12 RC1

[j-lakeman]

duplicate of #83 #9

[Danathar]

So, this has obviously been a problem for a while. Just wondering what the deal is? Is there some logical reason why making subvolumes configurable or supporting @rootfs is not good?

[Aparichit0]

There are tons of video tutorials on YouTube to manually create @ & @home subvolumes to work with Timeshift. But if your end goal is to just create btrfs snapshots without reinstalling then you should take a look at btrfs assistant instead. It also works with @rootfs and doesn't require you to manually create subvolumes.

All you need to do is:

1. Install btrfs assistant with simple instructions on gitlab (just copy-paste in terminal)
2. Install snapper (It's optional in btrfs assistant installation instructions. But I did and you'll need it for step 4)
3. Remove unnecessary qt5 files via sudo apt remove qt5* && sudo apt autoremove (in my case btrfs assistant icon wasn't properly displaying without removing it)
4. Create snapper config inside btrfs assistant with default options
5. Now you can create/automate/restore btrfs snapshots through btrfs assistant

Note: 1. There is no option to exclude home or specific files/directories like Timeshift has(because there are no separate subvolumes)

2. Everything in this guide is for debian 12 in mind, but it should be similar in other distros

[M4rQu1Nh0S]

There are tons of video tutorials on YouTube to manually create @root & @home subvolumes to work with Timeshift. But if your end goal is to just create btrfs snapshots without reinstalling then you should take a look at btrfs assistant instead. It also works with @rootfs and doesn't require you to manually create subvolumes.

All you need to do is:

1. Install btrfs assistant with simple instructions on gitlab (just copy-paste in terminal)
2. Install snapper (It's optional in btrfs assistant installation instructions. But I did and you'll need it for step 4)
3. Remove unnecessary qt5 files via sudo apt remove qt5* && sudo apt autoremove (in my case btrfs assistant icon wasn't properly displaying without removing it)
4. Create snapper config inside btrfs assistant with default options
5. Now you can create/automate/restore btrfs snapshots through btrfs assistant

Note: 1. There is no option to exclude home or specific files/directories like Timeshift has(because there are no separate subvolumes) 2. Everything in this guide is for debian 12 in mind but should be similar in other distros

Sorry, but I see some inconsistencies about one thing or two in your commentary: The root directory and home directory can be treated as separated subvolumes, by default some distros already create distinctive subvolumes for / and /home directories.

I disapprove of the idea to jump to another tool if this is open source and has ways to adopt suggested changes, anyway, I'm trying to say that I hope for improvements in Timeshift instead of jumping to another solution, mainly if another too has some functions missing.

Looking to timeshift files is not difficult to add more subvolumes as "supported" in timeshift. If the maintainer has no interest to adopt the changes, it is more sensate speak directly and let someone create a fork version.

Tip: For now if an Archlinux user has an interest to use Timeshift, is needed to create the @ subvolume during the install process, since the subvolume needs to be "level 5".

[Aparichit0]

There are tons of video tutorials on YouTube to manually create @root & @home subvolumes to work with Timeshift. But if your end goal is to just create btrfs snapshots without reinstalling then you should take a look at btrfs assistant instead. It also works with @rootfs and doesn't require you to manually create subvolumes. All you need to do is:

1. Install btrfs assistant with simple instructions on gitlab (just copy-paste in terminal)
2. Install snapper (It's optional in btrfs assistant installation instructions. But I did and you'll need it for step 4)
3. Remove unnecessary qt5 files via sudo apt remove qt5* && sudo apt autoremove (in my case btrfs assistant icon wasn't properly displaying without removing it)
4. Create snapper config inside btrfs assistant with default options
5. Now you can create/automate/restore btrfs snapshots through btrfs assistant

Note: 1. There is no option to exclude home or specific files/directories like Timeshift has(because there are no separate subvolumes) 2. Everything in this guide is for debian 12 in mind but should be similar in other distros

Sorry, but I see some inconsistencies about one thing or two in your commentary: The root directory and home directory can be treated as separated subvolumes, by default some distros already create distinctive subvolumes for / and /home directories.

I disapprove of the idea to jump to another tool if this is open source and has ways to adopt suggested changes, anyway, I'm trying to say that I hope for improvements in Timeshift instead of jumping to another solution, mainly if another too has some functions missing.

Looking to timeshift files is not difficult to add more subvolumes as "supported" in timeshift. If the maintainer has no interest to adopt the changes, it is more sensate speak directly and let someone create a fork version.

Tip: For now if an Archlinux user has an interest to use Timeshift, is needed to create the @ subvolume during the install process, since the subvolume needs to be "level 5".

Thanks for pointing typing mistake about @root (I just fixed it). & I fully agree with everything else you've said about improvement in Timeshift itself.

But every time I searched for a solution to use Timeshift btrfs snapshots post installation, I was either ended up with this github page or some comment suggesting to create subvolumes manually. Which I found too complex as a new linux user (because almost all easy to comprehend tutorials are for creating new subvolumes during installation not post installation) So I thought I should mention a workaround that worked for me.

[M4rQu1Nh0S]

But every time I searched for a solution to use Timeshift btrfs snapshots post installation, I was either ended up with this github page or some comment suggesting to create subvolumes manually. Which I found too complex as a new linux user (because almost all easy to comprehend tutorials are for creating new subvolumes during installation not post installation) So I thought I should mention a workaround that worked for me.

Your workaround is correct, even recommended, because other tools like snapper have not prerequisites like subvolume with name "@" with "level 5".

In a BTRFS filesystem exists only one subvolume as level 5, any subvolume created after will get another level, and timeshift only accept the subvolume if he is in level 5 and named as @

For now, the timeshift is only recommended if you are used to using this tool in the past or in another distro, and if you already know what is necessary to make the timeshift work in any distro.

[EvanCarroll]

Found this issue by researching the same YouTube videos I'm sure many others came here for. This is baffeling. https://unix.stackexchange.com/a/752750/3285

Is it the goal of the project to NOT accept other root volume names and to use this project to establish this convention? Or are patches accepted?

Because as far as I'm concerned, the project can do whatever it wants, but if it goes down this path intentionally then Debian should either (a) remove the package, or (b) patch the package to change default root name to that created by the installer. This is a horrible experience for Debian users, where the installer utilizes a convention that render packages it ships unusable.

If ya'll feel that strongly about making @ the convention for the root volume name, is there a conversation on Debian's mailing lists about this?

[M4rQu1Nh0S]

If ya'll feel that strongly about making @ the convention for the root volume name, is there a conversation on Debian's mailing lists about this?

No, a change in the default name of Debian subvolumes could impact the behavior of the system in some devices, and even impact the stability of other resources that already uses this subvolume name, in my opinion.

This change belongs mainly to the package, not to the system entirely since timeshift is configured to accept only two subvolume names (@home and @).

[EvanCarroll]

So then just to be clear, if the convention in Debian can't be changed moving forward and it's hardcoded in Timeshift, then we're back to,

• Does Timeshift want to change this, and is so what would an acceptable patch require?
• Should Debian patch Timeshift so it is consistent with its own (Debian's) defaults?

In lieu of either of these being accepted, it seems Debian is better off dropping the package entirely.

[M4rQu1Nh0S]

So then just to be clear, if the convention in Debian can't be changed moving forward and it's hardcoded in Timeshift, then we're back to,

• Does Timeshift want to change this, and is so what would an acceptable patch require?
• Should Debian patch Timeshift so it is consistent with its own (Debian's) defaults?

In lieu of either of these being accepted, it seems Debian is better off dropping the package entirely.

Seems that the Timeshift devs want to arrant compatibility with all distros based on Ubuntu only, since we are requesting the inclusion of @rootfs subvolume and until now no changes has been made.

So, if we can't change the subvolume name in Debian based distros we can at least talk with mainteiner of timeshift of debian repository but I don't know if he is able to do that.

I'm waiting for the timeshift staff to say the final word about this subject, before starting to talk with the maintainer of the package for Debian.

[EvanCarroll]

Thanks for the clarification I'll take care of it from here. They're going to have fun though when Debian patches this to work with their defaults, and all the downstream distros like Ubuntu get the patch and have to remove it so it continues to work with their distros. I'll file the bug now.

[EvanCarroll]

BTW, this is a duplicate of #83.

[EvanCarroll]

@M4rQu1Nh0S Bug filed upstream, I'll work on reproducing this and submitting a patch to linuxmint/timeshift

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042538

[cstrahan]

Having the subvolume names hardcoded (even if patched "appropriately" per distro package) is the wrong approach. This line of thinking is based upon a misconception: there is no "Mint volume structure" or "Ubuntu volume structure" or "Pop!_OS volume structure" or "Fedora volume structure" or "${INSERT_LINUX_DISTRO_HERE} volume structure".

Now, I will grant that each distro installer will have its defaults for how it sets up the volume structure (e.g. @ vs @rootfs for the / mount). But beyond the installer, the distros (and their respective packages) are oblivious to that structure -- to the distro, there's just the the / mount and everything reachable from there, with the expectations that / follows the Filesystem Hierarchy Standard. The installer ensures that the kernel command line is setup such that the kernel/initrd can mount the right filesystem at / by subvolume name; after that initial install step, nothing cares about how the filesystem hierarchy is composed. And while each distro installer has its defaults and conventions for @ or @rootfs and/or @home, these are easily changed during the installation of any distro.

To provide practical motivation for why one might want to roll their own subvolume scheme: dual booting. Many people (myself included) take advantage of BTRFS's nearly magical ability to slap multiple distros into the same filesystem. This is absolutely friggin' fantastic because now you don't have to worry about how you're going to partition your drive -- no more of this:

I think I want to give 70% to Mint and 30% to Fedora ...

Oh wait, what if I want/need to install another distro ...

Okay, so 50% to Mint and 25% to Fedora, with 25% left just in case ...

I really hope I can live with this partitioning scheme, because it'll really suck if I have to reinstall everything all over again, ugh

Instead, just use one partition formatted as BTRFS and then install Mint under mint/@ and mint/@home, and Pop!_OS under pop_os/@ and pop_os/@home, etc. Super easy, and super convenient. Once setup, this dual booting setup is completely hands-off -- "it just works".

This lets me jump into, say, Ubuntu to test something real quick for my Ubuntu users, or Fedora for work, and I get to use NixOS for everything else. If it turns out that Ubuntu is using 20 gb of space, then only 20 gb is in use by Ubuntu -- not 20 gb + the unused space of a dedicated-to-Ubuntu partition. All software within each of the distros I use works fine out of the box under this scheme, with zero tweaks or fixes needed -- the sole exception being Timeshift (which is why I don't/can't use it, as much as I would like to).

If you'll grant me a silly analogy: if you took your car to the mechanic because the transmission is clearly behaving faulty in 4th gear, what you wouldn't want to hear from the mechanic is "I don't see what's wrong; it handled just fine when I drove it. What do you mean 4th gear? Who uses that?! All you ever really need is the first couple gears, ya know -- why would you need anything higher than that when you're leisurely making short 1-5 mile trips in urban streets?"

While the mechanic might never reach higher speeds in his typical day, you need to commute between cities, which implies use of the highway and the speed limits that entails. Even if everyone in your city drives no faster than residential speeds, that doesn't make use of the 4th gear somehow "exotic" or a "special case" -- the car was designed to support this just as well as any other gear.

So it is with choosing how you want to compose your filesystem. You may (intentionally or not) leverage your distro's installer defaults, but those defaults do not constitute a standard or rule of any sort, and software should not make assumptions as if these defaults were the standard or rule.

---

Apologies if I'm coming off overly zealous. I'm just trying to be very thorough. One of my favorite things about BTRFS is the ability to easily share a single partition with multiple distros, without having to muck with LVM or some nonsense like that. BTRFS will practically lose that superpower if more and more software becomes unnecessarily concerned with how the subvolumes are laid out, so I feel its important to spread awareness.

[j-lakeman]

Couldn't agree more! 👏 Nice analogy! Cheers!

[nstiurca]

Bump.

I really wish the repo maintainers would comment on what they want to do about all this. I get not having the bandwidth to implement this feature request. But could they at least say "ok, we'll support someone sending us a patch that keeps the defaults in place for Mint, but adds support for other layouts." Or if not, I wish they'd just close this and similar issues with some "won't fix" label.

Not having any response after a year (much longer for duplicates like #83) is just terrible. I suppose maybe we're supposed to take the extended silence as a response that they'll not prioritize any of this any time soon.