Description of problem: Storage editor fails to prevent mounting btrfs / subvolume over btrfs /home subvolume. This causes the storage checker to fail verifying the layout, prevents unmounting the subvolumes and may prevent the installation to continue. Version-Release number of selected component (if applicable): F44 WS beta. How reproducible: Always. Steps to Reproduce: 1. Enter storage editor. Create /boot, /boot/efi, btrfs /home and / subvolumes. 2. Mount /home and / subvolumes in that order. 3. Press "Return to installation". Actual results: See https://discussion.fedoraproject.org/t/issue-when-trying-to-install-f44-beta-with-anaconda-web-ui/185049 Expected results: Storage editor prevents mounting / over /home, similar to how it prevents mounting /boot over /boot/efi. Additional info:
I'm not sure if this report contains the relevant data to reproduce: I think the summary of Jeff [1] contains the trigger to always reproduce the bug but also to always run the web-ui without triggering the bug. So I read his summary that he can decide if he triggers the bug or not, thus identifying the trigger: Extract of [1]: > I repeated my test exactly as you showed with a VM, although I reversed steps 7 & 8. (It is only logical (and mandatory) that / be mounted before /home) > The installation completed as expected. > > I then tried again but this time I mounted /home before I mounted / (in the order you noted with steps 7 & 8) > > This time it gave me the error already noted. I assume this is the bug: the storage editor does not adjust the order of mounts appropriately unless the users did it already themselves, at least in the given condition -> my assumption that this is a bug is based on the assumption that the installer is intended to determine itself the appropriate order about when to mount what partition, such as determining itself that / must be mounted before /home. [1] https://discussion.fedoraproject.org/t/issue-when-trying-to-install-f44-beta-with-anaconda-web-ui/185049/35 (= post 35)
Proposed as a Blocker for 44-final by Fedora user lruzicka using the blocker tracking app because: REASONING: Violates Beta “Custom partitioning” criterion: installer must reject invalid configurations without crashing. This bug allows creation of an invalid Btrfs subvolume mount layout and fails later during validation, blocking installation. ================================================================================
Just to clarify: this causes the partitioning to occur and destructively change the disk, but then fails to mount the newly-created partitions because the ordering is invalid?
I was able to produce the reported issue in the linked forum topic with an attempted installation on a VM. I first created the partitioning in the storage editor, then tried mounting the new partitions in an invalid order. Specifically I mounted /home before I mounted / while still within the storage editor. The mounts occurred as expected. However, when I then clicked to 'return to installation' I received the notification linked in the initial description above. This error was not due to an invalid partition configuration, but seems to be due to the storage editor allowing an invalid mount sequence that the editor then was unable to unmount the partitions in the correct (expected) order. The Storage editor should not allow mounting file system partitions in an invalid order since doing so hides the first mounted file system (/home) under the root file system (/) and the result is an inability to unmount /home before unmounting /. My suggested solution would be to never allow mounting any file systems created within the storage editor (/home, /var, /boot, /boot/efi, etc) before the root file system (/) has been mounted. I am not sure why the storage editor even needs to mount file systems that are newly created and usually contain no data anyway. There is already a mechanism to prevent mounting /boot over /boot/efi https://discussion.fedoraproject.org/t/issue-when-trying-to-install-f44-beta-with-anaconda-web-ui/185049/48 and this should apply to all file systems created within the storage editor.
This mount order should be prevented by cockpit-storage. Upstream fix: https://github.com/cockpit-project/cockpit/pull/23109
In my testing, I didn't see any destructive behavior and anaconda never crashed. When the user mounts partitions in this order, anaconda is unable to unmount them, which basically locks the user out of any further actions. Unmount is not possible, installation is not possible, not even removing partitions or reformatting the drive is possible. So there's no data loss, the user is most likely forced to quit anaconda and reboot to get out of the situation (or issue manual unmount commands in the correct order, if they know how).
The bug here is that Cockpit's code for detecting "over mounting" did not work for btrfs subvolumes. This is being fixed in https://github.com/cockpit-project/cockpit/pull/23109. Thanks for reporting that! Additionally, we will remove the "Mount" action from the filesystem menu (when Cockpit is used with Anaconda): https://github.com/cockpit-project/cockpit/pull/23115 It was left there "just in case anybody finds it useful", with the idea that people know what they are doing when they open the "Storage editor". But the consensus seems to be now that it is too dangerous, and that people might be lead to think they should actually mount filesystems while that is not necessary during installation. But note that mounting filesystems is not inherently dangerous, it is just that our tools don't work well with hidden mount points and Cockpit tries to protect against that, but failed in the case of btrfs.
AGREED RejectedFinalBlocker AcceptedFinalFreezeException Discussed at the 2026-04-13 (blocker / freeze exception) review meeting: This is an awkward corner case if you encounter it, but you have to do something that's not really necessary to hit it (try and mount filesystems). It doesn't crash the installer or eat any data; you just get a bit stuck. You can recover with a manual unmount, or by rebooting and trying again. We agreed this doesn't really clearly violate either the cited criterion or the Final "Disk layouts" criterion. It's accepted as an FE because we would like to fix this small footgun safely if possible. https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2026-04-13/f44-blocker-review.2026-04-13-16.00.log.txt
Can we backport the fix for F44 today or tomorrow? It would be nice indeed to have this fixed for the Final installers.
Marius merged the fix already: https://github.com/cockpit-project/cockpit/pull/23115 Martin can we have this release for F44 today?
I have tagged cockpit 360.1: https://github.com/cockpit-project/cockpit/releases/tag/360.1 https://src.fedoraproject.org/rpms/cockpit/pull-request/423 There seems to be trouble building rpms because somehow cockpit.spec ended up with "Version: 36360.1.1": https://src.fedoraproject.org/rpms/cockpit/pull-request/423#request_diff
> somehow cockpit.spec ended up with "Version: 36360.1.1": This smells like our fix-spec script has been applied to a soec file that already had the right version. (The script just replaces a "0" in the "Version" line with the right version and if you start with our template that has "Version: 0" and do that twice, you end up with "36360.1.1".)
See https://github.com/cockpit-project/cockpit/pull/23110
>> somehow cockpit.spec ended up with "Version: 36360.1.1": > This smells like our fix-spec script has been applied to a soec file that already had the right version. (The script just replaces a "0" in the "Version" line with the right version and if you start with our template that has "Version: 0" and do that twice, you end up with "36360.1.1".) Ah, this is know and being fixed here: https://github.com/cockpit-project/cockpit/pull/23110 And the release is also being hand-fixed to be able to proceed. Computers! Luckily AI will fix all that.
With https://github.com/cockpit-project/cockpit/pull/23115 I guess the user still sees Unmount actions on all mounted subvolumes. Without Mount actions, the user must have used an external tool to mount them. With an external tool the user can mount the subvolumes in the wrong order, still triggering the issue.
(In reply to tk2345_ from comment #15) > With https://github.com/cockpit-project/cockpit/pull/23115 I guess the user > still sees Unmount actions on all mounted subvolumes. Without Mount actions, > the user must have used an external tool to mount them. With an external > tool the user can mount the subvolumes in the wrong order, still triggering > the issue. You are absolutely right!
FEDORA-2026-ea792bf240 (cockpit-360.1-1.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-ea792bf240
FEDORA-2026-ea792bf240 has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-ea792bf240` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-ea792bf240 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
> There seems to be trouble building rpms because somehow cockpit.spec ended up with "Version: 36360.1.1": I know you guys release fast but this is ridiculous! ;)
I'm still able to mount btrfs subvolumes in Fedora 44 WS RC-1.2, but only in the correct order. "Mount" is not offered for non-btrfs volumes. https://github.com/cockpit-project/cockpit/pull/23109 works. https://github.com/cockpit-project/cockpit/pull/23115 works partially.
FEDORA-2026-ea792bf240 (cockpit-360.1-1.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.
(In reply to tk2345_ from comment #20) > I'm still able to mount btrfs subvolumes in Fedora 44 WS RC-1.2, [...] Ouch, I missed that subvolumes have their own actions. Thanks for reporting!
(In reply to Marius Vollmer from comment #22) > (In reply to tk2345_ from comment #20) > > > I'm still able to mount btrfs subvolumes in Fedora 44 WS RC-1.2, [...] > > Ouch, I missed that subvolumes have their own actions. Thanks for reporting! It is being fixed here: https://github.com/cockpit-project/cockpit/pull/23149 I expect it to be released next week as part of Cockpit 361. Let me know if that is good enough for you.
It would be great if we could get it today (Friday) or Monday for the next RC.
The 361 release is now proposed here: https://src.fedoraproject.org/rpms/cockpit/pull-request/427
Since the issue is closed I can't edit the bodhi update to add this ticket to https://bodhi.fedoraproject.org/updates/FEDORA-2026-adecf05ea9 Adam, what is usually the procedure here?
Bodhi prevents you from adding a closed bug? That's unexpected. Isn't the problem that the update is created by packit and you can't edit it? Either way, reopening this bug, until the remaining fix is pushed. Please try to edit the update again.
FEDORA-2026-adecf05ea9 (cockpit-361-1.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-adecf05ea9
FEDORA-2026-adecf05ea9 has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-adecf05ea9` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-adecf05ea9 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-adecf05ea9 (cockpit-361-1.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.