How to build a driver disk for an anaconda install (CentOS 6)

I need to make a driver disk for anaconda. This disk would contain an updated module for the network card of a somewhat recent laptop and the goal is to get a network install of CentOS 6.2 working. I am using cobbler so even the kickstart file itself is on the network. I don't mind if the installation is not completely unattended and I don't mind sticking a USB stick with the driver disk image during the install and manually selecting the correct item, but I do want to keep everything else on the network (kernel image, initrd, kickstart file, RPM repositories).

I already got the updated driver built, and I even have a "kmod" RPM built with the help of /usr/lib/rpm/redhat/kmodtool. Unfortunately I have found absolutely no documentation on what a driver disk looks like.

http://www.phil.muni.cz/~letty/linuxfaq/pracovni/driver-disk-howto is the only link I could find, and it describes the struggle of someone who did the same thing I did - downloaded driver disks and tried to explore them. Unfortunately the format in CentOS 6 seems to have changed and the best I could do is to get anaconda to tell me that: "Driver disk is invalid for this release of CentOS.". The log itself says "cannot find /tmp/drivers/rpms/x86_64/repodata" and until now I have not seen a driver disk with "repodata" on it.

Currently diving into the anaconda source code but I hope someone can point me in the right direction.

I may have found my answer in the anaconda source after all.

To generate a CentOS 6 compatible driver disk, you can create a squashfs image (other filesystems might also work, but squashfs is by far the easiest to create) with the following layout:

• rhdd3 - a file with a simple one-line comment to describe the disk
• .rundepmod - the presence of this file tells the installer that it should run depmod in order to pick up the modules
• rpms/x86_64 - an optional yum repository containing the kmod RPMs
• lib/modules/2.6.32-220.el6.x86_64/... - the actual kernel modules go here; if the driver disk contains an updated driver of an upstream driver, then the directory structure here should match the upstream kernel module location. The version of the kernel should of course match the version of the installer.

And since a picture is worth a thousand words, here is the sample driver disk we use to kickstart recent laptops that need an updated atl1c.ko driver:

$ unsquashfs -ls driver-disk.dd 
Parallel unsquashfs: Using 2 processors
8 inodes (26 blocks) to write

squashfs-root
squashfs-root/.rundepmod
squashfs-root/lib
squashfs-root/lib/modules
squashfs-root/lib/modules/2.6.32-220.el6.x86_64
squashfs-root/lib/modules/2.6.32-220.el6.x86_64/kernel
squashfs-root/lib/modules/2.6.32-220.el6.x86_64/kernel/drivers
squashfs-root/lib/modules/2.6.32-220.el6.x86_64/kernel/drivers/net
squashfs-root/lib/modules/2.6.32-220.el6.x86_64/kernel/drivers/net/atl1c
squashfs-root/lib/modules/2.6.32-220.el6.x86_64/kernel/drivers/net/atl1c/atl1c.ko
squashfs-root/lib/modules/2.6.32-220.el6.x86_64/updates
squashfs-root/rhdd3
squashfs-root/rpms
squashfs-root/rpms/x86_64
squashfs-root/rpms/x86_64/kmod-compat-wireless-3.3_2_n-2.el6.x86_64.rpm
squashfs-root/rpms/x86_64/repodata
squashfs-root/rpms/x86_64/repodata/filelists.xml.gz
squashfs-root/rpms/x86_64/repodata/other.xml.gz
squashfs-root/rpms/x86_64/repodata/primary.xml.gz
squashfs-root/rpms/x86_64/repodata/repomd.xml