|Linux kerneld mini-HOWTO|
Xmessages when I run /sbin/ifconfig?
xxxbut I just reconfigured my kernel without
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:
X is a number identifying the protocol
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
(see above), keeping the system load high and possibly
pouring lots of Cannot locate module for
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
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 188.8.131.52 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 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
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
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
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
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
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.
Actually, this is not true. Late 1.3.x and all 2.x kernels support the use of an initial ram-disk that is loaded by LILO or LOADLIN; it is possible to load modules from this disk very early in the boot process. How to do it is described in the linux/Documentation/initrd.txt file that comes with the kernel source-files.