Bug 2483145

Summary: Anaconda can't detect btrfs subvolume which have @ in the name when using custom partitioning
Product: [Fedora] Fedora Reporter: contact
Component: cockpitAssignee: Martin Pitt <mpitt>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 44CC: alpha, anaconda-maint, chkboom, contact, jvanderwaa, kkoukiou, mkolman, mmarusak, mpitt, patrick, stefw, theking2, w
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: cockpit-365-1.fc45 Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2026-07-30 23:41:23 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Screenshot of configuration used inside virtual machine. none

Description contact 2026-05-29 03:44:31 UTC 
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.
Comment 1 contact 2026-05-29 03:45:35 UTC 
Created attachment 2143270 [details]
Screenshot of configuration used inside virtual machine.
Comment 2 Katerina Koukiou 2026-06-01 15:15:30 UTC 
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)
Comment 3 Katerina Koukiou 2026-06-01 15:29:13 UTC 
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
Comment 4 Katerina Koukiou 2026-07-09 14:44:10 UTC 
*** Bug 2486047 has been marked as a duplicate of this bug. ***
Comment 5 Jelle van der Waa 2026-07-09 17:04:21 UTC 
Cockpitparses the subvol mount option incorrectly, this is fixed in https://github.com/cockpit-project/cockpit/pull/23501
Comment 6 Katerina Koukiou 2026-07-10 14:05:26 UTC 
*** Bug 2446446 has been marked as a duplicate of this bug. ***
Comment 7 Fedora Update System 2026-07-30 20:05:42 UTC 
FEDORA-2026-c7c121cc99 (cockpit-365-1.fc45) has been submitted as an update to Fedora 45.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-c7c121cc99
Comment 8 Fedora Update System 2026-07-30 23:41:23 UTC 
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.