Bug 9440 - Does not boot on a RAID 1 Chipset Intel on motherboard (dracut is stuck)
Summary: Does not boot on a RAID 1 Chipset Intel on motherboard (dracut is stuck)
Status: RESOLVED DUPLICATE of bug 11289
Alias: None
Product: Mageia
Classification: Unclassified
Component: Installer (show other bugs)
Version: Cauldron
Hardware: i586 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Thomas Backlund
QA Contact:
URL:
Whiteboard:
Keywords: NEEDINFO
: 9823 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-03-18 15:28 CET by Hugues JEAN-BAPTISTE
Modified: 2015-04-28 07:15 CEST (History)
6 users (show)

See Also:
Source RPM: grub
CVE:
Status comment:


Attachments
report.bug.xz (189.15 KB, application/x-xz)
2013-03-27 08:52 CET, Hugues JEAN-BAPTISTE
Details
dracut.lst (105.55 KB, application/octet-stream)
2013-03-27 08:53 CET, Hugues JEAN-BAPTISTE
Details
you mean something like this? (572 bytes, patch)
2013-04-05 17:06 CEST, Thierry Vignaud
Details | Diff
updated patch in order to handle ddf (578 bytes, patch)
2013-04-06 03:26 CEST, Thierry Vignaud
Details | Diff
report.bug from trying the isw/ddf filter (173.20 KB, text/plain)
2013-04-28 16:30 CEST, Thomas Backlund
Details

Description Hugues JEAN-BAPTISTE 2013-03-18 15:28:20 CET
Hi all,

Tested with Mageia 2, Mageia 3 32 and 64 bits
During installation Mageia, the RAID on motherboard is detected.
During partitioning step, I see /dev/sda, /dev/sdb and /dev/mapper/ddf1_XXX !...
I select /dev/mapper/ddf1_xxx.
In the last step, I select grub on /dev/mapper/ddf1_XXX.
At reboot, stop in dracut with disks non reconized.

This configuration works well in Mandriva 2010.1 and 2011.0.

Thanks in advance for your help.

Cheers

Reproducible: 

Steps to Reproduce:
Comment 1 Manuel Hiebel 2013-03-19 00:23:44 CET
you could try beta3 of Mageia 3, as the installer of Mageia 2 will not change any more.
Comment 2 Hugues JEAN-BAPTISTE 2013-03-20 11:37:10 CET
As I have already explained at the beginning of my post, I have tested with Mageia 2, Mageia 3 32 and 64 bits !...

Thank you for your help ;-)
Comment 3 Manuel Hiebel 2013-03-21 00:13:31 CET
oups, ok changing the version then, as the installer of mga2 will not change anymore

CC: (none) => pterjan, thierry.vignaud, tmb
Version: 2 => Cauldron

Comment 4 Hugues JEAN-BAPTISTE 2013-03-22 18:57:04 CET
Anymore, Mandriva 2010.2 works without problem with this controller RAID (LSI MegaRAID SATA) and Mandriva 2011.0 works with just a little adjustment.

But I should prefer installing Mageia ...
Is there, soon, a new version of Mageia 3 with this problem corrected ?
Comment 5 Thierry Vignaud 2013-03-22 19:49:15 CET
Could you attach the following files?
- your /root/drakx/report.bug.xz
- the dracut.lst file resulting from running the following command:
  lsinitrd /boot/initrd.img > /tmp/dracut.lst

Keywords: (none) => NEEDINFO
CC: (none) => mageia
Summary: Does not boot on a RAID 1 Chipset Intel on motherboard => Does not boot on a RAID 1 Chipset Intel on motherboard (dracut is stuck)

Comment 6 Hugues JEAN-BAPTISTE 2013-03-26 10:36:03 CET
I have sent the files directly to the mail address bugzilla-daemon@mageia.org.
But I have received a message "Undelivered mail".
And here I don't see how to join files !...

Thank you for your help
Comment 8 Hugues JEAN-BAPTISTE 2013-03-27 08:52:48 CET
Created attachment 3665 [details]
report.bug.xz
Comment 9 Hugues JEAN-BAPTISTE 2013-03-27 08:53:14 CET
Created attachment 3666 [details]
dracut.lst
Comment 10 Hugues JEAN-BAPTISTE 2013-03-27 19:43:31 CET
I have joined the two files, after rebooting in "rescue mode", because there is not the "/dev/mapper/ddf1...p1" device.
There is only "/dev/md126p1", but it is not the good one.
In "rescue mode", there is not the "/dev/mapper/ddf1...p1" too, but I can do "dmraid -ay" to create it.
Comment 11 Hugues JEAN-BAPTISTE 2013-04-05 11:51:31 CEST
I just have seen a new version "Mageia 3 Beta 4".
Previously my test were made with "Mageia 3 Beta 3".
I hope my problem is solved.
I try it now.
I'll come back soon to inform you about this test !...
Comment 12 Hugues JEAN-BAPTISTE 2013-04-05 15:53:09 CEST
Sorry, but it's the same, "Mageia 3 beta 4" does not work correctly with the RAID controller.
I'm annoyed, there is no help here, Mageia seemed promising, I am forced to look elsewhere.
Comment 13 Thomas Backlund 2013-04-05 16:12:52 CEST
This is becuse both dmraid and mdadm are capable of managing your hw.

the /dev/md126* (and a /dev/md127 container) is mdadm managing your hw

the /dev/mapper/* is dmraid.

You can try to boot with rd.md=0 on kernel/grub command line to prevent mdadm to init the raid setup

That should give dmraid the possibility to init properly.



Thierry, what do you think of filtering dmraid output for isw_* (wich matches all Intel softraid) and block dmraid from activating them in favour of mdadm, wich is the Intel prefferred/supported way nowdays ?
Comment 14 Thierry Vignaud 2013-04-05 16:36:06 CEST
I don't think anything :-)
Is there a parameter to stop dmraid too?
Comment 15 Thomas Backlund 2013-04-05 16:43:46 CEST
(In reply to Thierry Vignaud from comment #14)
> I don't think anything :-)

:)

> Is there a parameter to stop dmraid too?

yep.

rd.dm=0
Comment 16 Thomas Backlund 2013-04-05 16:48:22 CEST
I was thinking along the lines if dmraid -r/s -c -c lists a isw_*,
then dont ask if user want softraid enabled / dont run dmraid -ay,
instead let mdadm detect & enable it.
Comment 17 Thierry Vignaud 2013-04-05 16:48:46 CEST
Then it would be better if Jean-Baptiste could check running the install with "linux rd.dm=0" instead (when prompted on the DVD)
Comment 18 Thierry Vignaud 2013-04-05 17:06:23 CEST
Created attachment 3697 [details]
you mean something like this?

I've no HW to test. Can you test it Thomas?
Comment 19 Thomas Backlund 2013-04-05 17:42:59 CEST
Yep,

I will take if for a spin tonight / tomorrow ... my system with intel raid support is currently busy...
Comment 20 Hugues JEAN-BAPTISTE 2013-04-05 17:43:32 CEST
1) I just checked rd.md=0 in the Grub command line and I have the same message in dracut : "/dev/mapper/ddf_...p1 does not exist".
But I have not /dev/md126p*.
2) My first name is Hugues and my last name is JEAN-BAPTISTE
3) Thierry, you want I check to re-install Mageia 3 with "rd.dm=0" at boot of the install DVD, Is it exact ?
Comment 21 Thierry Vignaud 2013-04-05 18:37:21 CEST
yes.
Comment 22 Hugues JEAN-BAPTISTE 2013-04-05 19:09:55 CEST
I have started with "rd.dm=0" and not "rd.md=0" in the middle of the options from the install.
The install procedure asks me "Option RAID BIOS Software to be activated ?" (Something like that) and I respond "Yes".
The first problem I have seen is during partitioning, I had "/dev/sda", "/dev/sdb" and "/dev/mapper/ddf1_...".
I choose /dev/mapper/ddf1_...". Under Mandriva I have never seen "/dev/sda" and "/dev/sdb" !...
The step where the packages are installed is in progress (2-3 hours).
I will see the result on Monday, perhaps Sunday if I can ...

Thank you for your help.
Comment 23 Thomas Backlund 2013-04-05 19:45:43 CEST
(In reply to Hugues JEAN-BAPTISTE from comment #22)
> I have started with "rd.dm=0" and not "rd.md=0" in the middle of the options
> from the install.
> The install procedure asks me "Option RAID BIOS Software to be activated ?"
> (Something like that) and I respond "Yes".

Sorry for forgetting to mention this... here you should have answered "No",
as answering yes will run dmnraid -ay

> The first problem I have seen is during partitioning, I had "/dev/sda",
> "/dev/sdb" and "/dev/mapper/ddf1_...".
> I choose /dev/mapper/ddf1_...". Under Mandriva I have never seen "/dev/sda"
> and "/dev/sdb" !...

This is because dmraid did not hide  sda/b due to rd.dm=0, and the dmraid -ay
created the /dev/mapper/* so you get all 3.

Hm, looking some more at this it shows it's actually not identifying itself as isw, instead is it identifies as ddf wich is the "Industry Standard" as defined by SNIA

and mdadm handles both ...

So I guess we should filter both isw and ddf and leave them to mdadm as dmraid has not really been maintained for a very long time.


I'll see what it does on my system...
Comment 24 Thierry Vignaud 2013-04-06 03:26:20 CEST
Created attachment 3699 [details]
updated patch in order to handle ddf

Attachment 3697 is obsolete: 0 => 1

Comment 25 Hugues JEAN-BAPTISTE 2013-04-08 15:09:13 CEST
I have just re-started a new installation with "rd.dm=0".
I respond "No" to the question about "RAID BIOS Software".
But now, I have /dev/sda and /dev/sdb, how can I activate the RAID functionality ?
Comment 26 Colin Guthrie 2013-04-09 01:07:03 CEST
FWIW, if we apply the above patch we should also take care to patch initscripts appropriately too to fix up the file /usr/lib/systemd/fedora-storage-init which also takes care to filter out isw_* systems when running dmraid stuff. Very simply to patch, but we just need to remember to do it :)
Comment 27 Hugues JEAN-BAPTISTE 2013-04-12 16:30:00 CEST
Finally, I have found a tutorial for Linux RAID.
And the boot from the hard disk does not work (dracut) ...
I am going to try the same Linux RAID but without the RAID in the BIOS.
I hope this will work ...
Comment 28 Thomas Backlund 2013-04-12 16:40:02 CEST
The installer supports creating Linux raid using mdadm.

The only time you need the bios raid activated is if you dual boot with windows, otherways you are better off using mdadm.
Comment 29 Hugues JEAN-BAPTISTE 2013-04-18 19:41:08 CEST
Nothing I have tested, works !...
I am surprised that UUID parameters are not present in the /etc/mdadm.conf.
Then at "dracut" prompt, "mdadm --assemble --scan" does not work.
I tried to modify manually /etc/mdadm.conf, but it seems that it is necessary to modify initramfs and I don't know ...

Thank you, if you have new ideas ...
Comment 30 Thierry Vignaud 2013-04-22 05:11:57 CEST
(In reply to Thomas Backlund from comment #23)
> I'll see what it does on my system...

Thomas: any news on that?
Comment 31 Thierry Vignaud 2013-04-23 01:59:47 CEST
*** Bug 9823 has been marked as a duplicate of this bug. ***

CC: (none) => j.nieborak

Comment 32 Thomas Backlund 2013-04-24 21:47:46 CEST

Sorry, I didn't get around to testing this, will do so tomorrow

Status: NEW => ASSIGNED
Assignee: bugsquad => tmb

Comment 33 Thomas Backlund 2013-04-28 16:30:16 CEST
Created attachment 3842 [details]
report.bug from trying the isw/ddf filter

So,
I've tried this, but it seems we dont even trigger the filtering, but instead the installer complains about unreadable partition tables and if I answer no to
if I want to wipe them, it ends in a loop with unable to find diskspace to install on.

and mdadm has happily detected and started the md127 imsm containter, and the md126 that is the isw raid1 partition.
Comment 34 Hugues JEAN-BAPTISTE 2013-05-23 09:20:09 CEST
I don't understand, what have I missed !...
Is it the end of the story ?
What can I do to solve my problem ?
Am I the only person wanting to do RAID1, or this hardware is not supported ?
Thank you a new time for your help.
Comment 35 Bernard f6bvp 2013-05-30 17:27:09 CEST
I found the same problem since Mageia 2 and published bug 
https://bugs.mageia.org/show_bug.cgi?id=8761
I signaled it was still present in Mageia pre releases, however 
it seems that install team did not get very much preoccupied about it and when
they started to look at RAID issue it was probably to late and they did not
know how to solve the issue up to the date of Mageia 3 was released.
This is very sad when dealing with data security and hard disk failure prevention.
I hope RAID issue will be considered more seriously by Mageia development and install team when preparing next version release.

CC: (none) => bernard.pidoux

Comment 36 Thierry Vignaud 2013-05-30 21:45:52 CEST
Too many bug reports for a few people.
But you're welcome to suggest patches in order to fix bugs :-)
Comment 37 xboxboy 2013-06-03 01:25:54 CEST
I have similar issue: Replicable on Mageia 2 and 3.

Machine consists of singular boot drive, with additional 2 drives in RAID 1 array using on board intel storage matrix chip (ICH10R in this case).

Earlier Mandriva installs were fine. With raid array operating correctly.

During live install (CD or DVD) of Magiea 2 or 3 the raid array is detected and is displayed in hard drive management correctly as /dev/mapperXXXXXXXXXX.

If this raid array is NOT mounted via fstab the boot process occurs bring x up. But in disk management the individual disks (not the raid array) are seen.

Running 'dmraid -ay' in terminal finds and activates array. It can then be mounted. This is not permanent and must be run each boot: Painful on a home pc.

If the raid array is left to be mounted by fstab then the boot process isn't complete dropping to a rescue/recovery screen.

Activating and mounting array, and then 'mkinitrd' doesn't fix issue either.

I believe we need to be able to force dmraid to find and active raid arrays early in the boot process. How this can be achieved I do not know.

I do not have an understanding of the boot system to understand how and where action needs to be taken. I am willing to be guided though.

CC: (none) => m.p.cleggett

xboxboy 2013-06-03 15:05:23 CEST

CC: m.p.cleggett => (none)

Comment 38 xboxboy 2013-06-09 08:57:53 CEST
Ok all. I have managed to get a solution that fits my situation.

/lib/systemd/fedora-storage-init  filters out isw* named arrays (intel fake raid). Supposedly mdadm is able to run this, except for me it was never picked up by mdadm.

I commented out the four lines that filter isw* arrays and the system boots fine, the arrays are mounted by fstab properly. So for myself I am happy with this result. I understand dmraid may be old and not maintained, but I have run this hardware with dmraid for 5 years now it has been fine.
Comment 39 Dick Gevers 2014-11-15 06:27:58 CET
@tmb: at one point you assigned it to self. Could you review if anything can/will be done? Thanks.
Comment 40 Dick Gevers 2014-11-17 17:25:42 CET
Dunno why, but reporter answers to me by email ( !? ):

Now, I have stopped to use this kind of materials (SATA RAID 1), because it doesn't work.
I use SAS instead, it's not the same price, but it seems there no other solution.

Hugues JEAN-BAPTISTE (hjb@agorinfo.fr)
Comment 41 Thierry Vignaud 2015-04-28 07:15:43 CEST
bug #11289 fixed isw filtering in Mga 5 RC.
We now properly use dmraid.

*** This bug has been marked as a duplicate of bug 11289 ***

Status: ASSIGNED => RESOLVED
Resolution: (none) => DUPLICATE


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