Fedora Account System
Red Hat Associate
Red Hat Customer
The storage editor ignores a BTRFS partition and its subvolumes, if one of the subvolumes has the same name as the partition. If the ignored partition contains the / subvolume, the storage checker reports "You have not defined a root partition (/), which is required for the installation of Fedora to continue." See https://bugzilla.redhat.com/attachment.cgi?id=2159639. If the ignored partition does not contain the / subvolume, the installation continues w/o using the partition and its subvolumes. See https://bugzilla.redhat.com/attachment.cgi?id=2159637. Fedora-Workstation-Live-45_Beta-1.3.x86_64.iso. Reproducible: Always Steps to Reproduce: 1.Create BTRFS partition with a name. 2.Create subvolume with the same name. 3.Press Return to Installation Actual Results: The partition and its subvolumes are missing in the output of the storage checker. Expected Results: The partition and its subvolumes are present in the output of the storage checker. See https://discussion.fedoraproject.org/t/the-partitions-and-mount-points-from-the-manager-are-not-transferred/203255. [Heavily edited]
Created attachment 2159621 [details] @home layout
Created attachment 2159622 [details] @home checker result
Created attachment 2159624 [details] home layout
Created attachment 2159625 [details] home checker result
Created attachment 2159634 [details] btrfs partition
Created attachment 2159635 [details] btrfs partition
Created attachment 2159636 [details] btrfs subvolume
Created attachment 2159637 [details] storage checker
Created attachment 2159638 [details] review
Created attachment 2159639 [details] / subvolume
Proposed as a Blocker for 45-final by Fedora user tk2345 using the blocker tracking app because: The installer fails to continue, if the subvolume is the / subvolume. This violates Fedora_45_Final_Release_Criteria/Disk layouts: The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration.
Discussed during a blocker review meeting [1]. The outcome was: RejectedBlocker (Final) AcceptedFreezeException (Final) - this is rejected on the basis that it's a conditional violation of the criterion (relies on a very precise and uncommon naming setup) and we don't think it's significant enough; it is easy to document and work around (change one of the names). We note the bug is already in F44 (and presumably earlier releases). We accept it as an FE as it would still be good if this could be addressed and it obviously cannot be done post-release [1] https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2026-10-05/
Webui partition name specifies the filesystem label, which is available in /dev/devices/by-label. Webui subvolume name specifies the subvolume path, which is used in /etc/fstab. Filesystem labels and subvolume paths reside in separate namespaces. Using the same name in separate namespaces is not uncommon.
I had a poke around trying to work out what might be causing this. I think this might be an issue in a couple of places: - firstly in blivet because this is what handles all the system storage configuration stuff for Anaconda and if this issue is also present in F44, then webui is not entirely responsible here. - secondly in the webui cockpit storage integration because this is where the issue actually seems to show In blivet/blivet/devices/btrfs.py there is a function, BTRFSVolumeDevice._set_format that sets the volume device name to the file system label. I am not 100% sure, but I suspect that this is where the problem might exist, and possibly we could also check whether a subvolume has the same name here and avoid setting the device name to the file system label if there is a name conflict. The problem of setting the device name on the label becomes apparent when you see what the webui code is doing, because it The webui code in awu/src/components/storage/cockpit-storage-integration/CheckStorageDialog.jsx for preparePartitioning the AddRequest function does this: deviceSpec = getDeviceByName(devices, device); So there is a name collision because if the subvolume and the deviceName match, getDeviceByName is going to return the first in the object which is the volume device, and the subvolume is just not going to be listed. At least this is my understanding of it... but it is rudimentary. I think the resolution in the webui code would be to construct the deviceSpec by checking if there are subvolumes defined and then walking through the subvolumes and adding them, rather than doing a global getDeviceByName I looked at this directly but also used a local model to help analyse the code and describe what was going on, so I have marked this as an assist, because I might be completely wrong about this. However I am hoping that this dive into the code might be enough to help someone either direct this bug to the right folks for a fix, or to inspire someone to look a bit more closely at the code and propose a fix. Assisted by: Qwen3.8-27B-GGUF-UD-Q4_K_X
We actually already merged a patch for this: https://src.fedoraproject.org/rpms/anaconda-webui/c/8566d5ec17acf7ea343681aef766b2a366be139b?branch=rawhide
FEDORA-2026-adc8c83794 (anaconda-webui-88-1.fc45) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-adc8c83794
tk2345, can you please try booting a Live image, installing the update above *before* starting Anaconda, then starting Anaconda and testing whether it fixes this bug? Thanks!
The update fixes this bug, but introduces/contains another bug, see https://bugzilla.redhat.com/show_bug.cgi?id=2547562.
I replied to that bug above. This one is resolved, and more important than the cosmetic one reported, so setting VERIFIED.
FEDORA-2026-adc8c83794 (anaconda-webui-88-1.fc45) has been pushed to the Fedora 45 stable repository. If problem still persists, please make note of it in this bug report.