Bug 2355346

Summary:	SW RAID on top of disks fails to boot (when partitioning layout specified manually inside cockpit-storage)
Product:	[Fedora] Fedora	Reporter:	Katerina Koukiou <kkoukiou>
Component:	anaconda-webui	Assignee:	Katerina Koukiou <kkoukiou>
Status:	NEW ---	QA Contact:
Severity:	urgent	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	jkonecny, kkoukiou, mkolman, mpitt, mvollmer, rvykydal
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	2355323
Bug Blocks:

Description Katerina Koukiou 2025-03-27 14:25:10 UTC

Since last release cockpit-storaged when ran in anaconda mode defaults to using metadata 1.0 for MDRAID.

https://bugzilla.redhat.com/show_bug.cgi?id=2352953

This was done to allow bootloaders on top of RAID as they have the metadata limitations to 0.9, 1.0.

It seems that MDRAID1 with metadata 1.0 which is what currently cockpit-storage uses when creating MDRAID devices, is incorrectly detected as broken by parted when we put GPT table on that.

That causes blivet to try to ask parted to fix it before proceeding with the installation, causing the installer to crash.

anaconda-core-42.29.7
anaconda-webui-30
cockpit-storaged-336

Reproducible: Always

Steps to Reproduce:
1. Choose two disks vda, vdb
2. Go to cockpit-storage, create RAID1 on disks directly
3. Create GPT partition table on the RAID device
4. Create biosboot, /boot and / partitions
5. Exit the installer, proceed to review screen
6. Start the installation
Actual Results:
The installer crashes, either at step 5, before starting either right after starting the installation at step 6.

See attached screencast for exact reproducer.

Unless we can expect a very fast fix for fedora-42 for https://bugzilla.redhat.com/show_bug.cgi?id=2355323, I propose to revert the fix for https://bugzilla.redhat.com/show_bug.cgi?id=2355323, so cockpit-storage can default to 1.2 and disallow bootloaders to be on RAID for now.

This will users to at least use RAID for their rootfs. Putting RAID on stage1 and stage2 device is not as important and also not requested by the release critiria.

Comment 2 Martin Pitt 2025-03-27 15:27:25 UTC

I sent https://github.com/cockpit-project/cockpit/pull/21793 to revert the previous "fix" for bug 2352953, as asked by Katerina.

Comment 3 Marius Vollmer 2025-03-27 18:11:39 UTC

The problem here is that parted is run with a mdraid member. This should not be done.

blkid/udev can correctly distinguish between mdraid on gpt vs gpt on mdraid, and consequently neither UDisks2 nor Cockpit get confused about this.  Whatever code is calling parted on a mdraid member should be fixed.

Check this out. mdraid on bare disks with GPT inside the raid:

# mdadm --create bare --run --level=1 --metadata=1.0 --raid-devices=2 /dev/sda /dev/sdb
mdadm: array /dev/md/bare started.
# parted /dev/md/bare -s mktable gpt
# blkid -p /dev/sda
/dev/sda: UUID="280bac09-2eed-f646-75ca-be09d1268b36" UUID_SUB="1b635ad0-b889-4d26-1c60-3344a98f1aa4" LABEL="dev:bare" VERSION="1.0" TYPE="linux_raid_member" USAGE="raid"
# blkid -p /dev/md/bare
/dev/md/bare: PTUUID="b193ae51-35ac-4d00-8937-91110cfe84a2" PTTYPE="gpt"

Now mdraid on partitions:

# parted /dev/sdc -s mktable gpt
# parted /dev/sdc -s mkpart primary ext2 1M 2G
# parted /dev/sdd -s mktable gpt
# parted /dev/sdd -s mkpart primary ext2 1M 2G
# mdadm --create parts --run --level=1 --metadata=1.0 --raid-devices=2 /dev/sdc1 /dev/sdd1
mdadm: array /dev/md/parts started.
# blkid -p /dev/sdc
/dev/sdc: PTUUID="0b64a21c-a125-4637-ab10-16c0736575b2" PTTYPE="gpt"


Running parted on /dev/sda would be a mistake since it has TYPE="linux_raid_member" and because we know how tricky mdraid metadata 1.0 is.

Comment 4 Fedora Release Engineering 2026-05-06 12:31:18 UTC

This message is a reminder that Fedora Linux 42 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 42 on 2026-05-13.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '42'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 42 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 5 Martin Kolman 2026-05-15 15:21:06 UTC

Looks like this might still be an issue.