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:
mageia, nicolas.lecureuil, thierry.vignaud, tmb
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.
For the moment mdadm is not used by the installer.
Is mdadm in consideration for use in the installer?
i would like too. Let see what can be done.
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?
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.
@ 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?
Given Mageia 4 is moving to beta shortly, has there been any changes regarding this bug?
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.
Given that Mageia4 beta is out, should I retry with the new iso's? Or was there no progress here?
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.
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.
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...
Fixed in mga5 RC along bug #14330
*** Bug 9440 has been marked as a duplicate of this bug. ***