Knowledge Base Glossary       Exit
(how to) Search  

Browse by Category
Knowledge Base > Archive > Products > IFD/IFL/IFW - Version 1 > Working with kernel modules on the IFL Network Boot Disk

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 tainted
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
In 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.

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:

MODULES=(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
 BlocksId
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)

 

How helpful was this article to you?


powered by Lore