Working with kernel modules on the IFL Network Boot Disk
Please note: This article applies to version 1 product(s) only.
This article covers the subject of kernel modules, and some commands that can be used to work with them while using the IFL Network Boot Disk. It also describes how module loading can modified (if necessary) by creating a customized version the disk.While it should not normally be necessary to deal with this information, it can be useful in determining if/why certain hardware is not being detected. In some cases, it may also be possible to correct a module-related issue by modifying the IFL disk. Note that this article does not apply to the standard IFL Boot Disk, since it does not use kernel modules.
Background information:
Most kernel modules are either drivers to support specific hardware, or code that enables certain features and capabilities, such as support for specific file systems, networking features etc. Modules are actually part of the kernel, but are compiled as separate files so that they can be loaded into memory if needed, but left unloaded if not.
On a Linux system, the kernel module files will reside in a series of sub-directories under the /lib/modules/<kernel-version> directory. As a more specific example, all drivers for network adapters on the IFL Network Boot Disk are located in the /lib/modules/2.6.17.13-IFLnet/kernel/drivers/net directory.
Typically, modules required for hardware support are loaded as the hardware is detected while the system boots. Other modules may be loaded as needed while the system runs. For the most part, all required modules will load automatically, and no user action is required. Most issues with kernel modules will arise in the context of a specific hardware item not working as expected (network card, mass storage controller etc.). Two commands that can be helpful in troubleshooting modules are lsmod and modprobe.
The lsmod command (list loaded modules):
The lsmod command will simply list all loaded modules. It has no options, but it is helpful to know that modules are always listed in the reverse order in which they were loaded. The following is an example output from lsmod:
Module Size Used by Not taintedIn this case, pcspkr was the first module loaded, and nls_cp437 was the last. The "Used by" column shows how many other modules are using (depend on) each listed module, followed by the names of those modules. For example, it can be seen above that the pcnet32 module depends on the mii module, and therefore the mii module gets loaded first. Module dependencies are defined in the file /lib/modules/2.6.17.13-IFLnet/modules.dep, which is used by the modprobe command when loading modules.
nls_cp437 5376 0
shpchp 35480 0
pci_hotplug 25652 1 shpchp
piix 8964 0 [permanent]generic 3972 0 [permanent]pcnet32 27652 0
mii 4864 1 pcnet32
pcspkr 2176 0
The modprobe command (load or unload modules):
Modprobe has several command line options, but the most frequently used ones are the following:
Load a module:
modprobe <module name>
Unload a module:
modprobe -r <module name>
Show dependencies for a module:
modprobe --show-depends <module name>
As an example, the pcskpr module shown in the list above can be removed with the command 'modprobe -r pcspkr', and then reloaded with the command 'modprobe pcspkr'. Starting with the list of modules shown above, this will result in the lsmod output shown below. Note that pcspkr is listed first because it is now the last module that was loaded:
Module Size Used by Not tainted
pcspkr 2176 0
nls_cp437 5376 0
shpchp 35480 0
pci_hotplug 25652 1 shpchp
piix 8964 0 [permanent]generic 3972 0 [permanent]pcnet32 27652 0
mii 4864 1 pcnet32
Some
modules depend on other modules being loaded before they can be loaded
themselves. An example of that can be seen in the list above where the
pcnet32 module depends on the mii module. The modprobe command will
automatically determine a module's dependencies, and will load those
modules if they are not already loaded. In the example above, if
neither pcnet32 or mii were loaded, the command 'modprobe pcnet32'
would first load mii, and then pcnet32. A module's dependencies can be
listed with modprobe's --show-depends option.
Example: The command 'modprobe --show-depends pcnet32' will result in the following output:
insmod /lib/modules/2.6.17.13-IFLnet/kernel/drivers/net/mii.ko
insmod /lib/modules/2.6.17.13-IFLnet/kernel/drivers/net/pcnet32.ko
Creating a customized ISO file with modified module loading:
The IFL Network Boot Disk can be customized in a number of ways. In general, this involves the steps of uncommenting and editing one or more options in the file config.txt, and then building a customized ISO file by running the makeISO script. A customized ISO file can only be created from Linux.
The complete procedure to do this is outlined below, followed by an explanation of the MODULES option (which is the option in config.txt that controls module loading):
1. Unzip the IFL Network Boot Disk
archive. It is highly recommended that this be done on a Linux file
system (such as ext2/3 or reiserfs) to avoid potential issues with
upper/lower case and file permissions.
2. Unzip the
config.zip file included in the archive. The files in config.zip should
be extracted in the same directory as the rest of the archive (not in a
sub-directory).
3. Uncomment and edit the MODULES option in config.txt as described below. This can be accomplished with any text editor.
4. Run the makeISO script. Doing this will create the file iflnet-custom.iso,
which can then be burned to CD/DVD. From the archive directory, the
makeISO script can be executed with the command './makeISO'
The specific case of module loading is controlled by the MODULES option in config.txt. By uncommenting and editing this option line, you can modify module load behavior in the following ways:
1. To ensure that one or more modules will be loaded, list them inside the parenthesis, with a space between them (if more than one). Note that modules loaded in this manner will always be loaded before any other modules are loaded automatically by the normal boot process. As an example, the following will ensure that module1 and module2 will be loaded (and will be loaded in that order):
MODULES=(module1 module2)
2. To ensure that one or more modules will not be loaded, list them inside the parenthesis with a "!" in front of them. As an example, the following will ensure that module1 will be not be loaded:
MODULES=(!module1)
3. To ensure that modules are loaded in a specified order, list them in that order inside of the parenthesis. In the following example, the load order will be module1, module2, module3:
Ensuring modules will be loaded, preventing modules from loading, and specifying a module load order can all be combined in one MODULES line (only one will MODULES line will be recognized). As an example, the following line will load module1 and module3 in that order, and will prevent module2 from loading.
MODULES=(module1 !module2 module3)
Additional information:
Since module issues can involve storage devices such as hard drives, the following information is provided as a brief reference for those not familiar with how to view and interpret hard drive and partition information in Linux.
All hard drives in Linux will appear as either hdx devices (such as hda, hdb), or sdx devices (such as sda, sdb). The hdx devices are drives connected to an IDE controller. All other hard drives will be sdx devices. This includes SATA drives, SCSI drives, USB drives, and IEEE 1394 drives (FireWire).
Each partition on a hard drive will be designated by adding a number to the end of the hard drive designation. For example, hda1 is the first partition on hard drive hda, hda2 is the 2nd partition, and so on. The 4 possible primary partitions on a drive will always be numbered 1 through 4 (hda1, hda2, hda3, hda4), while logical volumes in an extended partition will always be numbered starting at 5 (hda5, hda6 ...), regardless of how many primary partitions are on the drive.
The following commands can be used to list drives and partitions in Linux:
List all partitions on all drives:
fdisk -l
List all partitions on just hda:
fdisk -l /dev/hda
The following is an example output of the command 'fdisk -l /dev/sdb':
Disk /dev/sdb: 203.9 GB, 203928109056 bytes
255 heads, 63 sectors/track, 24792 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
| Device Boot | Start | End | Blocks | Id | System |
| /dev/sdb1 | 16156 | 17174 | 8185117+ | 83 | Linux |
| /dev/sdb2 | 1306 | 2610 | 10482412+ | 83 | Linux |
| /dev/sdb3 | 2611 | 6690 | 32772600 | c | W95 FAT32 (LBA) |
| /dev/sdb4 | 6691 | 10770 | 32772600 | c | W95 FAT32 (LBA) |