Common problems and things that make you wonder

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

        alias net-pf-3 off      # Forget AX.25
        alias net-pf-4 off      # Forget IPX
        alias net-pf-5 off      # Forget AppleTalk

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 2.6.0.9 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 protected]>, 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[1]. You cannot modularize

• the driver for the hard disk where your root filesystem lives

• the root filesystem driver itself

• the binary format loader for init, kerneld and other programs

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

• read the Documentation/Changes file and see what packages need upgrading on your system

• use the latest modutils package, available from AlphaBits on Red Hat or the mirror site at TSX-11

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

The request-route stuff is obsolete, broken and not required [...] Its also removed from 2.1.x trees.

Instead of using the request-route script and kerneld, I highly recommend Eric Schenk's diald package to manage your demand dialing.