Description of problem: In cockpit storage, when I create a MDRAID0 device, then remove it, and create a MDRAID1 device, anaconda loses track of all disks and says "No usable disks". when I return to anaconda, Destination has "no disks selected". I have to select the RAID device again, go back to storage editor, and return from it again, to make anaconda finally detect a valid layout. IOW, it seems that removing a device breaks the storage detection workflow. The user needs to exit the storage editor, reselect disks, and only then they can continue. Version-Release number of selected component (if applicable): anaconda-42.27.7-1.fc42.x86_64 anaconda-webui-29-1.fc42.noarch cockpit-storaged-336-1.fc42.noarch How reproducible: always Steps to Reproduce: 0. boot under BIOS mode 1. have 3 completely empty disks, without partitioning (just 2 might be enough) 2. select the first two disks 3. enter storage editor 4. create MDRAID0 (I named it 'raid0') on top of both disks (not partitions) 5. create GPT, biosboot, /boot and / on MDRAID0 6. try to return to anaconda, anaconda will complain about stage1 device - biosboot is not supported on MDRAID0 7. delete MDRAID0 8. make sure all disks are have no part table again (create an "unformatted" label on them) 9. create MDRAID1 (I named it 'raid1') on both of them 10. create GPT, biosboot, /boot and / on MDRAID1 11. try to return to anaconda, anaconda says "no usable disks" 12. go to anaconda anyway 13. see that Destination has "no disks selected". Enter it and select the MDRAID1. 14. go to storage editor again 15. make no changes and try to return to anaconda 16. anaconda finally detects a valid layout
Created attachment 2081859 [details] no-usable-disks.png
Created attachment 2081860 [details] anaconda.log
Created attachment 2081861 [details] dbus.log
Created attachment 2081862 [details] packaging.log
Created attachment 2081863 [details] program.log
Created attachment 2081864 [details] storage.log
Proposing for a blocker discussion - anaconda stops detecting devices correctly after a device is removed. https://fedoraproject.org/wiki/Fedora_42_Beta_Release_Criteria#Custom_partitioning However there is a workaround, as mentioned above - just exit the storage editor, select the disks again, and enter the storage editor again.
Created attachment 2082057 [details] bug demonstration video See the reproducer here.
That above was with: anaconda-42.27.8-1.fc42.x86_64 anaconda-webui-29-1.fc42.noarch cockpit-storaged-336-1.fc42.noarch
Does this happen if the RAID0 device exists *before* you enter the installer? Or only if you both create and remove it as part of the install flow?
(In reply to Adam Williamson from comment #10) > Does this happen if the RAID0 device exists *before* you enter the > installer? Or only if you both create and remove it as part of the install > flow? Yes. Boot with an existing MDRAID -> delete it -> create a new one -> "no usable disks" error.
Discussed during the 2025-03-31 blocker review meeting [1]: * AGREED: 2354798 - AcceptedBlocker (Final) - this is accepted as a violation of Beta custom partition criterion "...the installer must be able to: Correctly interpret, and modify as described below ... software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions ... Remove existing storage volumes ... Create mount points backed by ext4 partitions, LVM volumes or btrfs volumes, or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions" [1] https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2025-03-31/f42-blocker-review.2025-03-31-16.01.log.html
Upstream fix: https://github.com/rhinstaller/anaconda-webui/pull/745/
Hint for easy verification in case pre-verification will happen: # Boot the Workstation Live ISO # Enable the packit copr built on the fix PR sudo dnf copr enable packit/rhinstaller-anaconda-webui-745 fedora-42-x86_64 # Update anaconda-webui package sudo dnf update -y anaconda-webui Instructions are also given on the packit copr job linked in the PR: https://dashboard.packit.dev/jobs/copr/2367608
FEDORA-2025-f4b60a3d74 (anaconda-42.27.11-1.fc42 and anaconda-webui-32-1.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2025-f4b60a3d74
Here's an openQA-built netinst that can be used for testing the fix: https://adamwill.fedorapeople.org/04891868-FEDORA-2025-f4b60a3d74-netinst-x86_64.iso
live image, for webui testing: https://adamwill.fedorapeople.org/04891897-Fedora-Workstation-Live-x86_64-FEDORA-2025-f4b60a3d74.iso
man, I'm failing at reproductions today. I tried following kparal's recipe but at step 11, I don't get "no usable disks", I get "'biosboot' partition on MDRAID device raid0 found. Bootloader partitions on MDRAID devices are not supported." Kamil, can you retest this one?
FEDORA-2025-f4b60a3d74 has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-f4b60a3d74` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-f4b60a3d74 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
(In reply to Adam Williamson from comment #18) > man, I'm failing at reproductions today. I tried following kparal's recipe > but at step 11, I don't get "no usable disks", I get "'biosboot' partition > on MDRAID device raid0 found. Bootloader partitions on MDRAID devices are > not supported." That's because of all the other related changes - biosboot is now not supported on any RAID type. That was not the case when I reported this. I'll test it.
When trying to reproduce this with anaconda-42.27.11-1.fc42 and anaconda-webui-32-1.fc42 according to comment 0, I received "d['format-type'] is undefined" error at step 11. I'll upload error logs (even though I don't see the exception there).
Created attachment 2083183 [details] error screenshot
Created attachment 2083184 [details] anaconda.log
Created attachment 2083185 [details] dbus.log
Created attachment 2083186 [details] packaging.log
Created attachment 2083187 [details] program.log
Created attachment 2083188 [details] storage.log
Created attachment 2083189 [details] journal.txt
@Kamil I have quite some trouble reproducing this with the exact error. I am getting a different error when using the same name for the first and second attempt to create the MDRAID. [1] When using different names for the first and second MDRAID devices, it works as expected for me. Assuming this is a race condition I am making some robustification effort: https://github.com/rhinstaller/anaconda-webui/pull/753 [1] See related bug: https://bugzilla.redhat.com/show_bug.cgi?id=2357214
FEDORA-2025-f4b60a3d74 (anaconda-42.27.11-1.fc42 and anaconda-webui-32-1.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.
I'll see if I can reproduce comment 21 reliably... if not, let's close this.
@Kamil I did find the reported bug here, so please keep this report open. To avoid confusion with other RAID-related issues, let's use this bug specifically for the case where the second created RAID device has a different name than the first one. I will send a fix for that scenario. If the two RAID devices created in steps #4 and #9 have the same name, then the issue is related to a different bug in anaconda backend/blivet, which is being tracked here: https://bugzilla.redhat.com/show_bug.cgi?id=2357214 — we're currently investigating that separately.
FEDORA-2025-3f6a3ddd2d (anaconda-42.27.12-1.fc42 and anaconda-webui-33-1.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2025-3f6a3ddd2d
FEDORA-2025-3f6a3ddd2d has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-3f6a3ddd2d` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-3f6a3ddd2d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
With F42 RC 1.1, I've done two different installations when creating, removing and creating a different MDRAID (with a different name), and they worked without any issues.
FEDORA-2025-3f6a3ddd2d (anaconda-42.27.12-1.fc42 and anaconda-webui-33-1.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.