Using rh 7.3 on new hardware that has an adaptec scsi controller not supported by the installation cd or boot floppy. Have to use a driver disk to get intallation to take. Want to automate using ks but have to have the scsi module in the boot.img. Have rebuilt the boot.img on the installation boot floppy (see instruction used at the bottom of this thread). After I tried it, the boot up shows it sees the Adaptec controller but the driver does not load. The driver I used (xxxxxx.o) I got from an install that I completed by hand on one of these machines (using the linux dd and a driver disk).

I then reoped the boot.img and found that all the other modules are in white when listed but the one I put in is in green (not sure what that means). My guess is that I have the to do something to that driver to make it work (reompile or somethig?)

I have been making these changes (boot.img) on a machine that has different hardware but don't feel that has anything to do with it but.....?


Any thoughts?

I guess the question I have boils down to "if I list a set of modules and all are white but one that is green, what does that tell me" other than I am screwed!

Does green = executable files?



Instructions I used:

Set up a workplace
mkdir /tmp/unpack
cd /tmp/unpack



Grab something to work with
cp /mnt/cdrom/images/boot.img .



Dig into the disk (any of boot.img, bootnet.img, drivers.ing, etc...)
mkdir disk.dir
mount boot.img disk.dir -o loop



Grab a copy of the initrd and uncompress it
cp disk.dir/initrd.img initrd.img.gz
gunzip initrd.img.gz



Dig into the initrd
mkdir initrd.dir
mount initrd.img initrd.dir -o loop



What is important in the initrd

Initrd calls /linuxrc which then loads drivers from the modules.cgz file which resides in the /modules directory (in the same initrd file). If all you are doing is adding in modules for different hardware into one of the default Red Hat boot disks, then you only need to modify the files that exist in the /modules directory. Files of interest in the /modules directory are module-info, modules.dep, pcitable, and modules.cgz.


Dig into the modules.cgz file
cd /tmp/unpack
mkdir modules
cd modules
zcat ../initrd.dir/modules/modules.cgz | cpio -idvm
cd ..



Modifying modules.cgz


Add and subtract modules to and from modules.cgz as necessary.
You may grab modules from one of the other boot disks available (boot.img, bootnet.img, drivers.img, drvblock.img, drvnet.img, etc).
Remember to keep track of how much space you are using inside modules.cgz, or your initrd may not fit back on the boot disk.
If the module you need is not present on one of these disk images then you will need to build the module.


If you have a ".o" file for your driver, then you're done. Take that .o file with you back to your /tmp/unpack/modules/2.4.7-10BOOT directory.



Modifying module-info


Follow the same format that exists in module-info
First see if there is an existing entry you can copy over from where you are getting the driver (such as from a different boot disk or from one of the drivers disks)
Second, see if you have an entry in your systems /boot/module-info that you can use
Otherwise create your own multi-line entry, such as:

sym53c8xx
scsi
"Symbios 53C896"



Modifying modules.dep


Follow the existing format in the file.
First, try to get a copy from where you got the driver (such as a boot disk or drivers disk).
Second, if you made your own driver then check in your systems /lib/modules/2.4.7-10/modules.dep. Please note that you should convert the format if you use information from your systems modules.dep - specifically your system will have a full path listed, please strip off this full path and only leave the drivername - further please remove all ".o" extensions.
Sample:

usb-storage: usbcore scsi_mod
usb-ohci: usbcore
usb-uhci: usbcore
vfat: fat

Modifying pcitable

See if you have an existing entry for pcitable from wherever you copied the driver from. If you don't have an entry, don't worry, things may work without modifying this file.


Repacking modules.cgz
cd /tmp/unpack/modules
find 2.4.7-2BOOT/ | grep -v "BOOT/$" | cpio -o -H crc >modules.cpio
gzip -9 -n modules.cpio
mv modules.cpio.gz modules.cgz



Repacking initrd.img

Before moving modules.cgz back into the initrd, make sure that it is the same size or smaller than the original one.
cd /tmp/unpack
ls -ltr initrd.dir/modules/modules.cgz modules/modules.cgz


If the new modules.cgz is bigger than the original modules.cgz, then you will most likely get the modules.cgz back into the initrd.img; however, the initrd.img, will then probably be too big for the boot floppy. Consider throwing drivers you don't need out of modules.cgz such as SCSI or Network Cards you don't have or don't plan on using. Even though there is plenty of space available in the initrd.img, there is only so much space available in the boot disk - and gzip is expecting much of the initrd.img file to be blank.

Do the same kind of check on any of the other files you modified, such as modules.cgz, modules.dep, module-info, and pcitable, etc.
cd /tmp/unpack
for X in modules.dep, modules.cgz, module-info, pcitable; do \
ls -ltr modules/$X initrd.dir/modules/$X; done


Once you have compared the sizes of the various files then place them back into the initrd.dir.
cd /tmp/unpack
mv modules/modules.cgz initrd.dir/modules/modules.cgz
mv modules/modules.dep initrd.dir/modules/modules.dep
mv modules/module-info initrd.dir/modules/module-info
mv modules/pcitable initrd.dir/modules/pcitable


We need to blank out the unused portions of initrd - this is needed so gzip doesn't try to compress data that we have already deleted out.
cd /tmp/unpack
dd if=/dez/zero of=initrd.dir/zero
rm initrd.dir/zero


Unmount initrd.dir
(This action finishes writing any cached information out to initrd.img, then it disconnects initrd.img from the initrd.dir directory. This behavior is just the same as working with a floppy under Linux - mount the floppy, work with it, unmount it - unmounting the floppy finishes writing any leftover information to the floppy, then returns to the prompt).
cd /tmp/unpack
umount initrd.dir


Now gzip up initrd.img
Note: The "file" utility can tell you if a file is compressed or not.
cd /tmp/unpack
gzip -9 -n initrd.img
mv initrd.img.gz initrd.img



Repacking the Disk

Before moving the initrd.img back into the disk image, make sure that it is the same size or smaller than the original one.
cd /tmp/unpack
ls -ltr initrd.img disk.dir/initrd.img


If you need more space in the disk image, you are able to remove all the disk.dir/*.msg files, but that is just about all the extra space you can get.

Place the initrd.img back into the disk image
cd /tmp/unpack
mv initrd.img disk.dir/initrd.img


Unmount the disk image - see note above on unmounting initrd.img for an understanding of why it is necessary to unmount the disk image.
cd /tmp/unpack
umount disk.dir