As shown in the screencast,the reproduce steps: 1.create some partitions including a software-raid 2.click into Mount point assignment and set the mount points accordingly 3.Click Next 4.come back to the Modify storage page 5.Rescan to have the new partitions shown 6.click into Mount point assignment and find the software raid is not list 7.come back to Modify storage page,found the software raid disksize is 0B Reproducible: Always
Created attachment 1986229 [details] screencast
Created attachment 1986231 [details] anaconda.log
Created attachment 1986232 [details] storage.log
The "0 B" size of the RAID array after rescan is really weird, reassigning to blivet for further investigation. Anaconda not showing the array in this case is not a bug, it shouldn't show devices that are unusable (abd from its point of view a device with size 0 is not usable).
A more clear reproducer is: 1.create some partitions including a software-raid 2.come back to main page and click "Rescan" 3.come back to the Modify storage page and find the size becomes 0B,click into mount point assignment page,the software raid is listed with correct size 4.repeat step2 6.click into Mount point assignment ,find the software-raid is not list
Created attachment 1986489 [details] anaconda.log
Created attachment 1986490 [details] storage.log
ie,Rescan-> software-raid size becomes 0B Rescan again-> anaconda realizes software-raid size is 0B and have it not listed on the mount point list.
I checked with btrfs
Proposed as a Freeze Exception for 39-beta by Fedora user lnie using the blocker tracking app because: This kind of violates this criteria: https://fedoraproject.org/wiki/Fedora_39_Beta_Release_Criteria#Custom_partitioning
+3 in https://pagure.io/fedora-qa/blocker-review/issue/1248 , marking accepted FE.
Does this have any impact on GTK UI, or is it webUI specific?
> Does this have any impact on GTK UI, or is it webUI specific? Yes,with gtk ui,click into Installation Destination->blivet-gui and create some partitions(remember set mount points),including a sw-raid one, click into Installation Destination page,and click the Refresh,a pop-up with "Rescan Disks" button will be shown,click that button, then check blivet-gui page,you will find the sw-raid size becomes 0. Btw,there is also a message on that pop-up:All storage changes made using the installer will be lost when you press "Rescan Disks" button. In previous releases,it behaves just likes that,you have to create all the partitions one by one again,which I think is not a desired action. Even in 39,the partitions are not removed,but you have to set all the mount points again,I think is inconvenience.
Created attachment 1988572 [details] screenshot
Er,okay,sorry,that 0 size is actually from previous installation,create a new machine just now,the gtk ui behaves just like previous releases, so no 0 size is shown.But as I said in #comment14, I think it will bring some inconvenience to users, users have to create all the partitions, and set mount points one by one again,even they only want to use that newly added disk for a new mount point,will open a new bug report for that anyway.
So if I'm understanding you correctly, you think there's a bad behaviour when doing the same thing in the old GTK UI, but it's not the same as this bug? If so, let's call this one a webUI bug and bump its FE status to F40, and you can file the GTK UI issue separately (and propose it as an FE if you think it's important enough). Thanks!
Due to this bug,when you boot an installer on a system which has sw-raid partition,and click into blivet-gui page,you will find the raid device is 0B,while 0B device will not be shown on mount point list,as a result, re-using the raid device for /home is not possible.This violates https://fedoraproject.org/wiki/Fedora_39_Beta_Release_Criteria#Custom_partitioning,so propose this as a F40 blocker.
@vtrefny ping - is this still being worked on? as we're nearing F40 Beta time, it's back on the list of 'blocker/FE candidates to be worried about'...
Discussed during the 2024-02-12 blocker review meeting: [0] The decision to delay the classification of this as a blocker bug was made as it would be helpful to clarify for sure what exactly the status of this issue is with webui/cockpit, webui/blivet and the current UI. [0] https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2024-02-12/f40-blocker-review.2024-02-12-17.05.txt
(In reply to Adam Williamson from comment #19) > @vtrefny ping - is this still being worked on? as we're nearing > F40 Beta time, it's back on the list of 'blocker/FE candidates to be worried > about'... I haven't started working on this one yet. It's on my todo list.
lili, could you retest this with current f40 and provide an update on how it affects webui (workstation live) and gtkui (other images)? Thanks!
Discussed during the 2024-02-19 blocker review meeting: [0] The decision to delay the classification of this as a blocker bug was made as we're still clarifying exactly the status with F40 here. The installer team is also looking at a fix. We have added a needinfo to the bug. [0] https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2024-02-19/f40-blocker-review.2024-02-19-17.00.log.txt
I can reproduce thus with both the WebUI and GtkUI. Prerequisites: Two disks with a RAID 1 MD array. With Gtk UI: 1. Select both disks 2. Enter custom partitioning 3. The array is visible, has correct size and can be reused. 4. Rescan disks and re-enter the custom partitioning spoke. 5. The array is still visible, but has size 0 B, unknown filesystem and cannot be reused. With Web UI: 1. Select both disks 2. Enter mountpoint assignment. 3. The array can be select for / mountpoint. 4. Go back to the disk selection and rescan storage. 5. Reenter mountpoint assignment. 6. The array is not available in the mountpoint assignment (because it doesn't show 0 B devices). Note that this happens also with older releases. The problem is that we don't activate MD arrays during storage scan. During the first scan the array is activate (it was automatically assembled during boot) so we can get its size from sysfs and check for filesystem on it, but during the second scan it isn't active (because Anaconda also deactivates/stops the array during the first scan) so we no longer can get the information about the array and filesystem. The fix will be to try to assemble the array during the scan when running from Anaconda (we already activate VGs and LVs during the scan).
Thanks for the clear explanation Vojtech! It'll make revoting on this much easier.
Adam,sorry for the late response,just back from Spring Festival vacation. I booted 20240219.n.0.x86_64 media on a system which has a raid1 mdraid device, With Gtk UI, it performs just as Comment24 claimed, With Web UI,the array can Not be select for mountpoint on step3(which means #Comment18 is still valid) and the size shown is NOT 0 even after step5
upstream PR: https://github.com/storaged-project/blivet/pull/1202
Discussed during the 2024-02-26 blocker review meeting: [1] The decision to classify this bug as a AcceptedBlocker (Beta) was made: "The installer must be able to detect and install to hardware RAID storage devices." [1] https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2024-02-26/f40-blocker-review.2024-02-26-17.01.log.html
I believe the fix was actually in python-blivet-3.9.1 . Marking the F40 update as resolving this bug. The change is already in Rawhide, so lnie, could you re-test with a current Rawhide image - anything from Fedora-Rawhide-20240228.n.0 or later - and see if it's fixed now? Thanks!
FEDORA-2024-66b51c2793 (python-blivet-3.9.1-1.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-66b51c2793
FEDORA-2024-66b51c2793 has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-66b51c2793` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-66b51c2793 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-66b51c2793 (python-blivet-3.9.1-1.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
Adam,I relied through email yesterday, I didn't realize that it isn't being transferred to bug comment until I saw your slack message this morning,and here is what I put: Played with Fedora-Server-dvd-x86_64-Rawhide-20240303.n.1.iso, it seems that the bug is fixed. Didn't check Web UI,as you mentioned in another bug that the webui-specific issues will not block this release, and I'm really pretty busy with other stuff:)
oh, that's weird, I guess bugzilla email replies are broken or something? anyway, thanks for the confirmation! sounds like we can safely leave this closed :)