Hi - I am setting up a Dell Poweredge 2600 as a new samba server using Slackware 12.2. The machine has an mpt Fusion internal scsi interface, a Adaptec 3960 scsi adaptor, and a Sil 3124 Serial ATA Controller.

Initially when I installed the system, I could not be the mpt Fusion driver to work so installed the operating system on /dev/sda which was a drive on the Adaptec. There were two additional drives on the Adaptec which came up as /dev/sdb and /dev/sdc. Also there were two large SATA drives on the Sil controller. They appeared as sdd, and sde.

Today I used mkinitrd -c -k 2.6.27.7 -m aic7xxx:mbcache:jbd:ext3 -f ext3 -r /dev/sda3. My goal was to load the aic7xxx driver only and later load modules to load the other drives. This incantation allowed all the interfaces to load and the drives to appear but now the drive order has changed with the SATA drive being /dev/sda and /dev/sdb.

I would like suggestions on a method control the order the drives appear. I would like sda to be the drive on the adaptec and not a drive on the Sil ATA controller. Also I would like the ATA drives to follow all the scsi drives. They are going to be for backup and I want to remove or swap them around if that would work.

Also I saw another mkinitrd that had an option like --preload module-name which seems like something I want to do.

Thanks...

At least the SCSI drive numbers are not guaranteed to be in fixed order on every boot (probe). So use UUID=******** instead of /dev/sd* if possible.

After some searching on UUID scsi using google I have an idea what you are suggesting and how to get the UUID but I don't know how or where to use it. Would this be incorporated in the initrd somehow? Do I use UUID's in my /etc/fstab? If in the /etc/fstab, would I need to do the initrd? Do I use it in my LILO and change my /etc/fstab to use UUIDs?

However, I think I need to use initrd to control the order of the probing. I am not sure if my initrd is actually controlling the ordering but I do know that without the initrd, the adaptec and Sil cards/drives would work and loading the mptbase/mptscsi module would fail with an "Unexpected doorbell active" message. The system would boot and the drives would be found in such a way the root=sda3 would be correct even though the Sil drives were on. I say that because using the initrd and all the drives on, a different drive comes up as sda and the system will not boot.

From googling I found the following to work using LILO- 'Yes, lilo will boot by uuid. Instead of root= you have to add it to the append line as in append="root=/dev/disk/by-uuid/xxxx"' Is this all I need?

(I am doing this from my mac at home so can't test linux stuff but I would like to get ideas/solutions to get it running tomorrow as soon as possible.)

Thanks...

As I understand your question and previous answer, you would use the UUIDs in LILO and fstab.

I do this with SATA and IDE drives but not SCSI, but should be the same as I understand it. The problem is that you actually cannot control the ordering assigned to the drives at boot, but you can control which physical devices mount where by specifying the unique ID, UUID.

I don't think you need to specify the full path to the device for LILO, just something like root="UUID=abd123..." will suffice.

In case you don't know, you can also use labels on ext2/3 filesystems. Use e2label to assign a label to each drive/partition then use LABEL=mydisk in LILO and fstab. I use labels where possible, sure helps keep things human readable!

This thread contains a link by uppman that will allow you to dynamically determine the type of the root filesystem (ext3, reiser or whatever) and his HowTo provides even better instructions on using root=LABEL=* or root=UUID=* in your lilo.conf or menu.lst. I am using both methods (with GRUB) & copy my boot partition, unmodified, between a desktop (IDE with ext3) & a laptop (SATA with reiserfs) with no problems at all.

TSquaredF, your links were the answer to a problem I had quite similar to the op's but I never got round to fixing it (switching hd between machines & controllers). Thanks for that. (btw, your first link has a typo in it at the start (http://http//www.linuxquestions.org/...orking-671890/ instead of http://www. ...)

Once again thanks for the help. It took a couple of days but I got my system to boot the way I wanted to plus learned about labeling drives and using drive LABEL= statement in my fstab.

The biggest problem, using the drive LABEL in the lilo and initrd, was solved by one of TSquaredF's replies in another thread. That thread included code for patching the initrd-tree/init file and incorporating the blkid program into the initrd-tree and init script to give initrd and lilo access to the drives through disk labels and UUID's. This post was in http://www.linuxquestions.org/questi...2/#post3349090
I found additional libraries were needed for blkid to function. These were libext2fs.so.2, libcom_err.so.2, libpthread.so.0 (which uppman included in his stuff to which TSqured provided a link).

I had one problem that I never got solved. That was using `blkid -c /dev/null` which would only return the information on the first partitions of each drive. My / was on /dev/sda3 at installation so when I tried to boot using the lilo.conf parm of 'root="LABEL=ROOT"' it wouldn't find it. Since I installed /boot on /dev/sda1 (LABEL=BOOT) I used used 'root="LABEL=BOOT"' in my lilo.conf and did the change below to have /dev/sd*3 as the root device which was the goal. I changed:

ROOTDEV=`echo $BLKID_ROOT | awk 'BEGIN{FS=":"}{print $1}'` to
ROOTDEV=`echo $BLKID_ROOT | awk 'BEGIN{FS=":"}{ sub("1","3") ; print $1}'`

Also another change I made that I didn't test to see if it was needed - in init I moved the module loading code to be before the processing of the input from lilo (`cat /proc/cmdline`). This was moved midway through the process and I forgot to move it back.

One thing that surprised me - for my mkinitrd I used:
mkinitrd -c -k 2.6.27.7-smp -m aic7xxx:mbcache:jbd:ext3 -r /dev/sda3
Maybe I didn't need to specify the module for my adaptec card but when I did and ran things later, the mptbase module loaded properly giving me access to the internal scsi controller. That had been a problem previously where I would get a message about the doorbell blah,blah, timeout error, and the controller couldn't be accessed.