How do I manually update a Driver Update Disk?

To build a Driver Update Disk (DUD) for use when installing Red Hat Enterprise Linux 4 and newer (2.6 kernels), you should first try to use ddiskit from http://dup.et.redhat.com/ddiskit/.  If, however, you need to manually modify a DUD or create one from scratch, or if you're just curious, below is a description of the contents of a DUD.

A DUD contains the following files:

A DUD is usually distributed as an ext2 filesystem image.  Create an image and mount it with:

dd if=/dev/zero of=/tmp/dud.img bs=1k count=1440
mkfs -t ext2 /tmp/dud.img
mkdir /mnt/dud
mount -o loop /tmp/dud.img /mnt/dud

To generate the above files for our DUD, let's assume we're working with the 2.6.18-128.el5 kernel on x86_64, and we have an updated cciss.ko driver for the HP Smart Array CCISS RAID controller that's already been compiled for this kernel.  Make the following directory structure and copy the updated driver into it.

mkdir -p /tmp/2.6.18-128.el5/x86_64
cp /path/to/updated/cciss.ko /tmp/2.6.18-128.el5/x86_64

Now let's create the modinfo, modules.alias, and other files for the DUD.

modinfo

This file is generated manually.  The first line is almost always "Version 0".  The rest of the file is just a list of the drivers on the DUD followed by 2 tab-indented lines: the first is a driver class (usually scsi or eth), and the second is a short text description of the hardware.  For example:

Version 0
cciss
        scsi
        "Update HP CCISS driver"
tg3
        eth
        "Update Broadcom tg3 gigabit ethernet driver"

modules.alias

This file maps, or aliases, a driver to the PCI device data.  It takes the format "alias pci-data driver", for example:

alias pci:v00000E11d00000046sv00000E11sd00004091bc*sc*i* cciss
alias pci:v00000E11d00000046sv00000E11sd0000409Abc*sc*i* cciss
alias pci:v00000E11d00000046sv00000E11sd0000409Bbc*sc*i* cciss
...
alias pci:v0000103Cd0000323Asv0000103Csd0000324Abc*sc*i* cciss
alias pci:v0000103Cd0000323Asv0000103Csd0000324Bbc*sc*i* cciss
alias pci:v0000103Cd*sv*sd*bc01sc04i* cciss

This file is generated by the depmod tool along with modules.dep, modules.pcimap, modules.usbmap and a number of other files.  Unfortunately, depmod wants to write this file into /lib/modules/VERSION which requires root privileges  and there's no command line option to override this, and furthermore we don't want to modify this file on a running system.  As an  alternative, we can use the dry-run feature (the -n command line flag) which sends all output to stdout, but then we have to manually split this output into the various files.

depmod -b /tmp -n /tmp/2.6.18-128.el5/x86_64/cciss.ko > /tmp/depmod.out
grep ^alias /tmp/depmod.out > /mnt/dud/modules.alias

An alternative method to generating the modules.alias file for driver.ko can be done with the modinfo tool.

modinfo -F alias driver.ko | sed -e 's/^/alias /' -e 's/$/ driver/' > /mnt/dud/modules.alias

On a side-note, the long string of gibberish in the middle of the line is actually a number of fields delimited by lower case letters.  Using the first line from the example above for the cciss driver, we can see:

Hardware vendors are assigned a 16-bit vendor ID by the PCI SIG.  In the above example, Hewlett-Packard (actually, Compaq) has 0x0E11.  You can look up vendor IDs in the file /usr/share/hwdata/pci.ids or at http://www.pcidatabase.com/  The device ID is assigned by the hardware vendor.  In the above example, 0x0046 is one of the device IDs for HP's Smart Array CCISS RAID controllers.

The sub-vendor ID and sub-device ID fields are used for more specific identification of a device.  These may be used to indicate a minor hardware revision, or if the device is an interface to other devices, they may indicate which sub-device you're talking to.

The base class is a generic class of devices, for example, storage or network.  The sub-class is more specific; for storage devices, it may be SCSI or IDE, or for network devices, it may be Ethernet or Token Ring.  A list of PCI classes is available at http://pciids.sourceforge.net/

Finally, the programming interface can be used for devices that have more than one way to talk to them, and the interface value tells you which method to use.

modules.cgz

This is simply a gzip'ed cpio archive — crc format — of the actual drivers (*.ko files).

cd /tmp
find 2.6.18-128.el5 | cpio -o -H crc | gzip -9 > /mnt/dud/modules.cgz

The -9 flag for gzip tells it to compress as much as possible so we can squeeze everything onto a 1.44MB floppy.

modules.dep

This file lists dependencies that modules may have, for example, the cciss module requires the generic scsi_mod driver to be loaded first.  The format is simple: the driver name with a colon followed by a space delimited list of other drivers.

cciss: scsi_mod
8139too: mii

This file is the first generated by the depmod tool, so it should be right at the top of the /tmp/depmod.out we generated earlier for modules.alias, however, it will contain the full path to the driver.  Strip the full path and leave just the driver name.

You can also manually build  a list of the dependencies using the modinfo tool:

modinfo -F depends driver.ko

modules.pcimap

This file contains similar information to modules.alias but in a different format: the driver name followed by the 7 fields shown above in modules.alias.  The base-class and sub-class fields are combined into the single class field, and the class_mask indicates which bits are relevant.  The driver_data field is the programming interface.  Instead of a * for a wildcard, this file uses 0xffffffff.  For example:

# pci module         vendor     device     subvendor  subdevice  class      class_mask driver_data
cciss                0x00000e11 0x0000b060 0x00000e11 0x00004070 0x00000000 0x00000000 0x0
cciss                0x00000e11 0x0000b178 0x00000e11 0x00004080 0x00000000 0x00000000 0x0
cciss                0x00000e11 0x0000b178 0x00000e11 0x00004082 0x00000000 0x00000000 0x0
...
cciss                0x0000103c 0x0000323a 0x0000103c 0x0000324a 0x00000000 0x00000000 0x0
cciss                0x0000103c 0x0000323a 0x0000103c 0x0000324b 0x00000000 0x00000000 0x0
cciss                0x0000103c 0xffffffff 0xffffffff 0xffffffff 0x00010400 0x00ffff00 0x0

Again, using the /tmp/depmod.out that we generated earlier for modules.alias, copy and paste the relevant lines into modules.pcimap.

pcitable

This file also contains similar information to modules.alias and modules.pcimap, but it is not used as much anymore since it's maintained by hand, whereas modules.alias and modules.pcimap can be generated automatically.  This file lists the vendor and device IDs, the driver name, and a text description.

0x0e11  0x4070  "cciss" "Compaq|Smart Array 5300 Controller"
0x0e11  0x4080  "cciss" "Compaq|Smart Array 5i Controller"
0x0e11  0x4082  "cciss" "Compaq|Smart Array 532 Controller"
...

rhdd

A short description of the driver disk, for example:

HP cciss drivers update disk