Description of problem: There is a problem running the FC5 installer (anaconda) on some hardware. This may be related to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179100 This also was mentioned on the fedora-test list by Dave Cantrell. The problem is that the regular pata drives are not recognized properly and anaconda things the the first drive (hda) is a raid device (the drives have never been used in a raid configuration and FC4 is installed on them also). Booting the install with "nodmraid" fixes the problem. I first had the problem with FC5test2 but was not able to do much testing this cycle. I was surprised to see the problem still exists in the final (GOLD) release and that no mention is made of using "nodmraid" in the RELEASE-NOTES. The hardware is an ABIT AN8 SLI motherboard (Athlon64 x2 4400 processor). Attached are lspci and lspci -v outputs. Version-Release number of selected component (if applicable): FC5 i386 and x86_64 tested How reproducible: yes
Created attachment 126391 [details] lspci
Created attachment 126392 [details] lspci -v
Created attachment 126408 [details] 186059giorio.lspci I have experienced the same anaconda problem, the entry nodmraid have not fixed the problem yet. Attached lspci -v.
Oops ... got my systems confused. The system with the problem has a ASUS A8N-E motherboard with a X2 4400+.
Can you run "dmraid -ay -t" and show us the output?
Output of dmrain -ay -t is: pdc_bjahffii: 0 240121665 linear /dev/hda 0 hda is a Maxtor 6Y120P0 with: Disk /dev/hda: 122.9 GB, 122942324736 bytes 255 heads, 63 sectors/track, 14946 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes from fdisk -l
OK, so at some point this disk (and one other disk) was plugged into a Promise software raid controller, and a raid volume was created. If you do: dmraid -E -f pdc /dev/hda and then restart the installer, does it work? (and are you *sure* booting with "nodmraid" didn't fix it? That option causes it not to even try to detect this, and that should work)
1. Using "nodmraid" with the installer worked fine for me ... another commentor: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186059#c3 said nodmrain did not work for him. 2. will running dmraid -E -f pdc /dev/hda destroy the current partitions (I have other OS installed on this system). 3. I have had a pair of Maxtor 120GB drives for some time and have never used wither software or hardware raid. At one point, one of this drives may (MAY) have been plugged into a promise controller but I certainly did not configure it for raid (at least as far as I know). FC4 did not have the "dmraid" problem when it was installed on this system (and still is installed). 4. Although this system is a "test" system which I can blow away at any time, it will take some time to do the test if the partitions are destroyed. If partitions are not destroyed, I should be able to do the test in a day or so.
<i>2. will running dmraid -E -f pdc /dev/hda destroy the current partitions (I have other OS installed on this system).</i> Well, it will wipe the metadata from the PDC raid controller. It's hard to say how safe that is. Since we can identify it, that *probably* means it's in an unallocated block of some filesystem, and thus safe. But there's not a very good way to be sure. It should leave the *partition table* intact; typically the raid metadata is near the end of the disk. FC4 doesn't support dmraid at all, so it's no surprise that it doesn't have any problem.
Ok, I gave it a try but I don't believe it worked: [root@raven ~]# dmraid -E -f pdc /dev/hda ERROR: option missing/invalid option combination with -f I assume it did not work so I did not try reinstalling.
I used dmraid -E -r It's safe for the partition table, and fixes the problem.
closing ... I "finally" got around to fixing things ... "dmraid -E -r" work whereas "dmraid -E -f" does not work. I am not sure how pdc was ever set but it has been erased now.