Description of problem:
I have installed a Promise SATA controller and 2 identical Seagate HDs in a Dell
02:01.0 Mass storage controller: Promise Technology, Inc. PDC40718 (SATA 300
TX4) (rev 02)
The kernel correctly sees /dev/sda and /dev/sdb and I have done some tests to
partition and check for DOA HDs. (Bad blocks test, etc.)
Anaconda from the FC6 CDs takes me to the partition configuration screens and
presents me with /dev/mapper/mpathp0 and /dev/mapper/mpath1. This isn't right.
Version-Release number of selected component (if applicable):
anaconda 220.127.116.11 (FC6 gold ISOs)
I pulled up this: http://www.fedoraforum.org/forum/archive/index.php/t-143840.html
Created attachment 148846 [details]
Created attachment 148847 [details]
Talked with pjones on irc a bit. He suggested I try installing with the
"nompath" option to the boot kernel which did work. I was able to install normally.
He also suggested that the serial numbers of my new hard drives were probably
the same, however they are indeed different. I'm attaching the hdparm -I output
from both HDs.
Created attachment 148948 [details]
hdparm -I /dev/sda
Created attachment 148949 [details]
hdparm -I /dev/sdb
This happens for me on F7, using 2 identical Maxtor STM3160812AS 160GB SATA
drives. The board is Intel D945GCCR (no onboard RAID) As per #3, the drives do
not have identical serial numbers
Using nompath resolves the issue. If this situation occurs frequently with
multipath why is it the default?
I can confirm that my machine has the same bug in F7 as well.
I also have the same problem with F7. Two Maxtor 500Gb drives to be formatted
as raid1 and LVM. O/S to be installed on a third drive (80Gb WDC)
/dev/sda WDC WD800BB-32FRA0
/dev/sdb MAXTOR STM350063A
/dev/sdc MAXTOR STM350063A
Machine is a 5 year old P4 (TYAN S2090 Trinity i845 MotherBoard), 1.6 GHz P4
processor 1GB ram.
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.
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
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:
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 no longer reproducible in newer versions of Fedora.
FWIW: The comments in this bug regarding the "nompath" option (thank you!) helped me work around this very issue with my Fedora 10 install yesterday (February 9, 2009). Until I ran the install with the nompath option I could not get Fedora to see my two 320gb SATA Maxstor drives. I tried various BIOS settings and the nodmraid option which did not work. I even dd if=/dev/zero of=/dev/sd[ab] when someone suggested "meta data" on the drives may be leading Fedora install program to only suggest /dev/mapper option.