This bug relates to the use of cockpit's storage module as the custom partitioning interface in the webui-based installer. Compared to the custom partitioning flows in the gtk-based installer, cockpit's handling of btrfs seems much more primitive. Unless I'm holding it wrong (I couldn't find any relevant docs), it cannot for instance create multiple btrfs subvolumes within a single volume, or use any of btrfs' RAID capabilities. It handles btrfs 'naively', like anaconda used to, as if it were a simple filesystem like ext4; all you can do is say "create a 15GB btrfs /home partition on this disk", which creates a simple partition, formats it as btrfs and creates a single subvolume that gets mounted at /home. If you then want another "btrfs partition" it creates a new partition with its own single subvolume, and so on. This seems to be broadly tracked upstream at https://github.com/cockpit-project/cockpit/issues/4796 , but there doesn't appear to be much urgency behind improving it. If I'm reading the history correctly, even the current basic handling of creating btrfs volumes was only added very recently. I don't think this clearly violates any release criteria, but it does seem like a significant loss of capability compared to the GTK UI, so I wanted to flag it up for consideration. This is relatively of more importance to Fedora than to RHEL, I believe.
it also *always* gives the subvolume the name "/", which seems a bit weird.
Btrfs suport in Cockpit is coming in pieces, but it is coming steadily and we are aware of its importance to the Installer, and the importance of the Installer to Fedora. We can certainly do a better job of exposing our plans. They probably are somewhere in Jira. I think you might be overlooking some features, such as the ability of creating multiple subvolumes. (Look for "Create subvolume" in the menu of a existing subvolume.) Other features, such as RAID and snapshots, are indeed missing. The UX in general is more clunky than it needs to be, and we have already started to streamline it, see for example https://github.com/cockpit-project/cockpit/issues/19920. Any help is appreciated, of course. Maybe you could do a little self-administered user test and record a quick screencast of how you try to create your desired btrfs storage layout and narrate how you struggle with this. That would be super valuable for us. Thanks!
> I think you might be overlooking some features, such as the ability of creating multiple subvolumes. (Look for "Create subvolume" in the menu of a existing subvolume.) I saw the option, but couldn't figure out how to use it. Trying again, though, I see; you have to "create a btrfs partition", then mount it (which in the installer environment seems to use an effective 'chroot' of /mnt/sysroot, though also see https://bugzilla.redhat.com/show_bug.cgi?id=2263971 ), then you can create a new subvolume (which is not visible at all on the screen you return to immediately after doing it, which is always confusing for the user). I guess the experience was a little confusing at first because it's a very literal representation of how btrfs subvolumes work, which is somewhat confusing conceptually at first. Other UIs I've worked with try to fuzz the details a bit more to provide a more intuitive UX, but I guess it's a valid choice and will probably be appreciated by btrfs experts. Is the requirement to mount the first subvolume before creating others something enforced by btrfs itself?
Btrfs requires the file system mounted in order to create/remove subvolumes. The kernel code (and libbtrfsutil) can create/remove subvolumes by path or fd. The fd variant means the target subvolume does not need to be located in the mounted path. When using btrfs commands in a shell, we're generally limited to creating/removing subvolumes in a path available to the shell. An exception, we can delete subvolumes by subvolume ID, that subvolume does not need to be locatable in any mounted path, just the file system it exists on. Reality is absurd, so I'm a fan of opinionated obfuscation of reality so long as it reduces absurdity. Easier said than done. :D Btrfs has very little opinion about subvolume layouts, so storage UI having an opinion is probably a good thing. But the consequences of opinions aren't so easy to imagine in advance, or work around later. So in the end it's just a bunch of tradeoffs like everything else.
> then you can create a new subvolume (which is not visible at all on the screen you return to immediately after doing it, which is always confusing for the user That's a good point, and one we should fix with higher priority. You can create subvolumes right on the overview, and then they immediately appear in the overview of course, but when you go deep into the hierarchy all the way to the details page for a single subvolume, then you wont see new subvolumes that are created below it. The same is true for snapshots of logical volumes, for example. So... with btrfs, Cockpit is a bit inconsistent: it shows a flat list of subvolumes, but the action for creating new ones treat it like a tree. Maybe we can show the subvolumes in a tree, or maybe we can have a single global "create" action. Or maybe we don't have pages for the individual subvolumes at all. Hmm.
This is not a actionable bug report, sorry.