Home arrow Site Administration arrow Page 10 - Kernel, Cron, and User Administration, Part 1

Understanding Kernel Modules - Administration

Today, get started with your RHCE certification. Learn about shell configuration files, setting up and managing disk quotas, and the basics of the kernel. This comes from chapter five of Red Hat Certified Engineer Linux Study Guide (Exam RH302), fourth edition, by Michael Jang. (McGraw-Hill/Osborne, 2004, ISBN: 0-07-225365-7).

  1. Kernel, Cron, and User Administration, Part 1
  2. Certification Objective: Shell Configuration Files
  3. Setting Up and Managing Disk Quotas
  4. The Quota Package
  5. Quota Management Commands
  6. Automating Quota Settings
  7. The Basics of the Kernel
  8. Kernel Concepts
  9. Other RHEL 3 Kernels
  10. Understanding Kernel Modules
  11. /lib/modules/kernel_version/ Directory Structure
By: McGraw-Hill/Osborne
Rating: starstarstarstarstar / 11
August 25, 2004

print this article



When you compile your kernel, you can set up a monolithic kernel with every driver that you might ever need. Unfortunately, such kernels are large, unwieldy, and take a lot of time to load. Generally, most Linux administrators use kernel modules. As described earlier, a kernel module is not compiled directly into the kernel but instead operates as a pluggable driver that can be loaded and unloaded into the kernel as needed.

EXAM WATCH!  If you’re having problems with hardware related kernel modules, one utility you can try is kudzu, the Red Hat hardware detection and configuration utility. It is normally run during the boot process, but you might try running it again if you’re having a problem.

To have the kernel dynamically load and unload kernel modules as needed, the kernel module loader, kmod, is used to control the loading and unloading of modules. For special parameters and options, edit the /etc/modules.conf file.

Most hardware modules are automatically detected. If you’ve just installed new undetected hardware, you could issue the following command:

# depmod -a

This will scan through your modules, find out what the different dependencies for all your modules are, and map them out to a file (modules.dep). This command also creates a number of other files in the /lib/modules/2.4.21-4.EL/ directory (if you’ve installed another kernel, the directory version changes accordingly).

RHEL 3 runs this command automatically through the /etc/rc.sysinit script. Once the depmod module scan is complete, you can load additional kernel modules. If that module has dependencies, then all the needed modules will automatically load first.

To load a module, you can use the modprobe command with the name of a specific driver:

# modprobe 3c503

In this example, the Ethernet module for a 3Com 503 network card requires the 8390 module to work properly. If depmod was run first, then 8390 would have loaded automatically before the 3c503 driver. If a dependency in the list fails during loading, then all modules will be automatically unloaded.

Alternatively, you can set up these modules in /etc/modules.conf. It should already be configured during the RHEL 3 installation process. Unfortunately, this work can be rather tedious. The following commands are accepted in this file:

  • alias  Allows you to bind a name to a module.
  • options  Allows you to specify options for a module.
  • install module command  Use commandinstead of insmod on this module.
  • pre-install module command  Run commandbefore installing this module.
  • post-install module command  Run commandafter installing this module.
  • remove module command  Use commandinstead of rmmod on this module.
  • pre-remove module command  Run commandbefore loading this module.
  • post-remove module command  Run commandafter loading this module.

Here is an example of what a common modules.conf file may look like:

alias eth0 pcnet32
alias usb-controller usb-uhci
options sb irq=5 io=0x220 dma=1
alias midi awe_wave
alias parport_lowlevel parport_pc

Here the eth0 device is bound to the pcnet32 module. To load the network card, you can then simply type modprobe eth0 without knowing what card is in the computer. The next command sets the USB controller. The following two lines show the configuration of a soundblaster (sb) module. This information includes a specific IRQ port, I/O address, and DMA channel. The options line specifies these options and binds them to the sb alias. The sound card happens to be a Sound Blaster AWE 32 model card; therefore, the midi alias is bound to the awe_wave module. Finally, a parallel port module is bound to the parport_lowlevel alias.

The /etc/rc.sysinit script recognizes certain aliases and will load them if it finds them in this file. You need to specifically place the sound modules in modules.conf to have them automatically loaded. To have the sound modules automatically loaded during the Linux boot process without having to edit the /etc/rc.sysinit file, you can simply create an alias to sound and or midi in the modules.conf file.

To see what modules are loaded, you can type either

# cat /proc/modules


# lsmod

Both commands return output that looks something like the following:

Module        Size  Used by     Not tainted
nfs           92912  1 (autoclean)
ide-cd        35680  0 (autoclean)
cdrom         33696  0 (autoclean) [ide-cd]
smbfs         44528  1 (autoclean)
nfsd          85456  8 (autoclean)
lockd         59856  1 (autoclean) [nfs nfsd]
sunrpc        85692  1 (autoclean) [nfs nfsd lockd]
parport_pc    19076  1 (autoclean)
lp             9028  0 (autoclean)
parport       37088  1 (autoclean) [parport_pc lp]
autofs        13364  0 (autoclean) (unused)
pcnet32       18080  1
mii            3976  0 [pcnet32]
crc32          3712  0 [pcnet32]
ipt_REJECT     4632  1 (autoclean)
ipt_state      1080  1 (autoclean)
ip_conntrack  27304  1 (autoclean) [ipt_state]
iptable_filter 2412  1 (autoclean)
ip_tables     15776  3 [ipt_REJECT ipt_state iptable_filter]
58160  0 (autoclean)
microcode      4724  0 (autoclean)
keybdev        2976  0 (unused)
mousedev       5524  1
hid           22212  0 (unused)
input          5888  0 [keybdev mousedev hid]
usb-uhci      26412  0 (unused)
usbcore       79392  1 [hid usb-uhci]
ext3          91592  3
jbd           52336  3 [ext3]
raid1         14988  2

The module name is listed on the left, and its size is in the second column. The “Used by” column shows more detail on how the module is being handled. An autoclean message means that the kernel, using the kmod thread is taking care of the module and will handle removing it. If a module name, such as ext3, is listed in brackets, then the module depends on the module in brackets. In our example, jbd depends on the ext3 module.

This is part one from the fifth chapter of Red Hat Certified Engineer Linux Study Guide (Exam RH302), fourth edition, by Michael Jang. (McGraw-Hill/Osborne, 2004, ISBN: 0-07-225365-7). Check it out at your favorite bookstore today. Buy this book now.

>>> More Site Administration Articles          >>> More By McGraw-Hill/Osborne

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort


- Coding: Not Just for Developers
- To Support or Not Support IE?
- Administration: Networking OSX and Win 7
- DotNetNuke Gets Social
- Integrating MailChimp with Joomla: Creating ...
- Integrating MailChimp with Joomla: List Mana...
- Integrating MailChimp with Joomla: Building ...
- Integrating MailChimp with Joomla
- More Top WordPress Plugins for Social Media
- Optimizing Security: SSH Public Key Authenti...
- Patches and Rejects in Software Configuratio...
- Configuring a CVS Server
- Managing Code and Teams for Cross-Platform S...
- Software Configuration Management
- Back Up a Joomla Site with Akeeba Backup

Developer Shed Affiliates


Dev Shed Tutorial Topics: