Skip to main content

By clicking Submit, you agree to the developerWorks terms of use.

The first time you sign into developerWorks, a profile is created for you. Select information in your profile (name, country/region, and company) is displayed to the public and will accompany any content you post. You may update your IBM account at any time.

All information submitted is secure.

  • Close [x]

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerworks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

By clicking Submit, you agree to the developerWorks terms of use.

All information submitted is secure.

  • Close [x]

developerWorks Community:

  • Close [x]

LPI exam 102 prep: Kernel

Junior Level Administration (LPIC-1) topic 105

Ian Shields, Senior Programmer, IBM
Ian Shields
Ian Shields works on a multitude of Linux projects for the developerWorks Linux zone. He is a Senior Programmer at IBM at the Research Triangle Park, NC. He joined IBM in Canberra, Australia, as a Systems Engineer in 1973, and has since worked on communications systems and pervasive computing in Montreal, Canada, and RTP, NC. He has several patents. His undergraduate degree is in pure mathematics and philosophy from the Australian National University. He has an M.S. and Ph.D. in computer science from North Carolina State University. You can contact Ian at
(An IBM developerWorks Contributing Author)

Summary:  In this tutorial, Ian Shields begins preparing you to take the Linux Professional Institute® Junior Level Administration (LPIC-1) Exam 102. In this first in a series of nine tutorials, Ian introduces you to the kernel on Linux®. By the end of this tutorial, you will know how to build, install, and query a Linux kernel and its kernel modules.

View more content in this series

Date:  21 Mar 2006
Level:  Intermediate PDF:  A4 and Letter (416 KB | 22 pages)Get Adobe® Reader®


Runtime kernel management

This section covers material for topic 1.105.1 for the Junior Level Administration (LPIC-1) exam 102. The topic has a weight of 4.

In this section, learn how to:

  • Use command-line utilities to get information about the currently running kernel and kernel modules
  • Manually load and unload kernel modules
  • Determine when modules can be unloaded
  • Configure the system to load modules by names other than their file name

Technically, Linux is the kernel of your system. The kernel provides a framework for applications to run and use various hardware devices. It is low-level code that deals with hardware interfaces, scheduling, and memory management among other things. Many people refer to a whole system as GNU/Linux because many of the tools that make most distributions usable come from the GNU project of the Free Software Foundation. Nevertheless, you will often just see "Linux" instead of "GNU/Linux."


The uname command prints information about your system and its kernel. Listing 1 shows the various options for uname and the resulting information; each option is defined in Table 3.

Listing 1. The uname command
ian@pinguino:~$ uname
ian@pinguino:~$ uname -s
ian@pinguino:~$ uname -n
ian@pinguino:~$ uname -r
ian@pinguino:~$ uname -v
#1 Mon Jan 16 17:18:08 UTC 2006
ian@pinguino:~$ uname -m
ian@pinguino:~$ uname -o
ian@pinguino:~$ uname -a
Linux pinguino 2.6.12-10-386 #1 Mon Jan 16 17:18:08 UTC 2006 i686 GNU/Linux

Table 3. Options for uname
-sPrint the kernel name. This is the default if no option is specified.
-nPrint the nodename or hostname.
-rPrint the release of the kernel. This option is often used with module-handling commands.
-vPrint the version of the kernel.
-mPrint the machine's hardware (CPU) name.
-oPrint the operating system name.
-aPrint all of the above information.

Listing 1 is from an Ubuntu system running on an Intel® CPU. The uname command is available on most UNIX® and UNIX-like systems as well as Linux. The information printed will vary by Linux distribution and version as well as by the type of machine you are running on. Listing 2 shows the output from an AMD Athlon 64 system running Fedora Core 4 and, for comparison, an Apple PowerBook.

Listing 2. Using uname with another system
Linux attic4 2.6.14-1.1656_FC4 #1 Thu Jan 5 22:13:55 EST 2006 x86_64 
x86_64 x86_64 GNU/Linuxfilesystem

Darwin Ian-Shields-Computer.local 7.9.0 Darwin Kernel Version 7.9.0: 
Wed Mar 30 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC  
Power Macintosh powerpc

Kernel modules

The kernel manages many of the low-level aspects of your system, including hardware and interfaces. With a large variety of possible hardware and several different file systems, a kernel that supported everything would be rather large. Fortunately, kernel modules allow you to load support software such as hardware drivers or file systems when needed, so you can start your system with a small kernel and then load other modules as needed. Often the loading is automatic, such as when USB devices are plugged in.

The remainder of this section looks at the commands and configuration for kernel modules.

The commands for tasks such as loading or unloading modules require root authority. The commands for displaying information about modules can usually be run by general users. However, since they reside in /sbin, they are not usually on a non-root user's path, so you will probably have to use full path names if you are not root.


Use the lsmod command to display the modules that are currently loaded on your system, as shown in Listing 3. Your output is likely to be different, although you should see some common entries.

Listing 3. Displaying kernel modules with lsmod
[ian@attic4 ~]$ /sbin/lsmod
Module                  Size  Used by
nvnet                  74148  0
nvidia               4092336  12
forcedeth              24129  0
md5                     4161  1
ipv6                  268737  12
parport_pc             29189  1
lp                     13129  0
parport                40969  2 parport_pc,lp
autofs4                29637  1
sunrpc                168453  1
ipt_REJECT              5825  1
ipt_state               1985  3
ip_conntrack           42009  1 ipt_state
iptable_filter          3137  1
ip_tables              19521  3 ipt_REJECT,ipt_state,iptable_filter
dm_mod                 58613  0
video                  16069  0
button                  4161  0
battery                 9541  0
ac                      4933  0
ohci_hcd               26977  0
ehci_hcd               41165  0
i2c_nforce2             7105  0
i2c_core               21825  1 i2c_nforce2
shpchp                 94661  0
snd_intel8x0           34945  1
snd_ac97_codec         76217  1 snd_intel8x0
snd_seq_dummy           3781  0
snd_seq_oss            37569  0
snd_seq_midi_event      9409  1 snd_seq_oss
snd_seq                62801  5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event
snd_seq_device          9037  3 snd_seq_dummy,snd_seq_oss,snd_seq
snd_pcm_oss            51569  0
snd_mixer_oss          18113  1 snd_pcm_oss
snd_pcm               100553  3 snd_intel8x0,snd_ac97_codec,snd_pcm_oss
snd_timer              33733  2 snd_seq,snd_pcm
snd                    57669  11 snd_intel8x0,snd_ac97_codec,snd_seq_oss,snd_seq,
soundcore              11169  1 snd
snd_page_alloc          9925  2 snd_intel8x0,snd_pcm
floppy                 65397  0
ext3                  132681  3
jbd                    86233  1 ext3
sata_nv                 9541  0
libata                 47301  1 sata_nv
sd_mod                 20545  0
scsi_mod              147977  2 libata,sd_mod
[ian@attic4 ~]$

You can see that this system has many loaded modules. Most of these are supplied with the kernel. However, some, such as the nvnet, nvidia, and sata_nv modules from NVIDIA Corporation include proprietary code and are not supplied as part of a standard kernel. In this way, the modular approach allows proprietary code to be plugged in to an open source kernel. Assuming the vendor license permits it, a Linux distributor may add proprietary modules to a distribution, saving you the effort of getting them directly from a vendor and helping to ensure that you have the appropriate levels.

From Listing 3, you can also see that modular support extends to devices such as video, SATA and SCSI hard drives, floppy disks, and sound cards, as well as to networking features such as IPV6, file system support such as ext3, and Sun remote procedure call (RPC).

In addition to the module name, lsmod also shows the module size and the number of users of the module. If the module is used by any other modules, these are listed. So, for example, the soundcore module is used by the snd module, which in turn is used by several other sound modules.


The modinfo command displays information about one or more modules. As shown in Listing 4, the information includes the full path to the file, the author, license, any parameters that the module might accept, version, dependencies, and other information.

Listing 4. Basic module information
[ian@attic4 ~]$ /sbin/modinfo floppy
filename:       /lib/modules/2.6.12-1.1456_FC4/kernel/drivers/block/floppy.ko
author:         Alain L. Knaff
license:        GPL
alias:          block-major-2-*
vermagic:       2.6.12-1.1456_FC4 686 REGPARM 4KSTACKS gcc-4.0
srcversion:     2633BC999A0747D8D215F1F
parm:           FLOPPY_DMA:int
parm:           FLOPPY_IRQ:int
parm:           floppy:charp
[ian@attic4 ~]$ /sbin/modinfo sata_nv
filename:       /lib/modules/2.6.12-1.1456_FC4/kernel/drivers/scsi/sata_nv.ko
author:         NVIDIA
description:    low-level driver for NVIDIA nForce SATA controller
license:        GPL
version:        0.6
vermagic:       2.6.12-1.1456_FC4 686 REGPARM 4KSTACKS gcc-4.0
depends:        libata
alias:          pci:v000010DEd0000008Esv*sd*bc*sc*i*
alias:          pci:v000010DEd000000E3sv*sd*bc*sc*i*
alias:          pci:v000010DEd000000EEsv*sd*bc*sc*i*
alias:          pci:v000010DEd00000054sv*sd*bc*sc*i*
alias:          pci:v000010DEd00000055sv*sd*bc*sc*i*
alias:          pci:v000010DEd00000036sv*sd*bc*sc*i*
alias:          pci:v000010DEd0000003Esv*sd*bc*sc*i*
alias:          pci:v000010DEd*sv*sd*bc01sc01i*
srcversion:     3094AD48C1B869BCC301E9F

In Listing 4, notice in the lines giving the module filenames that these filenames end in a .ko suffix. This distinguishes modules for 2.6 kernels from other object files and from modules for 2.4 and earlier kernels, which used the same .o suffix as other object files.

You will also notice that the module path include the kernel version. For example, /lib/modules/2.6.12-1.1456_FC4/kernel/drivers/block/floppy.ko includes 2.6.12-1.1456_FC4 as a path element. This is the same value emitted by uname -r. Kernel modules are specific to a given kernel, and this structure manages that relationship.

On 2.6 kernels you can also use modinfo to limit requests to specific information about a module. Use the -F option to extract a single information type, such as parm, description, license, filename, or alias. Use the command multiple times with different options if you need different types of information. On 2.4 kernels, parameters such as -p extracted parameter information. The current modinfo command also supports the older parameters. Listing 5 shows some examples.

Listing 5. Specific module information
[ian@attic4 ~]$ /sbin/modinfo -F parm snd
cards_limit:Count of auto-loadable soundcards.
major:Major # for sound driver.
[ian@attic4 ~]$ /sbin/modinfo -F license nvidia floppy
[ian@attic4 ~]$ /sbin/modinfo -p snd
major:Major # for sound driver.
cards_limit:Count of auto-loadable soundcards.

Using your Linux skills

You may use some of the techniques covered in the tutorial "LPI exam 101 prep (topic 103): GNU and UNIX commands" to extract information such as the number of parameters accepted by any module that accepts parameters. Listing 6 shows an example.

Listing 6. Number of parameters per module
[ian@attic4 ~]$ for n in `/sbin/lsmod | tail +2 | cut -d " " -f1`;
> do echo "$n $(/sbin/modinfo -p $n |wc -l )" | grep -v " 0$"; done
nvnet 12
forcedeth 1
parport_pc 5
dm_mod 1
ohci_hcd 2
ehci_hcd 2
shpchp 3
snd_intel8x0 7
snd_ac97_codec 1
snd_seq_dummy 2
snd_seq_oss 2
snd_seq 7
snd_pcm_oss 3
snd_pcm 2
snd_timer 1
snd 2
snd_page_alloc 1
scsi_mod 6


If a module's use count is 0, you may safely remove it. For example, you might do this in preparation for loading an updated version. This is a great feature of a modular kernel because you do not always have to reboot just to update support for one or another particular device. To remove a mod, use the rmmod command along with the module name as shown in Listing 7.

Listing 7. Removing a module for a running system
[root@attic4 ~]# rmmod floppy

Consult the man pages for other options available with rmmod.

insmod and modprobe

Once you have removed a module, you may need to reload it. You can do this using the insmod command, which takes the full path name of the module to be reloaded, along with any module options that may be required. If you use this command, you will probably want to use command substitution for generating the filename. Two ways of doing this are shown in Listing 8.

Listing 8. Loading a module using insmod
[root@attic4 ~]# insmod /lib/modules/
            `uname -r`/kernel/drivers/block/floppy.ko
            [root@attic4 ~]# rmmod floppy
            [root@attic4 ~]# insmod $(modinfo -F filename floppy)

The second form above saves you the need to remember which subdirectory (drivers/block in this case) a module is located in, but there is an even better way to load a module. The modprobe command provides a higher-level interface that operates with the module name instead of file path. It also handles loading additional modules upon which a module depends, and can remove modules as well as load them.

Listing 9 shows how to use modprobe to remove the vfat module, along with the fat module that uses it. It then shows what the system would do if the module were reloaded, and finally the result of reloading the module. Note that the -v option is specified to obtain verbose output; otherwise, modprobe (and the underlying insmod command) will display only error messages from the module itself. Between each step, the output of lsmod is piped through grep to show whether either the vfat or fat module is loaded or not.

Listing 9. Loading a module using modprobe
[root@lyrebird root]# modprobe -r vfat
vfat: Device or resource busy
[root@lyrebird root]# lsmod | grep fat
vfat                   13132   1
fat                    38744   0  [vfat]
[root@lyrebird root]# umount /windows/D
[root@lyrebird root]# modprobe -r vfat
[root@lyrebird root]# modprobe -v --show  vfat
/sbin/insmod /lib/modules/2.4.21-37.0.1.EL/kernel/fs/fat/fat.o
/sbin/insmod /lib/modules/2.4.21-37.0.1.EL/kernel/fs/vfat/vfat.o
[root@lyrebird root]# lsmod | grep fat
[root@lyrebird root]# modprobe -v  vfat
/sbin/insmod /lib/modules/2.4.21-37.0.1.EL/kernel/fs/fat/fat.o
Using /lib/modules/2.4.21-37.0.1.EL/kernel/fs/fat/fat.o
Symbol version prefix ''
/sbin/insmod /lib/modules/2.4.21-37.0.1.EL/kernel/fs/vfat/vfat.o
Using /lib/modules/2.4.21-37.0.1.EL/kernel/fs/vfat/vfat.o
[root@lyrebird root]# lsmod | grep fat
vfat                   13132   0  (unused)
fat                    38744   0  [vfat]


You have just seen that modprobe can handle the automatic loading of multiple modules when some are dependent on others. The dependencies are kept in the modules.dep file in the /lib/modules subdirectory for the appropriate kernel, as given by the uname -r command. This file, along with several map files, is generated by the depmod command. The -a (for all) is now optional.

The depmod command scans the modules in the subdirectories of /lib/modules for the kernel you are working on and freshens the dependency information. An example, along with the resulting changed files, is shown in Listing 10.

Listing 10. Using depmod to rebuild modules.dep
[root@lyrebird root]# date
Thu Mar 16 10:41:05 EST 2006
[root@lyrebird root]# depmod
[root@lyrebird root]# cd /lib/modules/`uname -r`
[root@lyrebird 2.4.21-37.0.1.EL]# ls -l mod*
-rw-rw-r--    1 root     root        54194 Mar 16 10:41 modules.dep
-rw-rw-r--    1 root     root           31 Mar 16 10:41 modules.generic_string
-rw-rw-r--    1 root     root           73 Mar 16 10:41 modules.ieee1394map
-rw-rw-r--    1 root     root         1614 Mar 16 10:41 modules.isapnpmap
-rw-rw-r--    1 root     root           29 Mar 16 10:41 modules.parportmap
-rw-rw-r--    1 root     root        65171 Mar 16 10:41 modules.pcimap
-rw-rw-r--    1 root     root           24 Mar 16 10:41 modules.pnpbiosmap
-rw-rw-r--    1 root     root       122953 Mar 16 10:41 modules.usbmap
[root@lyrebird 2.4.21-37.0.1.EL]# cd -

You can customize the behavior of modprobe and depmod using the configuration file /etc/modules.conf. This is commonly used to alias module names and to specify commands that should be run after a module is loaded or before it is unloaded. However, an extensive range of other configuration can be done. Listing 11 shows an example of /etc/modules.conf. Consult the man page for modules.conf for more details.

Listing 11. Example /etc/modules file
[root@lyrebird root]# cat /etc/modules.conf
alias eth0 e100
alias usb-controller usb-uhci
alias usb-controller1 ehci-hcd
alias sound-slot-0 i810_audio
post-install sound-slot-0 /bin/aumix-minimal -f /etc/.aumixrc -L >/dev/null 2>&1 || :
pre-remove sound-slot-0 /bin/aumix-minimal -f /etc/.aumixrc -S >/dev/null 2>&1 || :

You should also be aware that some systems use another configuration file called modprobe.conf, while others store module configuration information in the /etc/modules.d directory. You may also find a file called /etc/modules on some systems; this file contains the names of kernel modules that should be loaded at boot time.

USB modules

When you hot plug a USB device into your Linux system, the kernel must determine which modules to load to handle the device. This is usually done for you by a hot plug script that uses the usbmodules command to find the appropriate module. You can also run usbmodules (as root) to see for yourself. Listing 12 shows an example.

Listing 12. USB modules
root@pinguino:~# lsusb
Bus 005 Device 004: ID 1058:0401 Western Digital Technologies, Inc.
Bus 005 Device 003: ID 054c:0220 Sony Corp.
Bus 005 Device 001: ID 0000:0000
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 001: ID 0000:0000
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 003: ID 04b3:310b IBM Corp. Red Wheel Mouse
Bus 001 Device 001: ID 0000:0000
root@pinguino:~# usbmodules --device /proc/bus/usb/005/003
root@pinguino:~# usbmodules --device /proc/bus/usb/001/003

The next section shows you how to build and configure a custom kernel.

2 of 5 | Previous | Next


Zone=Linux, Open source
TutorialTitle=LPI exam 102 prep: Kernel