Bug 409931

I ran the installation with the nodmraid kernel option and this allowed the
installation to progress past the keyboard language selection.

Hi -

I am seeing the exact same issue.
I have a ASUS P5E-VM DO Motherboard and am suspecting the ICHR9DO AHCI/RAID
controller.
My config has 5 HD's, 2 in a split Raid 1 / 0 config (1/2 each), and 3 in Raid 5.

I have tried turning on / off all devices / management functions in the BIOS,
including Virtualization, the Intel management functions, etc. to no avail.

I also had the same issue w/ i386 32 bit version, and tried Fedora 7 64-bit with
the same results.

I tried FC8 Live - both 32 bit and 64 bit boot fine, but when I try the option
to "install to HD" I get a "pseudo-hang" as described in the first post in the
same place... on the good side Fedora / Gnome is still responsive, so if there
is a way to get an installer dump from the installer at this point let me know
and I'll try to post more details.

On a side note, I was able to install Windows 2000 (w/ some pain in finding the
right ICH9r drivers) and openSUSE installed mostly ok, minus the fact that GRUB
couldn't write to the MBR or boot record of the partitions... but that's a
different issue for a different day...

I've searched the web and various Linux forums, and all signs seem to point to
the dmraid module maybe not recognizing / communicating w/ the ICHR9DO chips, as
trying the noapic, acpi=off, etc. options hasn't helped... (and the reader above
mentions nodmraid helped... I need the raid though...)

How reproducible:
Always

Steps to Reproduce:
1. Boot from DVD (if using live DVD, run Install to Hard Drive after boot)
2. When selecting keyboard language, press Next.

Actual Results:
PC Appears Frozen, Installer Window is frozen, but using Fedora Live Gnome stays
active and works

Expected Results:
Continuation of installation process

Additional info:
Asus P5E-VM DO 
4G PQI PC6400 mem
2 Seagate 80G HD's 1/2 in Raid 1, 1/2 in Raid 0 using Intel ICHR9DO
3 WD 500RE2 HD's in Raid 5 using Intel ICHR9DO
1 Sony DVD reader on JMicron IDE port

*** Bug 233464 has been marked as a duplicate of this bug. ***

*** Bug 241720 has been marked as a duplicate of this bug. ***

*** Bug 237400 has been marked as a duplicate of this bug. ***

*** Bug 229679 has been marked as a duplicate of this bug. ***

*** Bug 227235 has been marked as a duplicate of this bug. ***

*** Bug 219203 has been marked as a duplicate of this bug. ***

*** Bug 218174 has been marked as a duplicate of this bug. ***

*** Bug 217291 has been marked as a duplicate of this bug. ***

*** Bug 213724 has been marked as a duplicate of this bug. ***

*** Bug 213519 has been marked as a duplicate of this bug. ***

*** Bug 208758 has been marked as a duplicate of this bug. ***

*** Bug 190977 has been marked as a duplicate of this bug. ***

*** Bug 190069 has been marked as a duplicate of this bug. ***

*** Bug 252281 has been marked as a duplicate of this bug. ***

*** Bug 249171 has been marked as a duplicate of this bug. ***

*** Bug 247910 has been marked as a duplicate of this bug. ***

*** Bug 243058 has been marked as a duplicate of this bug. ***

*** Bug 374671 has been marked as a duplicate of this bug. ***

*** Bug 216393 has been marked as a duplicate of this bug. ***

There is a bug where the dmraid stuff just blocks.  This bug has not been solved
yet and we are still working to fix it.   However there is a work around.  If
you use nodmraid, the installer will ignore/skip the dmraid stuff allowing the
install to finish.  This is a workaround and does not fix the problem.
There is a long list of bugs that are filed against this problem.  This bug is
one of them.  We have decided to close all the related nodmraid bugs and leave
just one open that will represent all of the others.  So this bug will be the
one that represents the nodmraid issue.

*** Bug 192120 has been marked as a duplicate of this bug. ***

*** Bug 187745 has been marked as a duplicate of this bug. ***

Same here on sun Ultra 20 M2 with 64 and 32 bit Fedora 8 dvd.
This workaround is of no use when one is trying to install onto the raid.
Adding myself to CC list in the hopes of a fix..

Will this be working in fedora 9??

No. I get the same problem with F9. The installer hangs immediately
after keyboard selection. The error I get on the console says:

cl->raidtype=0 rd_type=32
cl->raidtype=0 rd_type=32
cl->raidtype=0 rd_type=32

On the other screens, I get:

<6>device-mapper: multipath emc: version 0.0.3 loaded

and:

INFO   : moving (1) to step findrootparts

Note that I have the onboard RAID disabled in the BIOS.

Surely this should be higher priority/severity? It's completely preventing
me from installing F9...

Tethys,

Have you tried the nodmraid boot option?

Sorry - but nodmraid defeats the purpose of using the built-in raid in the
chipset so I can dual boot and use raid partitions in both OS's on the same HD's
and is not an acceptable option...

This bug should definitely get bumped to a little higher priority - or at least
give us an estimate of when it will be fixed.

If this takes much longer I'm going to install a different distro instead of
waiting for fedora 10 - I tested SUSE a while back and it seemed to work...

Yes, nodmraid gets me past that point where it hangs. But like
Chad, I need to use dmraid on this box. Indeed, the existing
Fedora installation (FC5) on this box works just fine with
dmraid, so it's a regression from something that previously
worked.

Moving this to F9 bugs.

Changing the name so its easier to find this afterwards. 

(In reply to comment #29)
> Sorry - but nodmraid defeats the purpose of using the built-in raid in the
> chipset so I can dual boot and use raid partitions in both OS's on the same HD's
> and is not an acceptable option...

Ok, so try this.  Start the install with nodmraid, and as soon as you get to stage 2 (i.e. when the graphics system has just started up), do the following:

1) hit ctrl+alt+f2 .  You should get to a shell.
2) cd /tmp
3) mkdir raiddata
4) cd raiddata
5) dmraid -D -r
6) cd ..
7) tar cjf raiddata.tar.bz2 raiddata

And then attach that tarball to this bug (you may need to bring up the network, etc.)

Created attachment 315467 [details]
output of requested command

I am having the exact same issue:

nVidia 680i chipset
2x 10k 74GB W.D. Raptors in RAID0 (sda/b) (3rd partition = /)
2x 1TB W.D. in RAID 1 (sdc/d) (sdc1=/boot)

strangely enough i was able to install F8 but have been unable to use the rescue prompt or reinstall since due to this bug.  I have no floppy drive and no IDE devices, it's all SATA.

Created attachment 315543 [details]
/tmp/*.log

Even though anaconda freezes I was still able to gather the log files from terminal 2, hope they help...

Created attachment 316925 [details]
dmraid -D -r output requested

Attached requested data - used Fedora 9 live to boot w/ nodmraid, then ran / collected the dmraid data (allowed me to transfer data on USB rather than starting network, etc. during install attempt...)
Note - my system config right now is -
 - Intel ICH9R chipset (10R on another board shows same thing)
 - Drives 1 & 2 (sda & sdb) are NON-Raid in the Intel Raid manager
 - Drive 3 (sdc) is a group of 3 750GB drives in Raid 5 in the Intel Raid manager

If you need me to add partitions, modify, etc. to gather more data or test out fixes let me know - the system won't be rebuilt for a few weeks at least...

Chad

Created attachment 322384 [details]
Dumps and log files from F10 Beta

To produce this tgz I booted from the F10 Beta CD1 and followed what was asked by Peter Jones in post #33.  I executed the same commands with and without "nodmraid".  I also zipped all log files hoping they can help.

My disk and raid configuration is the same as it is in post #34

the file "dmraid.tay.dd..." is:
# dmraid -tay -dddd -vvvv -f nvidia >> dmraid.tay...

anaconda issue
|-- dmraid
|   |-- dmraid.tay.dddd.vvvv
|   |-- dump
|   |   |-- sda_nvidia.dat
|   |   |-- sda_nvidia.offset
|   |   |-- sda_nvidia.size
|   |   |-- sdb_nvidia.dat
|   |   |-- sdb_nvidia.offset
|   |   |-- sdb_nvidia.size
|   |   |-- sdc_nvidia.dat
|   |   |-- sdc_nvidia.offset
|   |   |-- sdc_nvidia.size
|   |   |-- sdd_nvidia.dat
|   |   |-- sdd_nvidia.offset
|   |   `-- sdd_nvidia.size
|   `-- logs-dmraid.tgz
`-- nodmraid
    |-- dump
    |   |-- sda_nvidia.dat
    |   |-- sda_nvidia.offset
    |   |-- sda_nvidia.size
    |   |-- sdb_nvidia.dat
    |   |-- sdb_nvidia.offset
    |   |-- sdb_nvidia.size
    |   |-- sdc_nvidia.dat
    |   |-- sdc_nvidia.offset
    |   |-- sdc_nvidia.size
    |   |-- sdd_nvidia.dat
    |   |-- sdd_nvidia.offset
    |   `-- sdd_nvidia.size
    `-- logs-nodmraid.tgz

this bug seems similar to bug # 467904

*** Bug 473672 has been marked as a duplicate of this bug. ***

This bug occurs for me with Fedora 10 aswell.
This is extremely frustrating as I've just spent the last 4 hours trying various things to get the installer to work properly until I found this and the 'nodmraid' option (which I'm trying now).

come on it's been reported more the a year ago and it's simple make the installer unusable for all none technical user.
please try to fix it somehow!

Created attachment 330101 [details]
dmraid -D -r output

Even with 'nodmraid' kernel option I cannot get past the 'scanning for dmraid on drives' part of the Fedora 10 installer.
Please fix, this is completely preventing me from installing Fedora 10.

I can confirm that Fedora 10 still has the same problem.
Anaconda did not recognize my Fedora 9 install unless
I specified "nodmraid".  A possibly related issue is
that the "rescue" mode does not work as expected when
combined with "nodmraid".

Is there any way this can get bumped up to at least Med. priority?

Seems dmraid / mdadm are broken in how they identify / read the Intel raid partitions, and seeing as how Intel chipsets are pretty prevalent in the general population I'd think this impacts quite a few people (many of whom just give up before posting anything...)
Seems w/ the data the solution should be pretty straight forward - pick out the areas where Intel writes its array ID's, info / sizes, and then hopefully update dmraid to use the latest functionality of the ICH8R/9R/10R as needed...

So what is the status - will this ever be fixed?

A lot of structural changes have gone into anaconda partitioning code. (we are
rewriting the whole thing :)  so stuff that has been discussed here might not
be relevant anymore. I would like to redirect the interested parties to the new
dmraid tracking bug that will have all the dmraid related issues for the new
anaconda (sorry for doing it again, but we basically have to test again with new code to see if we are on the right track :)

There are a number of underlying causes to these problems, all of which have
been identified and fixed in rawhide we believe.

Unfortunately rawhide is currently not in a good shape to ask you to test it.
We hope to organize a dmraid test day, within some weeks, where we will ask the
community to test dmraid support in rawhide (the upcoming F-11 development
version).

In the mean time we are closing all the open anaconda dmraid bugs, against a
single master bug, for easier tracking, as all the open bugs have the same
underlying cause (2 bugs in pyblock, which have been fixed).

If you're interested in participating in the test day, please add yourself to
the CC of the master bug, I will add a comment there with a pointer to the
announcement for the test day as soon as the date has been fixed.

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

This bug is most often seen when a vendor or user has tested a workstation with hardware RAID under Windows. In particular, I have seen this with the Promise RAID drivers. When drives have been used in that way, tattooing is left on them that is not destroyed when the drives are repartitioned later for software RAID under Linux. Hence the need to resort to nodmraid when booting the installer so that the residual hardware RAID tattooing on the drives is ignored. I don't know of a utility that formats the drive at low enough of a level that will remove the tattooing that the hardware RAID firmware applies to the drives. Again, if the Fedora developers want to reproduce this bug, do the following...

1) Take any machine with Promise hardware RAID support and two SATA drives
2) Setup a mirror in the Promise RAID firmware and install Windows 2000 or XP
with the Promise RAID drivers.
3) Boot and delete the Promise RAID mirror in the firmware of the workstation.

Step three is insufficient to remove the Promise hardware raid tattooing from
the drive. You have to resort to nodmraid to repartition such drives with
software raid under Fedora.

Joel - 
Thanks for the update.  I'll post this in the new bug link as well.
I can verify the following based on some recent testing with that current FC10 release version -
 -  that in the current FC10 release Anaconda / dmraid no longer hang when detecting Intel ICH10R Raid disk partitions.
 -  although it doesn't hang, it still doesn't grab the info for the "fakeRaid" partitions that are already created on the drive

Bottom line - you're 1/2 way there, it's really be nice if dmraid / mdadm recognized the already-there Intel fakeRaid info and used that to determine how disks / partitions are already setup...

I was able to setup a dual boot w/ Windows (using Intel Matrix FakeRaid) and Linux FC10 release on the same drives by doing the following this past weekend:
 - BIOS setting is RAID for ICH10R
 - Have 2 drives assigned for OS - in Raid 1 configuration
 - Windows is installed on 2nd partition of Raid array (has been for a while - I obviously backed up this partition before testing below...)
 - First partition is 1G for Linux Boot - 3rd partition is for Linux / install
 - I installed FC10 doing the following - 
   - Leave BIOS SATA ports in Raid mode (so Windows still see's raid), boot FC10 Installer
   - Anaconda detects 2 actual HD's instead of 1 Raid Drive (but does see partitions as being exactly equal on both HD's, as would be expected since they are mirrored)
   - Setup Raid 1 using software raid format for Partition 1 and 3 for BOTH drives in exactly the same way in anaconda
   - Assigned md0 (part 1 from both drives) to /boot, assigned md1 (part 3 from both drives) to / - both ext3 fs
   - Proceeded to install FC10
   - Note - had to install GRUB on the MBR / boot sector of md0 (partition 1) instead of on master HD MBR's to get this to work correctly...
   - Booted to FC10 - verified using qparted it sees 2 HD's, all partitions, and verified w/ mdadm that md0 / md1 are setup correctly
   - Booted to Windows - Verified Windows still sees 1 Raid Volume in Matrix Storage manager, and see's 2 new partitions on that Raid volume (equivalent md0 / md1) that are both ext3 / linux software raid

Now the issues - 
 - As mdadm / dmraid doesn't recognize the ICH10R Raid Array volume I'm pretty sure that I was just lucky in that creating the 2 software raid partitions in Linux didn't over-write my Intel fakeRaid volume info sector (towards end of hard drive)
   - I'll be dumping sectors from end of disks to find Intel Raid info and will manually shrink the last partition in Linux on the HD's to ensure they can't over-write this data
 - I installed the free ext2fs driver for Windows - I need to validate if I can mount / access the Linux partitions in Windows w/out corrupting them (should be able to)
 - I have to setup FC10 to ignore the Windows partitions as it see's them as 2 separate partitions and writing data to either has "undefined" results (i.e. if the exact same changes aren't made on both drives then which data will you get when Windows reads the mirrored array?)
   - I'm going to try to set mdadm to see the Windows partitions as a Raid 1 array - think I'll have to shrink the Win partitions so mdadm has a place to write the raid info at the end, but then Linux will "think" the partitions are in Raid1 and I can access data off them...

howarth@ - think you missed part of the point of this post - it's not just to have dmraid / mdadm work in Anaconda for installing Linux - it's to be able to dual boot Windows and Linux using the same drives / Raid array setup (using Intel fakeRaid or whatever other raid card w/ fake raid you have...)
This was working in FC<8 then was broken...

Chad