The openSUSE page on BTRFS has this to say: “The root users home directory should also be preserved during a rollback.”
Even CachyOS does that, but they are probably just copying openSUSE.
So fast-forward to 2026, where BTRFS is the default file system of Fedora, is there any downside to allowing or placing /root on a separate subvolume, or has the anaconda installer simply not kept up with the times?
The argument seems to be that you should be able to boot to some kind of emergincy mode if it is not possible to mount any of the other disks. and without /root, the root account doesn’t have a home working home directory.
This argument is mostly irrelevant, becuase in emergency mode you would run the system from the initrd only and that doesn’t require /root to be part of /. Even this is mostly also irrelevant because it is encouraged to not assign a password to the root account and therefore you can’t use the emergency mode anyway.
Back 50 years ago, a big disk unit was probably some 50 Megabytes so a big part of the installed system needed to be moved to a separate disk unit, namely the /usr file system. That is why there was a split between /bin and /usr/bin, where you should be to run a minimal system without /usr/bin, or the /usr/lib for that matter. Today that doesn’t matter as currently the system would not run anyway if /usr was not available, and typical smallish disk units are orders of magnitude bigger in capacity than the big disk units 50 years ago.
So for your own system, go ahead and split out /root into a separate subvolume.
There’s / which is a mount point and the installer is complaining that the installation must have a / mount point.
Anaconda always puts the system files in a subvolume, default name is “root” mounted at / - since ancient times. And a separate subvolume, default name is “home” mounted at /home - is optional but is created by default.
With the new interface I’m off hand uncertain if you can give a subvolume an arbitrary name, but that functionality is in the backend. And subvolumes can be assigned arbitrary mount points.
This mount point is invalid. The /root directory must be on the / file system.
It doesn’t talk about the mount point of the root file system, but about the /root directory which must not be a mount point for a separate file system. And the question is: Why can’t the root directory be a separate mount point?
The various subvolumes of a btrfs file system are in themselves separate file systems and are mount at their respective mount mounts. So the subvolume “root” is mounted at / and the subvolume “home” is mounted at /home.
You can also create ext4 file systems instead of btrfs subvolumes, one for the / mount point and one for the /home mount point. None of that refers to the home directory of the root user which is /root.
I am referring to /root as in the root user’s home directory, not / as in the root file system altogether. So I am considering the following subvolume layout inspired by the openSUSE default layout:
@ → /
@opt → /opt
@root → /root
@srv → /srv
@usr.local → /usr/local
@var → /var
@var.tmp → /var/tmp
The other option is rather than do a flat layout, do exactly what openSUSE does:
@ → /
@/opt → /opt
@/root → /root
@/srv → /srv
@/usr/local → /usr/local
@/var → /var
@/var/tmp → /var/tmp
On the face of it, there’s a method to the madness behind the openSUSE way, but I recall the flat layout is recommended for some reason (something like Snapper or Timeshift needs it) I think?
Ahh. The message might be saying /root directory must be on the root subvolume (or if a different volume format than Btrfs, this directory must be on the first file system mounted, i.e. root file system). I’m not sure why the installer enforces this, but it might have something to do with booting in runlevel 1/single user mode, and making sure that boot doesn’t break if the “root user file system” can’t be mounted on the /root directory for some reason.
I’m aware this can happen with /etc - so I wouldn’t be surprised if that too can’t be a separate subvolume (or on a different file system) mounted subsequently.
Ironically, mounting Btrfs subvolumes is merely a bind mount behind the scenes. A subsequent mount of a subvolume doesn’t result in full mount process. The only way it fails is if the specified subvolume name or ID is incorrect (non-existent).
Flat layout is often used to stop snapshots from descending recursively into what would otherwise (likely) be a directory. So if you do not want a directory to be part of a snapshot, and you have no intention of ever snapshotting (separately policy) the contents of that directory, making it a subvolume in a flat layout effectively achieves a sort of bulkhead, since snapshots are not recursive, i.e. they do not cause the subsequent snapshotting of subvolumes or subvolume snapshots within a subvolume.
Anyway, sorry for the confusion. I’m not sure why Anaconda enforces /root cannot be a mount point for a separate file system. It might be documented in the code, I’d probably look there first because the Anaconda team has really limited bandwidth so I’m not sure a bug report will get a response in the near term.
I think (just from searching around in the code) that a set of paths that must be subdirs of / is configured in anaconda.conf, and the default includes /root. (Code here.)
The comments don’t provide any information on why it’s that way though. Like you I’d guess it’s considerations about booting into runlevel 1.