Customise, build and install a custom kernel and kernel modules (201.4)

Candidates should be able to customise, build and install a 2.6 kernel for specific system requirements, by patching, compiling and editing configuration files as required. This objective includes being able to assess requirements for a kernel compile as well as build and configure kernel modules.

Key Knowledge Areas:

The following is a partial list of used files, terms, and utilities:

This paragraph consolidates the knowledge of the previous paragraphs in this chapter and expands on that slightly. The topics that have not yet been covered will be explained in this paragraph.

Using kernel modules

In the paragraph What are Kernel Modules you have learned what kernel modules are. There are various utilities and configuration files associated with these modules. This paragraph will explain how you can use these to manage a running kernel and it's modules.

Manipulating modules


For each kernel module loaded, display its name, size, use count and a list of other referring modules. This command yields the same information as is available in /proc/modules. On a particular laptop, for instance, the command /sbin/lsmod reports:

Module      Size   Used by
serial_cb   1120   1
tulip_cb    31968  2
cb_enabler  2512   4 [serial_cb tulip_cb]
ds          6384   2 [cb_enabler]
i82365      22384  2
pcmcia_core 50080  0 [cb_enabler ds i82365]

The format is name, size, use count, list of referring modules. If the module controls its own unloading via a can_unload routine, then the user count displayed by lsmod is always -1, irrespective of the real use count.


Insert a module into the running kernel. The module is located automatically and inserted. You must be logged in as superuser to insert modules. It is generally recommended to use modprobe instead, since insmod only returns very general error codes and modprobe is more specific about errors. Also, you would need to pass the complete filename to insmod , whereas modprobe will work with just the module name.

Frequently used options:


Write results to syslog instead of the terminal.


Set verbose mode.

Example 1.2. insmod

The kernel was compiled with modular support for a specific scsi card. To verify that this specific module, in this case sym53c8xx.ko exists, look for the file sym53c8xx.ko in the /lib/modules/ kernel-version/kernel/drivers/scsi/ directory:

# insmod sym53c8xx.ko
# echo $?

The kernel had all the prerequisite modules already loaded and this specific module loaded successfully. However, insmod doesn't load the prerequisites for you.

# insmod snd-ens1371.ko
insmod: error inserting 'snd-ens1371.ko': -1 Unknown symbol in module
# echo $?

This insmod snd-ens1371.ko command yields an unknown symbol and an exit status of 1. This is the same sort of message that might be seen when attempting to link a program that referenced variables or functions unavailable to the linker. In the context of a module insertion, such messages indicate that the functions are not available within the kernel. This is usually caused by not having the prerequisite module loaded or compiled into the kernel.


Unless a module is in use or referred to by another module, the module is removed from the running kernel. You must be logged in as the superuser to remove modules.

Example 1.3. rmmod

# rmmod snd_ac97_codec
ERROR: Module snd_ac97_codec is in use by snd_ens1371
# echo $?

The module can't be unloaded because it is in use, in this case by the snd_ens1371 module. The solution is to remove the snd_ens1371 module first:

# rmmod snd_ens1371
# rmmod snd_ac97_codec
# echo $?

Issue the command lsmod to verify that the modules have indeed been removed from the running kernel.


Like insmod, modprobe is used to insert modules. However, modprobe has the ability to load single modules, modules and their prerequisites, or all modules stored in a specific directory. The modprobe command can also remove modules when combined with the -r option. It also is more specific in it's error messages than insmod.

A module is inserted with optional symbol=value parameters such as irq=5 or dma=3 . This can be done on the command line or by specifying options in the module configuration file as will be explained later on. If the module is dependent upon other modules, they will be loaded first. The modprobe command determines prerequisite relationships between modules by reading modules.dep at the top of the module directory hierarchy, for instance /lib/modules/2.6.31/modules.dep. You must be logged in as the superuser to insert modules.

Frequently used options


Load all modules. When used with the -t tag, all is restricted to modules in the tag directory. This action probes hardware by successive module-insertion attempts for a single type of hardware, such as a network adapter. This may be necessary, for example, to probe for more than one kind of network interface.


Display a complete module configuration, including defaults and directives found in /etc/modules.conf (or /etc/conf.modules, depending on your version of module utilities.) The -c option is not used with any other options.


List modules. When used with the -t tag, list only modules in directory tag.


Remove module, similar to rmmod. Multiple modules may be specified.


Display results in syslog instead of on the terminal.

-t tag

Attempt to load multiple modules found in the directory tag until a module succeeds or all modules in tag are exhausted. This action probes hardware by successive module-insertion attempts for a single type of hardware, such as a network adapter.


Set verbose mode.

Example 1.4. modprobe

Loading sound modules using modprobe.

# modprobe snd_ens1371
# echo $?
# lsmod
Module                  Size  Used by
snd_ens1371            20704  0
snd_rawmidi            22448  1 snd_ens1371
snd_seq_device          7436  1 snd_rawmidi
snd_ac97_codec        112280  1 snd_ens1371
ac97_bus                1992  1 snd_ac97_codec
snd_pcm                72016  2 snd_ens1371,snd_ac97_codec
snd_timer              21256  1 snd_pcm
snd                    62392  6 snd_ens1371,snd_rawmidi,snd_seq_device,snd_ac97_codec,snd_pcm,snd_timer
soundcore               7952  1 snd
snd_page_alloc          9528  1 snd_pcm

All prerequisite modules for snd_ens1371 have been loaded. To remove both snd_ac97_codec and snd_ens1371 modules, use modprobe -r snd_ac97_codec.


Display information about a module from its module-object-file. Some modules contain no information at all, some have a short one-line description, others have a fairly descriptive message.

Options from the man-page:

-a, --author

Display the module's author.

-d, --description

Display the module's description.

-n, --filename

Display the module's filename.

-fformat_string, --format format_string

Let's the user specify an arbitrary format string which can extract values from the ELF section in module_file which contains the module information. Replacements consist of a percent sign followed by a tag name in curly braces. A tag name of %{filename} is always supported, even if the module has no modinfo section.

-p, --parameters

Display the typed parameters that a module may support.

-h, --help

Display a small usage screen.

-V, --version

Display the version of modinfo.

Example 1.5. modinfo

What information can be retrieved from the snd-ens1371 module:

# modinfo snd_ens1371
filename:       /lib/modules/2.6.31/kernel/sound/pci/snd-ens1371.ko
description:    Ensoniq/Creative AudioPCI ES1371+
license:        GPL
author:         Jaroslav Kysela <>, Thomas Sailer <>
alias:          pci:v00001102d00008938sv*sd*bc*sc*i*
alias:          pci:v00001274d00005880sv*sd*bc*sc*i*
alias:          pci:v00001274d00001371sv*sd*bc*sc*i*
depends:        snd-pcm,snd,snd-rawmidi,snd-ac97-codec
vermagic:       2.6.31-gentoo-r10 SMP mod_unload modversions
parm:           index:Index value for Ensoniq AudioPCI soundcard. (array of int)
parm:           id:ID string for Ensoniq AudioPCI soundcard. (array of charp)
parm:           enable:Enable Ensoniq AudioPCI soundcard. (array of bool)
parm:           spdif:S/PDIF output (-1 = none, 0 = auto, 1 = force). (array of int)
parm:           lineio:Line In to Rear Out (0 = auto, 1 = force). (array of int)

Configuring modules

You may sometimes need to control assignments of the resources a module uses, such as hardware interrupts or Direct Memory Access (DMA) channels. Other situations may dictate special procedures to prepare for, or to clean up after, module insertion or removal. This type of special control of modules is configured in the file /etc/modules.conf.

Commonly used directives in/etc/modules.conf:


The keep directive, when found before any path directives, causes the default paths to be retained and added to any paths specified.


This directive overrides the default location for the modules dependency file, modules.dep which will be described in the next section.


This directive specifies an additional directory to search for modules.

options modulename module-specific-options

Options for modules can be specified using the options configuration line in modules.conf or on the modprobe command line. The command line overrides configurations in the file. modulename is the name of a single module file without the .ko extension. Module-specific options are specified as name=value pairs, where the name is understood by the module and is reported using modinfo -p.

alias aliasname result

Aliases can be used to associate a generic name with a specific module, for example:

alias /dev/ppp ppp_generic
alias char-major-108 ppp_generic
alias tty-ldisc-3 ppp_async
alias tty-ldisc-14 ppp_synctty
alias ppp-compress-21 bsd_comp
alias ppp-compress-24 ppp_deflate
alias ppp-compress-26 ppp_deflate
pre-install module command

This directive causes a specified shell command to be executed prior to the insertion of a module. For example, PCMCIA services need to be started prior to installing the pcmcia_core module:

pre-install pcmcia_core /etc/init.d/pcmcia start

install module command

This directive allows a specific shell command to override the default module-insertion command.

post-install module command

This directive causes a specified shell command to be executed after insertion of the module.

pre-remove module command

This directive causes a specified shell command to be executed prior to removal of module.

remove module command

This directive allows a specific shell command to override the default module-removal command.

post-remove module command

This directive causes a specified shell command to be executed after removal of module.

For more detailed information concerning the module-configuration file see man modules.conf.

Blank lines and lines beginning with a # are ignored in modules.conf.

Module Dependency File

The command modprobe can determine module dependencies and install prerequisite modules automatically. To do this, modprobe scans the first column of /lib/modules/kernel-version/modules.dep to find the module it is to install. Lines in modules.dep are in the following form:

module_name.(k)o: dependency1 dependency2 ...

Below is an example for thermal and processor modules (which are part of the ACPI layer):

/lib/modules/2.6.31/kernel/drivers/acpi/thermal.ko: \
/lib/modules/2.6.31/kernel/drivers/acpi/processor.ko: \

Here both the processor and thermal module depend on the thermal_sys module.

All of the modules available on the system are listed in the modules.dep file and are referred to with their full path and filenames, including their .(k)o extension. Those that are not dependent on other modules are listed, but without dependencies. Dependencies that are listed are inserted into the kernel by modprobe first, and after they have been successfully inserted, the subject module itself can be loaded.

The modules.dep file must be kept current to ensure the correct operation of modprobe. If module dependencies were to change without a corresponding modification to modules.dep, then modprobe would fail because a dependency would be missed. As a result, modules.dep needs to be (re)created each time the system is booted. Most distributions will do this by executing depmod -a automatically when the system is booted.

This procedure is also necessary after any change in module dependencies.

/proc/sys/kernel/ is a directory in the /proc pseudo filesystem which contains the following entries:

$ ls -l /proc/sys/kernel/ 
-rw------- 1 root root 0 Oct 22 14:11 cad_pid 
-rw------- 1 root root 0 Oct 22 14:11 cap-bound
-rw-r--r-- 1 root root 0 Oct 22 14:11 core_uses_pid 
-rw-r--r-- 1 root root 0 Oct 22 14:11 ctrl-alt-del 
-rw-r--r-- 1 root root 0 Oct 22 14:11 domainname 
-rw-r--r-- 1 root root 0 Oct 22 14:11 hostname 
-rw-r--r-- 1 root root 0 Oct 22 14:11 hotplug 
-rw-r--r-- 1 root root 0 Oct 22 14:11 modprobe 
-rw-r--r-- 1 root root 0 Oct 22 14:11 msgmax 
-rw-r--r-- 1 root root 0 Oct 22 14:11 msgmnb 
-rw-r--r-- 1 root root 0 Oct 22 14:11 msgmni    
-r--r--r-- 1 root root 0 Oct 22 14:11 osrelease 
-r--r--r-- 1 root root 0 Oct 22 14:11 ostype 
-rw-r--r-- 1 root root 0 Oct 22 14:11 overflowgid    
-rw-r--r-- 1 root root 0 Oct 22 14:11 overflowuid 
-rw-r--r-- 1 root root 0 Oct 22 14:11 panic 
-rw-r--r-- 1 root root 0 Oct 22 14:11 printk 
dr-xr-xr-x 2 root root 0 Oct 22 14:11 random 
-rw-r--r-- 1 root root 0 Oct 22 14:11 rtsig-max 
-r--r--r-- 1 root root 0 Oct 22 14:11 rtsig-nr 
-rw-r--r-- 1 root root 0 Oct 22 14:11 sem 
-rw-r--r-- 1 root root 0 Oct 22 14:11 shmall
-rw-r--r-- 1 root root 0 Oct 22 14:11 shmmax 
-rw-r--r-- 1 root root 0 Oct 22 14:11 shmmni 
-rw-r--r-- 1 root root 0 Oct 22 14:11 tainted 
-rw-r--r-- 1 root root 0 Oct 22 14:11 threads-max 
-r--r--r-- 1 root root 0 Oct 22 14:11 version 

Some files can be used to get information, for instance to show the version of the running kernel:

 cat /proc/sys/kernel/osrelease 

Some files can also be used to set information in the kernel. For instance, the following will tell the kernel not to loop on a panic, but to auto-reboot after 20 seconds:

 echo 20 > /proc/sys/kernel/panic 

kmod versus kerneld

What are they?

Both kmod and kerneld make dynamic loading of kernel-modules possible. A module is loaded when the kernel needs it. (What modules are has been explained earlier on in this chapter).

What is the difference between them?

kerneld is a daemon, kmod is a thread in the kernel itself.

The communication with kerneld is done through System V IPC. kmod operates directly from the kernel and does not use System V IPC thereby making it an optional module.

kmod replaces kerneld as of Linux kernel 2.2.x.

What do they have in common?

Both facilitate dynamic loading of kernel modules.

Both use modprobe to manage dependencies and dynamic loading of modules.

Manual loading of modules with modprobe or insmod is possible without the need for kmod or kerneld.

In both cases, the kernel-option CONFIG_MODULES must be set to enable the usage of modules.

Enabling kmod

To enable the use of kmod, a kernel must be compiled with the kernel-option CONFIG_KMOD enabled. This can only be done if the kernel-option CONFIG_MODULES has also been enabled.

Building A Custom Kernel

A kernel can be configured to meet custom needs using one of the make targets for configuration (make config, xconfig, menuconfig, gconfig, oldconfig), see creating a .config file. Once the kernel is configured it can be built with the command make zImage/bzImage. To compile the kernel image and loadable modules you can use the command make all. After configuring and compiling the kernel it can be installed with make install . Installing the kernel means installing the following files into the /boot directory:

  • config-2.6.x
  • vmlinuz-2.6.x

The depmod command builds a modules.dep file which is needed by modprobe to determine the dependencies of the (newly) built modules.

Besides building and installing a kernel on a local machine, the newly built kernel can be distributed to other machines using several packages. This can be done with the commands:

  • make rpm-pkg: builds both source and binary RPM packages.
  • make binrpm-pkg: builds (only) binary kernel RPM package.
  • make deb-pkg: builds the kernel package as a deb(ian) package.
Copyright Snow B.V. The Netherlands