Bug 2236356 - the software raid disk becomes unusable after click "Rescan" twice
Summary: the software raid disk becomes unusable after click "Rescan" twice
Alias: None
Product: Fedora
Classification: Fedora
Component: python-blivet
Version: 40
Hardware: Unspecified
OS: Linux
Target Milestone: ---
Assignee: Vojtech Trefny
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedBlocker
Depends On:
Blocks: BetaBlocker, F40BetaBlocker AnacondaWebUITracker
TreeView+ depends on / blocked
Reported: 2023-08-31 03:49 UTC by lnie
Modified: 2024-03-06 02:48 UTC (History)
11 users (show)

Fixed In Version: python-blivet-3.9.1-1.fc40
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2024-03-05 22:48:09 UTC
Type: ---

Attachments (Terms of Use)
screencast (1.77 MB, video/webm)
2023-08-31 03:49 UTC, lnie
no flags Details
anaconda.log (5.91 KB, text/plain)
2023-08-31 03:55 UTC, lnie
no flags Details
storage.log (450.43 KB, text/plain)
2023-08-31 03:56 UTC, lnie
no flags Details
anaconda.log (5.84 KB, text/plain)
2023-09-01 03:19 UTC, lnie
no flags Details
storage.log (910.70 KB, text/plain)
2023-09-01 03:20 UTC, lnie
no flags Details
screenshot (128.92 KB, image/png)
2023-09-13 07:37 UTC, lnie
no flags Details

Description lnie 2023-08-31 03:49:06 UTC
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

Comment 1 lnie 2023-08-31 03:49:56 UTC
Created attachment 1986229 [details]

Comment 2 lnie 2023-08-31 03:55:54 UTC
Created attachment 1986231 [details]

Comment 3 lnie 2023-08-31 03:56:32 UTC
Created attachment 1986232 [details]

Comment 4 Vojtech Trefny 2023-08-31 08:08:37 UTC
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).

Comment 5 lnie 2023-09-01 03:18:56 UTC
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

Comment 6 lnie 2023-09-01 03:19:46 UTC
Created attachment 1986489 [details]

Comment 7 lnie 2023-09-01 03:20:34 UTC
Created attachment 1986490 [details]

Comment 8 lnie 2023-09-01 03:24:17 UTC
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.

Comment 9 lnie 2023-09-01 09:28:09 UTC
I checked with btrfs

Comment 10 Fedora Blocker Bugs Application 2023-09-01 09:30:50 UTC
Proposed as a Freeze Exception for 39-beta by Fedora user lnie using the blocker tracking app because:

 This kind of violates this criteria:

Comment 11 Adam Williamson 2023-09-03 17:02:31 UTC
+3 in https://pagure.io/fedora-qa/blocker-review/issue/1248 , marking accepted FE.

Comment 13 Adam Williamson 2023-09-12 22:09:28 UTC
Does this have any impact on GTK UI, or is it webUI specific?

Comment 14 lnie 2023-09-13 07:28:59 UTC
> 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.

Comment 15 lnie 2023-09-13 07:37:00 UTC
Created attachment 1988572 [details]

Comment 16 lnie 2023-09-13 08:01:44 UTC
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.

Comment 17 Adam Williamson 2023-09-13 15:58:52 UTC
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!

Comment 18 lnie 2023-09-22 08:52:46 UTC
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.

Comment 19 Adam Williamson 2024-02-06 17:20:56 UTC
@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'...

Comment 20 Geoffrey Marr 2024-02-13 16:19:45 UTC
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

Comment 21 Vojtech Trefny 2024-02-14 12:18:32 UTC
(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.

Comment 22 Adam Williamson 2024-02-19 18:43:39 UTC
lili, could you retest this with current f40 and provide an update on how it affects webui (workstation live) and gtkui (other images)? Thanks!

Comment 23 Geoffrey Marr 2024-02-20 05:44:08 UTC
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

Comment 24 Vojtech Trefny 2024-02-20 12:47:52 UTC
I can reproduce thus with both the WebUI and GtkUI.

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).

Comment 25 Adam Williamson 2024-02-20 16:23:56 UTC
Thanks for the clear explanation Vojtech! It'll make revoting on this much easier.

Comment 26 lnie 2024-02-21 05:44:28 UTC
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

Comment 27 Vojtech Trefny 2024-02-21 09:28:44 UTC
upstream PR: https://github.com/storaged-project/blivet/pull/1202

Comment 28 František Zatloukal 2024-02-27 10:42:28 UTC
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

Comment 29 Adam Williamson 2024-03-01 20:59:27 UTC
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!

Comment 30 Fedora Update System 2024-03-01 20:59:54 UTC
FEDORA-2024-66b51c2793 (python-blivet-3.9.1-1.fc40) has been submitted as an update to Fedora 40.

Comment 31 Fedora Update System 2024-03-04 01:57:52 UTC
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.

Comment 32 Fedora Update System 2024-03-05 22:48:09 UTC
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.

Comment 33 lnie 2024-03-06 02:17:04 UTC
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:)

Comment 34 Adam Williamson 2024-03-06 02:48:48 UTC
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 :)

Note You need to log in before you can comment on or make changes to this bug.