partition table, jump to the location indicated by it, and do a string
     comparison on the info it finds there - mind you, I don't know that that's
     what it does, but it would seem like a simple way to do it. However,
     "mkinitrd" also reads "/etc/fstab", so that might me how it's done.

     (!) [Faber] It seems RH doesn't have an /etc/mkinitrd directory or files.

     What I'm looking at is the

echo 0x0100 > /proc/sys/kernel/real-root-dev

     If I read this right, it's saying the real-root-dev is device major number
     01 and minor 00 which is ram0 (so maybe Kapil was right about Red Hat
     using two ramdisks? but I see only one pivot_root. :-?) I'm going to
     change it to read

echo 0x802 > /proc/sys/kernel/real-root-dev

     (!) [Ben] I assume you mean something like

disk = /dev/sda
  bios = 0x80
disk = /dev/hda
  bios = 0x81

     (!) [Ben] That would be pretty standard stuff. You could get really wild
     and describe the geometry of "/dev/sda" (see the LILO manual), but I don't
     know that it would be helpful.

     (!) [Kapil] I had a look at RedHat's mkinitrd script also. RedHat's
     procedure seems to be pretty straightforward (no jumping through hoops
     here :) ). The key to understanding the above script is "man nash".

     Both mkdevices and mkrootdev are builtin commands for nash. Quoting from
     the man page:

                              ...............

       mkdevices path
                     Creates device files for all of the block devices
                     listed in /proc/partitions in the directory  spec-
                     fied by path.

       mkrootdev path
                     Makes  path  a  block inode for the device which
                     should be mounted as root. To determine this device
                     nash uses the device suggested by the root= kernel
                     command line  argument (if  root=LABEL  is  used
                     devices  are  probed to find one with that label).
                     If no root= argument is available, /proc/sys/ker-
                     nel/real-root-dev provides the device number.

                                 ...............

     Note that the line after the mkrootdev business is setting a "dummy"
     "real-root-dev" so just replacing "0x100" by "0x810" or some such is not
     likely to work.

     By the way, I always thought that the way to invoke pivot_root was

     cd new_root pivot_root . old_root exec chroot next_command But RedHat's
     script seems to bypass the "change directory" step...

     Hope this helps

     (!) [Ben] That smells like it is talking about some sort of RAM based file
     system  (CRAMFS perhaps?) which is certainly unlikely to be an ext3
     filesystem.

     In other words your problem may not be with the SCSI disk and its ext3
     file system at all! I don't know RH's boot procedure but some of these
     distro boot images have some intermediate "RAM disk" in addition to the
     initrd and do two pivot_roots!

     If you want to stick with the distro's boot procedure, your best bet is to
     examine this procedure in detail.

     0. Check the boot command line.

     1. Open up the initrd image and look at linuxrc.

     Having looked at 0 and 1 for a number of distro's I have come to the
     conclusion that either the guys who produce these distro boot images do
     too  many  drugs  or  they  are  taking care of some really unusual
     eventualities or both :-)

     I seem to remember that it's either CRAMFS or something like that; I'm
     sure Heather knows more about it than I do. It's a "pull yourself up by
     your bootstraps" kind of thing: you boot a RAM-based ext2 mini-"partition"
     (which mounts as "/"), which then loads the appropriate ext3 modules,
     mounts your actual partition, and "pivots" "/" to it.

     The usual reason is to avoid having to recompile the kernel - it makes
     more sense for RH, etc. to make ext3, jfs, jffs, reiserfs, etc. modules
     and let you choose which one you want to use, but the price is having to
     mess with the "initrd"/"pivot_root" stuff. I just compile ext3 right in,
     and never have to mess with it. SCSI, of course, is a different sort of
     animal altogether.

     (!) [Faber] Well, you can have alook at this one. :-) The relevant parts