Fedora Account System
Red Hat Associate
Red Hat Customer
During the installation of Fedora 44 using the Anaconda installer, when specifying a custom partition layout using the Storage Editor, if the root partition is inside a btrfs sub-volume it won't be detected as a valid configuration despite the technicality of it being valid on other distributions. When trying to continue installation with the "invalid configuration" Reproducible: Always Steps to Reproduce: 1. Begin the installation and proceed to the "Installation Method" section. 2. Open up the Storage Editor and create a valid partition layout up until the creation of the root partition. 3. Create a btrfs partition with no mount point. 4. Create a sub-volume below the "top-level" sub-volume and mount it to / or root. 5. Exit the Storage Editor and wait for the configuration validation to finish. Actual Results: The Storage Editor will attempt to validate the current configuration, then prompt that the configuration is incorrect. Trying to bypass it using the "Continue Installation" option will simply discard your custom configuration. Expected Results: The Storage Editor should consider the following partition layout valid allowing installation to continue as normal. Additional Information: The configuration used when the bug was found goes as follows: ╔═══════════╦═══════╦═══════════╦══════╦══════════════════════╗ ║ ID ║ Type ║ Location ║ Size ║ Notes ║ ╠═══════════╬═══════╬═══════════╬══════╬══════════════════════╣ ║ vda1 ║ EFI ║ /boot/efi ║ 1GB ║ N/A ║ ╠═══════════╬═══════╬═══════════╬══════╬══════════════════════╣ ║ vda2 ║ ext4 ║ /boot ║ 1GB ║ N/A ║ ╠═══════════╬═══════╬═══════════╬══════╬══════════════════════╣ ║ vda3 ║ swap ║ N/A ║ 8GB ║ Encrypted ║ ╠═══════════╬═══════╬═══════════╬══════╬══════════════════════╣ ║ vda4 ║ btrfs ║ N/A ║ 24GB ║ Encrypted ║ ╠═══════════╬═══════╬═══════════╬══════╬══════════════════════╣ ║ top-level ║ sub ║ N/A ║ N/A ║ ║ ╠═══════════╬═══════╬═══════════╬══════╬══════════════════════╣ ║ @root ║ sub ║ / ║ N/A ║ Child to "top-level" ║ ╠═══════════╬═══════╬═══════════╬══════╬══════════════════════╣ ║ @home ║ sub ║ /home ║ N/A ║ Child to "top-level" ║ ╚═══════════╩═══════╩═══════════╩══════╩══════════════════════╝ ( This is the configuration used on the virtual machine. ) This structure was both used on real hardware and a virtual machine.
Created attachment 2143270 [details] Screenshot of configuration used inside virtual machine.
I was able to reproduce. Thanks for the report. It looks like when using @ as prefix in the names WebUI has an issue parsing the expected layout. Having the btrfs volumes for @root and @home named without the @, resolves the issue (workaround)
When btrfs subvolumes use @-prefixed names (e.g. Fedora-style @root, @home) on an encrypted partition, Cockpit does not populate the subvolumes map in sessionStorage.cockpit_mount_points. Instead it exports a flat filesystem with dir: "/", and the mount point assignments are lost. Anaconda WebUI relies on cockpit-storage prefilled `cockpit_mount_points` to fill the data for manual partitioning requests. The current session storage object with the layout of this bug report is: cockpit_mount_points:"{ "/dev/vda1":{"type":"filesystem","dir":"/boot/efi"} "/dev/mapper/luks-f6e87f02-3219-49e3-ba3f-5508e22f91ec":{"type":"filesystem","dir":"/"}, "/dev/zram0":{"type":"swap"} "/dev/vda3":{"type":"crypto","cleartext_device":"/dev/mapper/luks-f6e87f02-3219-49e3-ba3f-5508e22f91ec","content":{"type":"filesystem","dir":"/"}}, "/dev/vda2":{"type":"filesystem","dir":"/boot"} }" expected object is: ... "/dev/vda3": { "type": "crypto", "cleartext_device": "/dev/mapper/luks-…", "content": { "type": "filesystem", "subvolumes": { "@root": { "dir": "/" }, "@home": { "dir": "/home" } } } } Reference: https://github.com/cockpit-project/cockpit/blob/main/pkg/storaged/btrfs/utils.jsx#L57 Cause: parse_subvol_from_options: [\w\\/]+ rejects @ in names
*** Bug 2486047 has been marked as a duplicate of this bug. ***
Cockpitparses the subvol mount option incorrectly, this is fixed in https://github.com/cockpit-project/cockpit/pull/23501
*** Bug 2446446 has been marked as a duplicate of this bug. ***
FEDORA-2026-c7c121cc99 (cockpit-365-1.fc45) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-c7c121cc99
FEDORA-2026-c7c121cc99 (cockpit-365-1.fc45) has been pushed to the Fedora 45 stable repository. If problem still persists, please make note of it in this bug report.