This issue only appeared when the main file system for fedora was switched to using btrfs. The subvolume “names” are immaterial to where the file system is mounted, but do clearly identify what that subvolume is (and is intended for).
The subvolume “home” is mounted at /home, but is not directly a users data space. It is instead the “root” of the users directory tree and contains their home directories and the data in those directories. There are directories created as /home/USER and that directory is the USER’s home directory.
Similarly the subvolume “root” is mounted at / but is not the home directory of the user root. There is a directory on / named /root that is the root users home directory.
I do not see where anyone could be confused with just a tiny bit of thought.
This directory structure was decided many eons ago to ensure that a users data never overwrites system programs and data. The user root has a home directory in the system area that is named for that user (/root).
It seems you are confusing the root of the file system / with the home directory of the user root /root. Don’t confuse file system structure with directory structure so literally.
In fact other distros that use btrfs have a slightly different naming for the subvolumes. Fedora uses root and home, but Ubuntu and the like seem to use @root and @home (maybe to assist in avoiding the misconception you seem to be experiencing)
Most new users never even know that a root user even exists since the account is disabled on Workstation by default and sudo is used to gain (most of) the root users powers. (The account is not unavailable, but its direct usage is definitely discouraged)
In fact the LABEL root is not used to mount the ‘/’ file system in /etc/fstab. It is mounted by UUID, and the subvolume to be used is named in the options for that btrfs file system.
The linux file system explained (modern version)
and I quote
tree /
The / in the instruction above refers to the root directory. The root directory is the
one from which all other directories branch off from. When you run tree and tell it
to start with /, you will see the whole directory tree, all directories and all the
subdirectories in the whole system, with all their files, fly by.
This seems to be an obvious bug that the mount points need to be sorted by mount point and not by name. Then the storage manager can either mount in the correct order or umount in the correct order.
Manual mounting is always allowed in any order since it is assumed that the user know what they desire to happen.
The unmount appears to be the issue in that logic says that /home, if mounted, should be after / has been mounted and it appears the installer expects that and attempts to unmount /home first. The installer apparently cannot handle the logic required with a situation where /home is hidden below /. A user can determine that and make adjustments, but the installer does not have the logic to switch the sequence for unmounting devices.
Unmounting by name/mount point is the issue here during installation. When /home is mounted first it is seen as /home. Then when / is mounted it has a mount point for /home, but the file system /home is hidden when / is mounted.
When attempting the unmount the system expects /home to be mounted on top of the /home mount point that would be part of / but is not so the unmount process fails. It is actually hidden by / being mounted on top of the same mount point.
Agreed. While there has been discussion about the unmount order, I believe that once the problematic state occurs (where /home is mounted before /), there is no way to unmount them cleanly regardless of the order attempted.
If the “Mount” feature in the storage editor simply prevented incorrect mount operations (i.e., mounting /home before /), this issue would never occur in the first place.
At the best, someone writes a bug report. I might do it in a few days. Feel free to be quicker. Jeff’s posts contain all relevant data.
As mentioned by Neal in the other topic, the anaconda team has limited resources and needs to prioritize. It’s not sure they can spare the time to work through this topic.
I think the bug report is more important, and since it is an installer webui issue may be fixed fairly quickly.
I believe that what Chris meant above is that the developers cannot spend the time reading this topic on the forum, while they will see the bug report immediately.
This is the only time I have seen this reported even though the webui became used for installation a couple releases back (I think f41 or f42) so it cannot be very ‘common’ for users to cause this type error. I suspect a very great majority of users understand the proper sequence of mounting file systems and thus naturally avoided this situation.
The only thing that seems to need fixed is to prevent mounting /home, /boot, /var, etc. unless / is already mounted, similar to what @tk2345 shows above.
Indeed, with regards to the bug of web-ui I mentioned above, it was fixed in a day or two (of course it does take a little longer until it ends up in the ISOs we use).
The idea of common issues was discussed in the other topic, and if and how far anaconda issues can be added there, or separated in an own category. Not sure if we can reliably maintain this to be honest → I fear it becomes another cemetery of obsoleted data that people stop to trust soon.
Exactly. It ends up automatically in their workflow to be prioritized etc, and they then have all necessary information at a glance and not spread over many 50 posts or so That’s all time they cannot invest in fixing bugs.
I added a post as I’m not sure if they can read from the elaboration what the trigger is. But thank you very much for opening a report. That saves time!
@computersavvy could you respond to the question in the bug report? You reproduced the issue itself and identified a trigger. I can just forward hearsay.
Tests based on (Fedora-LXQt-Live-44-20260408.n.0.x86_64.iso)
I tested the LXQT Spin and got the error while I added on the top-level the / mount point and underneath the /home sub volume.
This gave me the error to. I deleted the Btrfs part and started over.
In the end it is not a disk manager issue, it is more the knowledge about btrfs which is not really clearly for the testers.
The ID’s are somehow also a bit confusing.
Is the top-level already a subvolume?
Then it is possible to create a subvolume underneath a other one … should this be possible (see ROF / & /home)?
On the other print screens I see the subvolumes on the same level. Does this make a difference?
Or is it just the disk manager displaying different?
Because the valid Layout not puts the label nor the mountpoint different, they are all level in the beginning.
What I see there seems a mislabeling. I don’t think the first created volume (top level) should be called a subvolume though it can be used the same.
The top level is the btrfs file system volume under which subvolumes are created.
I don’t remember the naming at the time of creation, but will check that out soon
Yes, multilevel subvolumes are possible though far from ideal once you go beyond the first subvolume level.
I believe that the default automatic partitioning creates the file system (vda3) and 2 subvolumes (home) and (root) – both at the top level. What I see there is a 3 level nested subvolume structure.
That’s all time they cannot invest in fixing bugs.
… including a fix for the issue 
