I have an ASUS P5RD1-V motherboard which has the ALI/ULI SATA RAID chipset.

I'd been running RedHat AS3 on it for some time, using a single IDE (PATA) drive. For a futer project, I need to populate out the SATA drives to provide additional storage space.

I originally upgraded to RedHat AS4.6 in order to get the SATA drivers, but was never able to get the a true hardware driver to work, so I backed out all the driver changes for that. Don't want the software RAID, so eventually decided to use them as straight disks. Turned off the hardware RAID in the bios so that the system would treat them as individual drives.

Now comes the fun part: Redhat sees all four drives as /dev/sda, /dev/sdb, etc. I am able to partition the drives (one big 500MB part), format them, label them, mount them manually, etc.

However, when I add them to /etc/fstab, I can't seem to boot the system. If I add them as "LABEL=xxx" entries, then fsck.ext3 cannot find them by their label names. If I add them as device entries (/dev/sda1 /mount01...) then the fsck of the boot partition fails misserably. In both cases I'm allowed to enter single-user state, at which point I can mount the drives manually, etc.

What's missing? Why will a standard entry not work?

What do /var/log/syslog, /var/log/messages & /var/log/boot say? (These are Debian names. RHAS log files might be named slightly different.)

Also, is the SATA driver a module or linked directly in?

The logs all show no problems up to that point.
The SATA driver is a module and the logs show that the driver is loaded and all the drives are recognized and setup as devices by the time it gets to the error.
The really interesting thing is, after I login to the single-user maintenance shell, I can re-issue the exact fsck command being used by the rc.sysinit script, and it runs perfectly.

Might want to check and see what udev is naming them. They may not be getting named the same every boot causing the hang. Here is a good link if that is the problem

http://www.linuxquestions.org/questi...oddity-563356/

Nope, it's not musical disk drives. They are being assigned the same major/minor numbers on each boot.

I do have it working, but it involved adding
/bin/sleep 10
just prior to the code with does the fsck and mounts. Looks like the driver is taking it's sweet time initiallizing.

Could it be related to the fact the the module is loaded twice?
Kmodule lists the sata_uli driver as OTHER/RAID depending on whether or not I have the hardware RAID bios enable. In either case, rc.sysinit puts "sata_uli" in the $other module list when processing the output from kmodule.

However, the files modules.conf and modprobe.conf both have the line
alias scsi_hostadapter sata_uli
in them, so the output of "modprobe -c" called in rc.sysinit ends up adding the sata_uli module to the $scsi list. Then when rc.sysinit starts loading modules, it loads it twice, once when it processes the $scsi list and once when it processes the $other list.

Should I just remove the alias from the modprobe.conf file? Would that cause any problems? It doesn't look like it should.

Well, imperical testing shows that the double load of the sata_uli module is not the problem. It's just a slow init sequence. For some reason, the extra 10 second wait is needed before the operating system can see the labels on the drives. Anyone know what causes the read and if there is a way to speed it up?