Description of problem: Anaconda now seems to check whether biosboot is located on a supported device (for MDRAID, it needs to be MDRAID1, and not MDRAID0). However, it doesn't check /boot location. If I place biosboot on a standard disk, and /boot on MDRAID0, Anaconda accepts this layout. However, the installed system doesn't boot. Grub complains about unknown filesystem. 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: 1. boot in BIOS mode 2. have 3 completely empty disks, without partitioning 3. select all disks 4. enter storage editor 5. create GPT on the first disk, and put biosboot there 6. create MDRAID0 on top the last two disks (not partitions) 7. create GPT, /boot and / on MDRAID0 8. anaconda accepts this layout, install 9. see grub not booting the installed system
Created attachment 2081868 [details] layout.png
Created attachment 2081869 [details] layout-valid.png
Created attachment 2081870 [details] grub-unknown-filesystem.png
Created attachment 2081871 [details] anaconda.log
Created attachment 2081872 [details] dbus.log
Created attachment 2081873 [details] journal.log
Created attachment 2081874 [details] packaging.log
Created attachment 2081875 [details] program.log
Created attachment 2081876 [details] storage.log
Proposing for a blocker discussion. Anaconda accepts a non-working disk layout. Perhaps related to: "Reject or disallow invalid disk and volume configurations without crashing." https://fedoraproject.org/wiki/Fedora_42_Beta_Release_Criteria#Custom_partitioning and https://fedoraproject.org/wiki/Fedora_42_Final_Release_Criteria#Disk_layouts
The supported RAID levels for stage2 are hardcoded in anaconda: https://github.com/rhinstaller/anaconda/blob/main/pyanaconda/modules/storage/bootloader/grub2.py#L120 RAID0 should according to the list above not be an issue for /boot.
The same scenario with MDRAID1 boots OK.
For the record I just added an upstream test reproducer for this. https://github.com/rhinstaller/anaconda-webui/pull/729
@Kamil I was able to reproduce almost the same issue with GTK UI from f41. With the following reproducer: * Three disks, vda, vdb, vdc * Select all of the and choose Custom partitioning with Blivet GUI * Create a biosboot partition on vda * Create a RAID0 device with ext4 on vdb and vdc and mount /boot (blivet GUI creates automatically the vdb1 and vdc1 partitions and creates RAID0 on the partitions) * Create a RAID0 device with ext4 on the rest of space on vdb and vdc and mount / Proceed with the installation. There is a warning shown, that biosboot is on seperate disk than /boot, but one can proceed with the installation. warning: "boot loader stage2 device %(stage2dev)s is on a multi-disk array, but boot loader stage1 device %(stage1dev)s is not part of this array.The stage1 boot loader will only be installed to a single drive." Finish the installation and reboot, resulting in the exact error screen in GRUB. Please verify my scenario that GTK is also broken for /boot on RAID0. I am in the meantime working on a global fix.
Upstream fix: https://github.com/rhinstaller/anaconda/pull/6311
New PR: https://github.com/rhinstaller/anaconda/pull/6314
+3 in https://pagure.io/fedora-qa/blocker-review/issue/1810 , marking accepted blocker.
FEDORA-2025-900bb2b163 (anaconda-42.27.10-1.fc42 and anaconda-webui-31-1.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2025-900bb2b163
FEDORA-2025-900bb2b163 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-900bb2b163` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-900bb2b163 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-900bb2b163 (anaconda-42.27.10-1.fc42 and anaconda-webui-31-1.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.
This bug hasn't seen any change, it can still be reproduced exactly as described in the reproducer. Tested with: cockpit-storaged-336.2-1.fc42.noarch anaconda-42.27.10-1.fc42.x86_64 anaconda-webui-31-1.fc42.noarch
You are right Kamil, sorry for the back and forward. Upstream fix: https://github.com/rhinstaller/anaconda/pull/6324 I verified this also with anaconda-webui directly.
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
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.
This is fixed, anaconda now rejects the layout from comment 0. However, I discovered bug 2357128 when I tried to make anaconda happy.
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.