Bug 11289 - /lib/systemd/Fedora-storage-init filtering intel raid sets (isw*) to mdadm: Not being activated by mdadm
Summary: /lib/systemd/Fedora-storage-init filtering intel raid sets (isw*) to mdadm: N...
Alias: None
Product: Mageia
Classification: Unclassified
Component: Installer (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: High critical
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
Keywords: NEEDINFO, Triaged
: 9440 (view as bug list)
Depends on:
Blocks: 14330
  Show dependency treegraph
Reported: 2013-09-25 16:05 CEST by xboxboy
Modified: 2015-04-28 07:15 CEST (History)
6 users (show)

See Also:
Source RPM: initscripts
Status comment:


Description xboxboy 2013-09-25 16:05:25 CEST
Description of problem:

Version-Release number of selected component (if applicable):

How reproducible: Has existed in Mageia 2, 3 & persists in couldron.

Steps to Reproduce:
1. Build intel raid array through bios utility
2. Install distro via DVD
3. During install only individual disks are displayed: No raid sets.
4. Boot install, confirm in diskdrake that OS detects individual disks not raid sets.
5. Check /lib/systemd/Fedora-storage-init

All bios raid sets OTHER than isw* are activated by dmraid.

All remaining reaid sets (ie. software and filtered ISW* raid sets) activated by mdadm.

As of mdadm 3.2.1 Intel Storage Matrix (ie. isw* raids) are supported, hence dmraid not being used by fedora-storage-init.

mdadm 3.2.6 is installed by couldron: Why isw* arrays are not detected and activated is beyond my knowledge: Any suggestions/patches can/will be gladly applied/tested.

Commenting out the isw* filter in fedora-storage-init allows dmraid to detect and operate the arrays, but this is not recommended, given that dmraid progress has been slow and that mdadm is the preferred method.

I assigned the severity as critical as inexperienced users may install over their existing array, wiping any data.


Steps to Reproduce:
Manuel Hiebel 2013-09-27 21:31:54 CEST

Keywords: (none) => Triaged
CC: (none) => mageia, nicolas.lecureuil, thierry.vignaud, tmb

Comment 1 xboxboy 2013-10-08 12:53:17 CEST
Updated priority to high: This should be fixed before final release.

Retested with Magiea 4 Alpha 3, problem remains.

During install, the installer does not pick up the raid arrays, rather shows all disks individually.

I'm unsure how mdadm is activated during boot/install. I suspect that this is the cause of the issue, ie: mdadm is not activated or not detecting the intel matrix arrays.

Any patches will be gladly tried.

Priority: Normal => High

Comment 2 Nicolas Lécureuil 2013-10-08 13:17:22 CEST
For the moment mdadm is not used by the installer.
Comment 3 xboxboy 2013-10-08 14:21:37 CEST
Is mdadm in consideration for use in the installer?
Comment 4 Nicolas Lécureuil 2013-10-08 14:45:52 CEST
i would like too. Let see what can be done.
Comment 5 Colin Guthrie 2013-10-09 10:43:01 CEST
mdadm is not used in the installer? When did this change? AFAIK it's always been used for raid support (certainly it's listed in install/share/list.xml and plenty of code seems to shell out to it... Or are you only referring to using it for intel matrix arrays?
Comment 6 Thomas Backlund 2013-10-09 12:22:44 CEST
It is in use for clean md raids, but for fakeraid support there is iirc a "nodmraid" flag to pass to installer to not probe with dmraid, then mdadm should find what it needs

and for dracut to ignore dmraid pass rd.dm=0

I think for "simplicity" we should switch the probing around, so:

1. probe for mdadm supported setups,

2. if no mdadm, probe for dmraid supported setups not already covered by mdadm

3. probe for normal disks.
Comment 7 xboxboy 2013-10-09 12:25:41 CEST
@ Thomas Backlund

Ok, that makes sense. Is there a way to test that? ie. will that work on an installed system? Or will we need to roll it into an install iso?
Comment 8 xboxboy 2013-11-05 04:42:33 CET
Given Mageia 4 is moving to beta shortly, has there been any changes regarding this bug?
Comment 9 Colin Guthrie 2013-11-05 10:27:22 CET
Not sure yet. I'm also wondering if we should kill off the fedora-storage-init stuff as fedora did. AFAIK, LVM and RAID stuff is all auto-assembled via udev rules and such like magic these days... Need to do a lot more testing/fiddling tho' on that front.
Comment 10 xboxboy 2013-11-21 12:03:18 CET
Given that Mageia4 beta is out, should I retry with the new iso's? Or was there no progress here?
Comment 11 xboxboy 2013-11-24 00:53:10 CET
Have done some testing with beta:

Live CD and DVD appear to find the raid arrays correctly when run as a live disc.

Full DVD install could not execute: I have my mbr on SDE (it's an anonomoly of how I set up my box) So the installer complained that SDA is corrupt, so I select NO, then it complains SDB is corrupt, select no, SDC is corrupt, select no, SDD is corrupt, no: Then it looks at SDE with the result of 'I cannot find any room/space' and the installer is stuck: So unable to procede.

With the live DVD I was unable to install from the disc either through the live desktop or from the disc boot menu.
Vladimir Zawalinski 2014-10-19 11:22:59 CEST

CC: (none) => vzawalin1

Vladimir Zawalinski 2014-10-19 11:55:00 CEST

Blocks: (none) => 14330

Comment 12 Dick Gevers 2014-11-15 14:49:05 CET
Content & comments shows this to be against M3 / M4.

But those installers will not change.

So reporter or other knowledgeable people: please 'whiteboard' it as 5beta1 or close as OLD. Thanks.

Keywords: (none) => NEEDINFO

Comment 13 Thierry Vignaud 2015-04-03 16:15:20 CEST
@Thomas, Colin
See https://bugs.mageia.org/show_bug.cgi?id=14330#c4
I think we should just revert
("Do not try and activate ISW raidsets, unless noiswmd is passed (#524355)"

as we still use dmraid for isw whereas FC switched to mdadm...

Source RPM: (none) => initscripts

Comment 14 Thierry Vignaud 2015-04-28 07:13:54 CEST
Fixed in mga5 RC along bug #14330

Resolution: (none) => FIXED

Comment 15 Thierry Vignaud 2015-04-28 07:15:43 CEST
*** Bug 9440 has been marked as a duplicate of this bug. ***

CC: (none) => hjb

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