As shown in the screencasts, error message pops up if we created one encrypted software raid partition(screencast1).The error message says we need rescan the disks,but after we rescan the disks,the software-raid device will not be listed when we set mount point,just as described in #2236356. We will also run into similar problem if we want to use encrypted lvm partitions,but will be able to finish the installation in that situation. The differences are ,as you can see from the screencast3 and screencast4,1)anaconda will ask users to de-encrypt the partitions,2)the partitions will be shown. Reproducible: Always
Created attachment 1986251 [details] screencast1
Created attachment 1986252 [details] screencast2
Created attachment 1986253 [details] screencast
Created attachment 1986254 [details] screencast4
Created attachment 1986255 [details] anaconda.log
Created attachment 1986256 [details] storage.log
Proposed as a Blocker for 39-beta by Fedora user lnie using the blocker tracking app because: This bug violates the criteria: https://fedoraproject.org/wiki/Fedora_39_Beta_Release_Criteria#Custom_partitioning
Looks like Bug 2236538
+4 in https://pagure.io/fedora-qa/blocker-review/issue/1246 , accepted.
Lili was testing with a slightly old image, but I can confirm this on yesterday's Rawhide, with the latest anaconda build. It behaves just as she described. Trying to set an encrypted RAID device as the root partition and hitting Next shows the red error box, which in English reads: "The existing unlocked LUKS device blivet cannot be used for the installation without an encryption key specified for this device. Please, rescan the storage." but if you go back to the "Installation method" screen and rescan the storage, then return to the mount point assignment screen, the same error message is still shown, and now the encrypted RAID device does not appear in the drop-down menu of possible mount point targets at all.
*** Bug 2236538 has been marked as a duplicate of this bug. ***
upstream PR: https://github.com/rhinstaller/anaconda/pull/5146 updates image for Fedora 39: https://vtrefny.fedorapeople.org/img/rhbz2236398.img
OK, looks like it's fixed to me. Thanks!
As webUI has been deferred to F40 and this bug is specific to the webUI flow, it is clearly no longer a blocker.
actually, the logical thing to do is to defer the blocker status to F40, I guess.
FEDORA-2023-7aa321caa4 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-7aa321caa4
FEDORA-2023-7aa321caa4 has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-7aa321caa4` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-7aa321caa4 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-7aa321caa4 has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
The updates is for gtk ui,while this bug is about web ui,reopening.
The fix for this issue is included in the 39.32.3-1 anaconda release[1]. The anaconda-webui package is still available in Fedora 39 so (some) fixes for the Web UI are still being released for it. [1] https://github.com/rhinstaller/anaconda/releases/tag/anaconda-39.32.3-1