Bug 213738

Created attachment 140174 [details]
Anacanda Dump

Does booting with 'linux nodmraid' help?

I found the problem. I had created a RAID 5 set before the first install and 
got this error. I then disabled RAID in my motherboards BIOS and still got the 
error. To correct the problem I enabled RAID in my BIOS and deleted the RAID 5 
set and then disabled RAID in the BIOS and was able to install.

Yeah, we need to handle this case better

I am seeing a very similar issue with my ASUS K8N-DL Mobo.  It has an Nvidia
CK804 and a Silicon Image Raid Controller on it.  It looks like the installer is
attempting to detect a RAID set even if there is no RAID set configured.  I was
unable to install FC6(x86_64) at all as it would fail after building the file
systems and attempting to mount them.

There is a message on one of the consoles(ctrl-alt-f1 I think) that shows
something detecting a SIL and NVIDIA RAID set on the disks and then it decides
to use Nvidia.  I think it's related, but not sure.

In the end, I can't install as the only hard disk device that my machine ever
detects under FC6 is /dev/mapper/mpath0 .  It never sees /dev/sda or /dev/sdb no
matter where I connect them.

We encountered the same issue with an HP X4000 workstation using an Symbios SCSI
Controller and two Seagate SCSI disks. We were not able to install FC6 an that
machine due to the described problems.

I have the same Traceback as Dewayne's (Comment #1) with FC6 with an ASUS
P5ND2-SLI mb with 3 SATA Seagate drives in a RAID5 array.  The nVidia driver for
FC5 is rejected by anaconda when offered with 'linux dd'.  

RE: Comment #2 From Jeremy Katz

"Does booting with 'linux nodmraid' help?"

It does help somewhat.  It allows the installer to proceed without attempting to
start the RAID array, and allows for installation on a disk which is not part of
the array, but does not allow installation on the array per se.  Be careful
here: it will also allow installation on a disk which is an element of an
established array, presenting each as a separate disk.  This naturally
compromises the array. 

Please inform me if a resolution to this problem becomes available.  Gracious
thanks.

is this still an issue in f9?

I did not see this issue in F8.

Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers

This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen thus bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.