On Fri, Mar 28, 2003 at 02:12:07PM -0500, Matt Fahrner wrote:
> Yeah, that was one of the possibilities, but one I was hoping to
> avoid. Worst case that's how we'll go.
>
> I was kind of hoping someone from RedHat was listening and might be
> able to suggest what they do to customize the kernel to deal with
> using "/modules/modules.cgz" in the search path...
>
The way I do it is to take the drivers and information I need from the
drvnet image, and add it to the bootnet image (actually I usually just
combine the two images entirely, and use a bootable cd rather than a
floppy). I don't see anything here that indicates if you are rebuilding
the modules.cgz or just new kernels with the drivers you need built in,
but when building a custom modules.cgz, the two things that you really
need to remember are
1. If you add a driver to modules.cgz, you also need to add the info for
it to module-info, pcitable, and possibly modules.dep
2. When rebuilding the modules.cgz, you have to specify the -H crc option
to cpio, or the modules.cgz won't be usable.
Here is a quick overview of how to copy a module from the drvnet modules.cgz
to the bootnet modules.cgz, which will hopefully get you started.
1. First, uncompress the bootnet and mount it on loopback
# zcat bootnet.img > unbootnet.img
# mkdir bootnet
# mount -o loop unbootnet.img bootnet
2. Then uncompress the bootnet initrd, and mount that on loopback
# zcat bootnet/initrd.img > initrd.img
# mkdir initrd
# mount -o loop initrd.img initrd
3. Then loopback mount the drvnet image (it isn't compressed)
# mkdir drvnet
# mount -o loop drvnet.img drvnet
4. Make an uncompressed copy of the modules.cgz for both disks
# zcat drvnet/modules.cgz > modules.cpio
# cpio -i --make-directories < modules.cpio
# mv 2.4.9-e.3BOOT modules-drvnet
(substitute the correct directory name for your bootdisk)
# zcat initrd/modules/modules.cgz > modules.cpio
# cpio -i --make-directories < modules.cpio
5. Now copy whatever modules you need from modules-drvnet to 2.4.9-e3BOOT
(or whatever the version is for the boot disk you are using, this is
the version from the AS 2.1 boot disk).
# cp modules-drvnet/e1000.o 2.4.9-e.3BOOT
# cp modules-drvnet/tg3.o 2.4.9-e.3BOOT
6. If you are going to put this on a floppy, you will probably have to
remove some other drivers from your module directory to make room, I
find the USB ones are generally a good target:
# rm 2.4.9-e.3BOOT/usb*
7. Now you need to look in the drvnet/modinfo file, and copy any entries
that are related to the modules you copied to your new modules directory
into the initrd/modules/module-info file. You can also remove entries
for any modules you deleted (you don't have to, but it might save you a
little space).
8. Now do the same thing for modules.dep and pcitable, copy any relevant
entries from the drvnet files to the initrd/modules files (these two
have the same name on both disks, I don't know why modinfo/module-info
is different).
9. Now you need to repackage and recompress your modules
# find 2.4.9-e.3BOOT > filelist
# cpio -o -H crc < filelist > modules.cpio
# gzip --best modules.cpio
# mv modules.cpio.gz initrd/modules/modules.cgz
(If this last step fails, try removing some other unneeded modules from
the module directory and repeat. Also make sure you don't have any of
the files from step 7 or 8 open in an editor, the swap file that vi or
emacs makes when you have a file open can suck up any extra space on the
disk).
10.Now unmount and recompress the initrd
# umount initrd
# gzip --best initrd.img
# mv initrd.img.gz bootnet/initrd.img
(If this fails, you probably need to remove more modules, although first
you can try getting rid of the *.msg files in bootnet/, they contain
information for the person doing the install, you generally never even
get the chance to seem them while kickstarting)
11.Unmount bootnet and put bootnet.img on a floppy to test.
> Incidentally, the generic boot kernel has a lot of stuff enabled that
> is a total waste (like "parallel port" support, which is hardly useful
> at kickstart time).
>
parallel port support is more than useful if you want to do network installs
on machines without network support, PLIP is much faster than SLIP.
--
Jason Kohles jkohles@xxxxxxxxxx
Senior Engineer Red Hat Professional Consulting
