Copyright © 2000 by Linux Documentation Project
This document explains how to install and use the automatic kernel module loader "kerneld". The latest released version of this document can be found at the Linux Documentation Project
This document is based on an original HTML version 1.7 dated July 19, 1997 by Henrik Storner <email@example.com> and was revised and translated to DocBook DTD by Gary Lawrence Murphy <firstname.lastname@example.org> May 20, 2000.
The following people have contributed to this mini-HOWTO at some point:
If you find errors in this document, please send email to <email@example.com>. Your comments, encouragement and suggestions are welcome and appreciated, and help ensure this guide remains current and accurate.
The kerneld feature was introduced during the 1.3 development kernels by Bjorn Ekwall. It allows kernel modules such as device drivers, network drivers and filesystems to be loaded automatically when they are needed, rather than having to do it manually with modprobe or insmod.
And for the more amusing aspects, although these are not (yet ?) integrated with the standard kernel:
kerneld consists of two components:
Both components must be working for the kerneld support to function; it is not enough that only one or the other has been setup.
There are some good reasons for using kerneld. The ones I will mention are mine, others have other reasons.
Of course, there are also reasons why you may not want to use it. If you prefer to have just one kernel image file with all of your drivers built in, you are reading the wrong document.
The support in the Linux kernel was introduced with Linux 1.3.57. If you have an earlier kernel version, you will need to upgrade if you want the kerneld support. The current Linux kernel sources can be found at most Linux FTP archive sites including:
The user-space daemon is included with the modules package. These are normally available from the same place as the kernel sources
First get the necessary parts: A suitable kernel and the latest modules package. Then you should install the module utilities as per the instructions included in the package. Pretty simple: Just unpack the sources and run make install. This compiles and installs the following programs in /sbin: genksysm, insmod, lsmod, modprobe, depmod and kerneld. I recommend you add some lines to your startup-scripts to do some necessary setup whenever you boot Linux. Add the following lines to your /etc/rc.d/rc.S file (if you are running Slackware), or to /etc/rc.d/rc.sysinit if you are running SysVinit, i.e. Debian, Corel, RedHat, Mandrake or Caldera:
These commands may already be installed in your SysV init scripts. The first part starts kerneld itself. The second calls depmod -a at startup to build a list of all available modules and analyzes their inter-dependencies. The depmod map then tells kerneld if one module needs to have another loaded before it will itself load.
Next, unpack the kernel sources, configure and build a kernel to your liking. If you have never done this before, you should definitely read the README file at the top level of the Linux sources. When you run make xconfig to configure the kernel, you should pay attention to some questions that appear early on:
You need to select the loadable module support, or there will be no modules for kerneld to load! Just say Yes.
This, of course, is also necessary. Then, a lot of the things in the kernel can be built as modules - you will see questions like
where you can answer with an M for "Module". Generally, only the drivers necessary for you to boot up your system should be built into the kernel; the rest can be built as modules.
When you have gone through the make config, compile and install the new kernel and the modules with make dep clean bzlilo modules modules_install.
Now reboot with the new kernel. When the system comes back up, you can run ps ax, and you should see a line for kerneld:
One of the nice things with kerneld is that once you have the kernel and the daemon installed, very little setup is needed. For a start, try using one of the drivers that you built as a module; it is more likely than not that it will work without further configuration. If I build the floppy driver as a module, I could put a DOS floppy in the drive and type
The floppy driver works! It gets loaded automatically by kerneld when I try to use the floppy disk.
To see that the floppy module is indeed loaded, you can run /sbin/lsmod to list all currently loaded modules:
The "(autoclean)" means that the module will automatically be removed by kerneld when it has not been used for more than one minute. So the 11 pages of memory (= 44kB, one page is 4 kB) will only be used while I access the floppy drive - if I don't use the floppy for more than a minute, they are freed. Quite nice, if you are short of memory for your applications!
Although kerneld comes with builtin knowledge about the most common types of modules, there are situations where kerneld will not know how to handle a request from the kernel. This is the case with things like CD-ROM drivers or network drivers, where there are more than one possible module that can be loaded.
The requests that the kerneld daemon gets from the kernel is for one of the following items:
The kerneld determines what module should be loaded by scanning the configuration file /etc/conf.modules. There are two kinds of entries in this file: Paths where the module-files are located, and aliases assigning the module to be loaded for a given service. If you don't have this file already, you could create it by running
If you want to add yet another path directive to the default paths, you must include all the default paths as well, since a path directive in /etc/conf.modules will replaceall the ones that modprobe knows by default!
Normally you don't want to add any paths by your own, since the built-in set should take care of all normal setups (and then some...), I promise!
On the other hand, if you just want to add an alias or an option directive, your new entries in /etc/conf.modules will be added to the ones that modprobe already knows. If you should redefine an alias or an option, your new entries in /etc/conf.modules will override the built-in ones.
If you run /sbin/modprobe -c, you will get a listing of the modules that kerneld knows about, and what requests they correspond to. For instance, the request that ends up loading the floppy driver is for the block-device that has major number 2:
Why block-major-2 ? Because the floppy devices /dev/fd* use major device 2 and are block devices:
Character devices are dealt with in a similar way. E.g. the ftape floppy tape driver sits on major-device 27:
However, kerneld does not by default know about the ftape driver - it is not listed in the output from /sbin/modprobe -c. So to setup kerneld to load the ftape driver, I must add a line to the kerneld configuration file, /etc/conf.modules:
You can also use the device name instead of the char-major-xxx or block-major-yyy setup. This is especially useful for network drivers. For example, a driver for an ne2000 netcard acting as eth0 would be loaded with
If you need to pass some options to the driver, for example to tell the module about what IRQ the netcard is using, you must add an "options" line:
This will cause kerneld to load the NE2000 driver with the command
Of course, the actual options available are specific to the module you are loading.
Binary formats are handled in a similar way. Whenever you try to run a program that the kernel does not know how to load, kerneld gets a request for binfmt-xxx, where xxx is a number determined from the first few bytes of the executable. So, the kerneld configuration to support loading the binfmt_aout module for ZMAGIC (a.out) executables is
Since the magic number for ZMAGIC files is 267, if you check /etc/magic, you will see the number 0413; keep in mind that /etc/magic uses octal numbers where kerneld uses decimal, and octal 413 = decimal 267. There are actually three slightly different variants of a.out executables (NMAGIC, QMAGIC and ZMAGIC), so for full support of the binfmt_aout module we need
a.out, Java and iBCS binary formats are recognized automatically by kerneld, without any configuration.
Line disciplines are requested with tty-ldisc-x, with x being usually 1 (for SLIP) or 3 (for PPP). Both of these are known by kerneld automatically.
Speaking of ppp, if you want kerneld to load the bsd_comp data compression module for ppp, then you must add the following two lines to your /etc/conf.modules:
Some network protocols can be loaded as modules as well. The kernel asks kerneld for a protocol family (e.g. IPX) with a request for net-pf-X where X is a number indicating what family is wanted. E.g. net-pf-3 is AX.25, net-pf-4 is IPX and net-pf-5 is AppleTalk; These numbers are determined by the AF_AX25, AF_IPX etc. definitions in the linux source file include/linux/socket.h. So to autoload the IPX module, you would need an entry like this in /etc/conf.modules:
See Common Problems for information about how you can avoid some annoying boot-time messages related to undefined protocol families.
kerneld requests for filesystems are simply the name of the filesystem type. A common use of this would be to load the isofs module for CD-ROM filesystems, i.e. filesystems of type iso9660:
Some devices require a bit of extra configuration beyond the normal aliasing of a device to a module.
Hardware devices are usually identified through their major device numbers, e.g. ftape is char-major-27. However, if you look through the entries in /dev for char major 10, you will see that this is a bunch of very different devices, including
These devices are controlled by several different modules, not a single one, and therefore the kerneld configuration for these misc. devices use the major number and the minor number:
You need a kernel version 1.3.82 or later to use this; earlier versions do not pass the minor number to kerneld, making it impossible for kerneld to figure out which of the misc. device modules to load.
Drivers for SCSI devices consist of a driver for the SCSI host adapter (e.g. an Adaptec 1542), and a driver for the type of SCSI device you use, e.g. a hard disk, a CD-ROM or a tape-drive. All of these can be loaded as modules. However, when you want to access e.g. the CD-ROM drive that is connected to the Adaptec card, the kernel and kerneld only knows that it needs to load the sr_mod module in order to support SCSI CD-ROM's; it does not know what SCSI controller the CD-ROM is connected to, and hence does not know what module to load to support the SCSI controller.
To resolve this, you can add an entry for the SCSI driver module to your /etc/conf.modules that tells kerneld which of the many possible SCSI controller modules it should load:
This only works with kernel version 1.3.82 or later.
This works if you have only one SCSI controller. If you have more than one, things become a little more difficult.
In general, you cannot have kerneld load a driver for a SCSI host adapter, if a driver for another host adapter is already installed. You must either build both drivers into your kernel (not as modules), or load the modules manually.
You should be aware, that this technique only works if you have different kinds of SCSI devices on the two controllers, for example, hard disks on one controller, and cd-rom drives, tapes or generic SCSI devices on another.
Sometimes, just loading the module is not enough to get things working. For instance, if you have your sound card compiled as a module, it is often convenient to set a certain volume level. Only problem is, the setting vanishes the next time the module is loaded. Here is a neat trick from Ben Galliart (<firstname.lastname@example.org>):
What this does is that after the sound module is loaded, kerneld runs the command indicated by the post-install sound entry. So the sound module gets configured with the command /usr/local/bin/setmix -f /etc/volume.conf.
This may be useful for other modules as well, for example the lp module can be configured with the tunelp program by adding
For kerneld to recognize these options, you will need a version of kerneld that is 1.3.69f or later.
If you have tried everything, and just cannot figure out what the kernel is asking kerneld to do, there is a way of seeing the requests that kerneld receives, and hence to figure out what should go into /etc/conf.modules: The kdstat utility.
This nifty little program comes with the modules-package, but it is not compiled or installed by default. To build it, go to the directory where you have the kerneld sources and type make kdstat. Then, to make kerneld display information about what it is doing, run kdstat debug and kerneld will start spewing messages on the console about what it is doing. If you then try and run the command that you want to use, you will see the kerneld requests; these can be put into /etc/conf.modules and aliased to the module needed to get the job done.
To turn off the debugging, run /sbin/kdstat nodebug.
I knew you would ask about how to setup the screen-saver module!
The kerneld/GOODIES directory in modules package has a couple of kernel patches for screen-saver and console-beep support in kerneld; these are not yet part of the official kernel, so you will need to install the kernel-patches and rebuild the kernel.
To install a patch, you use the patch command:
Then rebuild and install the new kernel.
When the screen-saver triggers, kerneld will run the command /sbin/screenblanker; this file may be anything you like, for example, a shell script that runs your favorite screen-saver.
When the kernel wants to unblank the screen, it sends a SIGQUIT signal to the process running /sbin/screenblanker. Your shell script or screen-saver should trap this, and terminate. Remember to restore the screen to the original text mode!
Around kernel version 1.3.80, the networking code was changed to allow loading protocol families (e.g. IPX, AX.25 and AppleTalk) as modules. This caused the addition of a new kerneld request: net-pf-X, where X is a number identifying the protocol (see /usr/src/linux/include/linux/socket.h for the meaning of the various numbers). Unfortunately, ifconfig accidentally triggers these messages, so a lot of people get a couple of messages logged when the system boots and it runs ifconfig to setup the loopback device. The messages are harmless, and you can disable them by adding the lines
to /etc/conf.modules. Of course, if you do use IPX as a module, you should not add a line to disable IPX.
There have been a couple of reports of this. It seems to be an unfortunate interaction between kerneld and the tkPPP script that is used on some systems to setup and monitor the PPP connection. The script apparently runs loops while running ifconfig. This triggers kerneld, to look for the net-pf-X modules (see above), keeping the system load high and possibly pouring lots of Cannot locate module for net-pf-X messages into the system log. There is no known workaround, other than not use tkPPP, or change it to use some other way of monitoring the connection.
Add an entry for the SCSI hostadapter to your /etc/conf.modules. See the description of the scsi_hostadapter entry above.
This is a bug in the module utilities, that show up only with binutils 22.214.171.124 and later, and it is also documented in the release note for the binutils. So read that, or fetch an upgrade to the module-utilities that fix this bug.
The settings for a module are stored inside the module itself when it is loaded. So when kerneld auto-unloads a module, any settings you have made are forgotten, and the next time the module loads it reverts to the default settings.
You can tell kerneld to configure a module by running a program after the module has been auto-loaded. See Pre/Post Install on the post-install entry.
You cannot. None of the dosemu versions, official or development versions, support loading the dosemu modules through kerneld. However, if you are running kernel 2.0.26 or later, you do not need the special dosemu modules any longer; just upgrade dosemu to 0.66.1 or higher.
When the kernel sends a request off to to kerneld, it expects to receive an acknowledgment back within one second. If kerneld does not send this acknowledgment, this message is logged. The request is retransmitted, and should get through eventually.
This usually happens on systems with a very high load. Since kerneld is a user-mode process, it is scheduled just like any other process on the system. At times of high load, it may not get to run in time to send back the acknowledgment before the kernel times out.
If this happens even when the load is light, try restarting kerneld. Kill the kerneld process, and start it again with the command /usr/sbin/kerneld. If the problem persists, you should mail a bug report to <email@example.com>, but please make sure that your versions of the kernel, kerneld and the module utilities are up-to-date before posting about the problem. Check the requirements in linux/Documentation/Changes
There has been a number of reports that the mount(8) command does not wait for kerneld to load the filesystem module. lsmod does show that kerneld loads the module, and if you repeat the mount command immediately it will succeed. This appears to be a bug in the module-utilities version 1.3.69f that affects some Debian users. It can be fixed by getting a later version of the module-utilities.
You need to compile the ncpfs utilities with -DHAVE_KERNELD. See the ncpfs Makefile.
You are using an older version of the smbmount utilities. Get the latest version (0.10 or later) from the SMBFS archive one TSX-11
You cannot modularize everything: The kernel must have enough drivers built in for it to be able to mount your root filesystem, and run the necessary programs to start kerneld. You cannot modularize
Newer versions of kerneld need the GNU dbm library, libgdbm.so, to run. Most installations have this file in /usr/lib, but you are probably starting kerneld before the /usr filesystem is mounted. One symptom of this is that kerneld will not start during boot-up (from your rc-scripts), but runs fine if you start it by hand after that system is up. The solution is to either move the kerneld startup to after your /usr is mounted, or move the gdbm library to your root filesystem, e.g. to /lib.
The Slackware installation (possibly others) builds a default /etc/rc.d/rc.modules which does an explicit modprobe on a variety of modules. Exactly which modules get modprobed depends on the original kernel's configuration. You have probably reconfigured your kernel to exclude one or more of the modules that is getting modprobed in rc.modules, thus, the error message(s). Update your rc.modules by commenting out any modules you no longer use, or remove the rc.modules entirely and let kerneld load the modules when they are needed.
You probably reconfigured/rebuilt your kernel and excluded some modules. You've got some old modules that you no longer use hanging around in the /lib/modules directory. The easiest fix is to delete your /lib/modules/x.y.z directory and do a make modules_install from the kernel source directory again. Note that this problem only occurs when reconfiguring your kernel without changing versions. If you see this error when moving to a newer kernel version you've got some other problem.
Odd numbered Linux are development kernels. As such, it should be expected that things break from time to time. One of the things that has changed significantly is the way modules are handled, and where the kernel and modules are loaded into memory.
In brief, if you want to use modules with a development kernel, you must
I recommend using at least kernel 2.1.29, if you want to use modules with a 2.1 kernel.
kerneld originally had some support for establishing dial-up network connections on demand; trying to send packets to a network without being connected would cause kerneld to run the /sbin/request_route script to setup a PPP or SLIP connection.
This turned out to be a bad idea. Alan Cox of Linux networking fame wrote on the linux-kernel mailing list
Instead of using the request-route script and kerneld, I highly recommend Eric Schenk's diald package to manage your demand dialing.