Description of Problem: I just was forced to play with a machine hosting 500 GB disk array using 3ware escalade driver. The device itself is identified by 'lspci' and 'lspci -n' as: 00:10.0 RAID bus controller: 3ware Inc: Unknown device 1001 (rev 01) 00:10.0 Class 0104: 13c1:1001 (rev 01) First the good news. Currently this machine is running RH 7.1 distro with updates and 2.4.9-12 kernel booted it "right of the box" without any special hackery. The biggest, "main storage", partition I converted manually to ext3 (but left smaller "system" stuff alone) and everything is running just fine. Bad news and the gist of this report - attempts to install RH 7.2 on the same hardware dismally fail. The following is not really in a chronological order in an attempt to maintain clarity. :-) RH 7.1 was installed using a "standard" installation CD and a driver disk supplied by 3ware. Nothing out of ordinary in the process (with this exceptions that making a file system on 460 GB partition takes a while and configuring X in anaconda fails although there are no problems afterwards). An attempt to use RH 7.2 distribution CD and its drivers floppy fails to recognize the controller and its driver. A peek into a table of PCI ids on this floppy quickly reveals that 13c1:1000, and an associated 3w-xxxx driver entry, are there but 13c1:1001 is missing. Quick addition with an editor and this time on screen flashes few times "Loading 3w-xxxx driver". The problem is that the moment it comes to partitioning screen "there is no such device" shows up. 'lsmod' on a console and 3w-xxxx is not a list. After 'insmod 3w-xxxx' a device shows up and even 'fdisk -l sda' shows an old partition table. But attempts to rebuild a partition table, or even get the disk into a "partition editor" end up with "get_last_sector ioctl: bread returned NULL" errors. What is more even without writing anything to a disk somehow a raid array gets corrupted and after reconstructing it, on a BIOS level, a partition table is gone (although Linux still tries to boot, via lilo, goes pretty far and panics with no init in sight). Next try - RH 7.2 CD and a drivers disk from 3ware. This, a bit surprisingly, appears to work. A driver loads and seems to recognize a disk but attempts to partition the disk end up as before. A syslog for both cases looks remarkably similar and a sample is attached as 'syslog.install'. Another approach - I install RH 7.1 and I try to upgrade to 7.2 a working installation. Regardless if I attempt to use a doctored, to recognize the required PCI id, drivers disk from a new distribution or that one supplied by 3ware, and does not matter what I am doing or not on a command line of a console, I end up informed that "An upgrade is impossible because there are no Linux partitions present" (or words to that effect). This after seeing on a screen lines: <4>SCSI device sda: 976847361 512-byte hdwr sectors (500146 MB) <6>Partition check: <6> sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 > which is absolutely correct. After that line I did not ever got anything else shown or logged. I attach a sample of a syslog from such attempts as 'syslog.update'. From the above it looks like that I could likely hack my custom boot floppies and get RH 7.2 installed but I was not that desperate and had no that much time. I am afraid that the hardware is not mine and it should be already shipped (maybe it will be still around Friday morning) so I will be not able to do much more testing with it. As noted in the opening Linux runs on it, and seems to be quite happy, even if this is not 7.2 distribution. Michal michal
Created attachment 38383 [details] Sample syslog from a failed attempt to install "from scratch"
Created attachment 38384 [details] A sample syslog from an attempt to upgrade a running 7.1 installation
Please see http://www.redhat.com/support/errata/RHBA-2001-131.html for more information on the update disk to fix this problem *** This bug has been marked as a duplicate of 51214 ***
Note that even with "updates" floppy, like mentioned in RHBA-2001-131, an installation and/or upgrade would still fail due to "13c1:1001 problem". If you will look at the report again you will notice that partitioning was only ONE among other troubles and a diskette image refered to in errata only supplies a new 'parted' library. I believe that "CLOSED DUPLICATE" is at this moment an incorrect disposition. If you think that I am wrong close it again.
I tried today and an "updates" floppy, as per RHBA-2001-131, does not really solve the problem. With a "correct" drivers disk I see on a screen, few times, "Loading 3w-xxxx driver", updates load and after that I get "You don't have any Linux partitions. You can't upgrade this system!". By jumping-in "early enough" to a shell prompt and typing 'insmod 3w-xxxx.o' I can avoid the error above. With "updates" floppy present an upgrade proceeds without incidents and the resulting system starts and runs just fine. But this is rather among "don't try this at home" solutions.
Use 'linux updates expert' to add the driver. Already added to the pcitable in kudzu for future releases (which is a dupe of a different bug) *** This bug has been marked as a duplicate of 51214 ***