mirror of https://github.com/tLDP/LDP
1232 lines
50 KiB
Plaintext
1232 lines
50 KiB
Plaintext
<!DOCTYPE ARTICLE PUBLIC "-//OASIS//DTD DocBook V3.1//EN"[
|
|
]>
|
|
<article class="journalarticle"
|
|
status="DRAFT"
|
|
id="kerneld" lang="EN"
|
|
xreflabel="kerneld mini-HOWTO"
|
|
os="linux"
|
|
revision="$Id$"
|
|
vendor="Linux Documentation Project">
|
|
<artheader>
|
|
<title>Linux kerneld mini-HOWTO</title>
|
|
<authorgroup>
|
|
<author>
|
|
<firstname>Henrik</firstname>
|
|
<surname>Storner</surname>
|
|
<affiliation>
|
|
<address><email>kerneld-howto@linuxdoc.org</email></address>
|
|
</affiliation>
|
|
</author>
|
|
</authorgroup>
|
|
|
|
<revhistory>
|
|
<revision>
|
|
<revnumber>v2.0</revnumber>
|
|
<date>22 May 2000</date>
|
|
<revremark>
|
|
conversion from HTML to DocBook SGML.
|
|
</revremark>
|
|
</revision>
|
|
</revhistory>
|
|
|
|
<copyright>
|
|
<year>2000</year>
|
|
<holder role="mailto:kerneld-howto@linuxdoc.org">Linux Documentation
|
|
Project</holder>
|
|
</copyright>
|
|
<legalnotice>
|
|
<title>Copyright</title>
|
|
<para>This document is Copyright by Henrik Storner, 1996, 1997.</para>
|
|
|
|
<para>Unless otherwise stated, Linux HOWTO documents are
|
|
copyrighted by their respective authors. Linux HOWTO documents
|
|
may be reproduced and distributed in whole or in part, in any
|
|
medium physical or electronic, as long as this copyright notice
|
|
is retained on all copies. Commercial redistribution is allowed
|
|
and encouraged; however, the author would like to be notified of
|
|
any such distributions. </para>
|
|
|
|
<para>All translations, derivative works, or aggregate works
|
|
incorporating any Linux HOWTO documents must be covered under
|
|
this copyright notice. That is, you may not produce a
|
|
derivative work from a HOWTO and impose additional restrictions
|
|
on its distribution. Exceptions to these rules may be granted
|
|
under certain conditions; please contact the Linux HOWTO
|
|
coordinator at the address given below. </para>
|
|
|
|
<para>In short, we wish to promote dissemination of this
|
|
information through as many channels as possible. However, we do
|
|
wish to retain copyright on the HOWTO documents, and would like
|
|
to be notified of any plans to redistribute the HOWTOs. </para>
|
|
|
|
<para>If you have questions, please contact the Linux HOWTO
|
|
coordinator, at linux-howto@sunsite.unc.edu via email.</para>
|
|
</legalnotice>
|
|
|
|
</artheader>
|
|
<sect1><title>About the kerneld mini-HOWTO</title>
|
|
|
|
<para>This document explains how to install and use the automatic
|
|
kernel module loader <quote>kerneld</quote>. The latest released
|
|
version of this document can be found at <ulink
|
|
url="http://www.linuxdoc.org">the Linux Documentation
|
|
Project</ulink></para>
|
|
|
|
<sect2 id="credits"><title>Credits</title>
|
|
|
|
<para>This document is based on an original HTML version 1.7
|
|
dated July 19, 1997 by Henrik Storner
|
|
<email>storner@osiris.ping.dk</email> and was revised and
|
|
translated to DocBook DTD by Gary Lawrence Murphy
|
|
<email>garym@teledyn.com</email> May 20, 2000.</para>
|
|
|
|
<para>The following people have contributed to this
|
|
mini-HOWTO at some point:</para>
|
|
|
|
<itemizedlist>
|
|
<LISTITEM><PARA>Bjorn Ekwall bj0rn@blox.se</PARA></LISTITEM>
|
|
<LISTITEM><PARA>Ben Galliart bgallia@luc.edu</PARA></LISTITEM>
|
|
<LISTITEM><PARA>Cedric Tefft cedric@earthling.net</PARA></LISTITEM>
|
|
<LISTITEM><PARA>Brian Miller bmiller@netspace.net.au</PARA></LISTITEM>
|
|
<LISTITEM><PARA>James C. Tsiao
|
|
jtsiao@madoka.jpl.nasa.gov</PARA></LISTITEM>
|
|
</itemizedlist>
|
|
|
|
<para>If you find errors in this document, please send email to
|
|
<email>kerneld-howto@linuxdoc.org</email>. Your comments,
|
|
encouragement and suggestions are welcome and appreciated, and
|
|
help ensure this guide remains current and accurate.</para>
|
|
|
|
</sect2>
|
|
</sect1>
|
|
<sect1 id="introduction"><title>What is kerneld?</title>
|
|
|
|
<para>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 <command>modprobe</command> or
|
|
<command>insmod</command>. </para>
|
|
|
|
<para>And for the more amusing aspects, although these are not
|
|
(yet ?) integrated with the standard kernel: </para>
|
|
|
|
<itemizedlist>
|
|
<LISTITEM><PARA>It can be setup to run a user-program instead
|
|
of the default screen blanker, thus letting you use any
|
|
program as a screen-saver. </PARA></LISTITEM>
|
|
|
|
<LISTITEM><PARA>Similar to the screen-blanker support, you can
|
|
also change the standard console beep into something
|
|
completely different. </PARA></LISTITEM>
|
|
</itemizedlist>
|
|
|
|
<para>kerneld consists of two components: </para>
|
|
|
|
<itemizedlist>
|
|
<LISTITEM><PARA>Support in the Linux kernel for sending
|
|
requests to a daemon requesting a module for a certain
|
|
task. </PARA></LISTITEM>
|
|
|
|
<LISTITEM><PARA>A user-space daemon that can figure out what
|
|
modules must be loaded to fulfill the request from the
|
|
kernel. </PARA></LISTITEM>
|
|
</itemizedlist>
|
|
|
|
<para>Both components must be working for the kerneld support to
|
|
function; it is not enough that only one or the other has been
|
|
setup. </para>
|
|
|
|
<sect2 ID="Why"><title>Why do I want to use it ?</title>
|
|
|
|
<para>There are some good reasons for using kerneld. The ones I
|
|
will mention are mine, others have other reasons. </para>
|
|
|
|
<itemizedlist>
|
|
<LISTITEM><PARA>If you have to build kernels for several
|
|
systems that only differ slightly - different kind of network
|
|
card, for instance - then you can build a single kernel and
|
|
some modules, instead of having to build individual kernels
|
|
for each system. </PARA></LISTITEM>
|
|
|
|
<LISTITEM><PARA>Modules are easier for developers to test.
|
|
You don't need to reboot the system to load and unload the
|
|
driver; this applies to all modules, not just kerneld-loaded
|
|
ones. </PARA></LISTITEM>
|
|
|
|
<LISTITEM><PARA >It cuts down on the kernel memory usage
|
|
leaving more memory available for applications. Memory used by
|
|
the kernel is <emphasis>never</emphasis> swapped out, so if
|
|
you have 100Kb worth of unused drivers compiled into your
|
|
kernel, they are simply wasting RAM. </PARA></LISTITEM>
|
|
|
|
<LISTITEM><PARA >Some of the things I use, the ftape
|
|
floppy-tape driver, for instance, or iBCS, are only available
|
|
as modules, but I don't want to bother with loading and
|
|
unloading them whenever I need them. </PARA ></LISTITEM >
|
|
|
|
<LISTITEM><PARA>People making Linux distributions don't have
|
|
to build 284 different boot images: Each user loads the
|
|
drivers he needs for just his hardware. Most modern Linux
|
|
distributions will detect your hardware and will only load
|
|
those modules actually required.</PARA ></LISTITEM>
|
|
</itemizedlist >
|
|
|
|
<para>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.</para >
|
|
|
|
</sect2>
|
|
<sect2 ID="Where"><title>Where can I pick up the necessary pieces
|
|
?</title>
|
|
|
|
<para>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:</para >
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><ulink
|
|
url="ftp://ftp.kernel.org/pub/linux/kernel/">Kernel.Org
|
|
Archive</ulink></para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><ulink
|
|
url="ftp://metalab.unc.edu/pub/Linux/kernel/">Metalab Linux
|
|
Archive</ulink></para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><ulink
|
|
url="ftp://tsx-11.mit.edu/pub/linux/sources/system/">TSX-11
|
|
at MIT</ulink></para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>The user-space daemon is included with the
|
|
<productname>modules</productname> package. These are normally
|
|
available from the same place as the kernel sources
|
|
</para>
|
|
|
|
<note>
|
|
<para>If you want to try module-loading with the latest
|
|
<emphasis>development</emphasis> kernels, you should use the
|
|
newer <productname>modutils</productname> package and not the
|
|
<productname>modules</productname>. Always check the
|
|
<filename>Documentation/Changes</filename> file in the kernel
|
|
sources for the minimum required version number for your kernel
|
|
image. Also see <xref
|
|
linkend="kernel2-1-problems"> about the problems with modules
|
|
and 2.1 kernels.</para ></note>
|
|
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="setup"><title>How do I set it up?</title>
|
|
|
|
<para>First get the necessary parts: A suitable kernel and the
|
|
latest <productname>modules</productname> package. Then you
|
|
should install the module utilities as per the instructions
|
|
included in the package. Pretty simple: Just unpack the sources
|
|
and run <command>make install</command>. This compiles and
|
|
installs the following programs in <filename>/sbin</filename>:
|
|
<command>genksysm</command>, <command>insmod</command>,
|
|
<command>lsmod</command>, <command>modprobe</command>,
|
|
<command>depmod</command> and <command>kerneld</command>. 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 <filename>/etc/rc.d/rc.S</filename> file (if you are
|
|
running Slackware), or to
|
|
<filename>/etc/rc.d/rc.sysinit</filename> if you are running
|
|
SysVinit, i.e. Debian, Corel, RedHat, Mandrake or Caldera:
|
|
</para>
|
|
|
|
<programlisting>
|
|
# Start kerneld - this should happen very early in the
|
|
# boot process, certainly BEFORE you run fsck on filesystems
|
|
# that might need to have disk drivers autoloaded
|
|
if [ -x /sbin/kerneld ]
|
|
then
|
|
/sbin/kerneld
|
|
fi
|
|
|
|
# Your standard fsck commands go here
|
|
# And you mount command to mount the root fs read-write
|
|
|
|
# Update kernel-module dependencies file
|
|
# Your root-fs MUST be mounted read-write by now
|
|
if [ -x /sbin/depmod ]
|
|
then
|
|
/sbin/depmod -a
|
|
fi
|
|
</programlisting>
|
|
|
|
<para>These commands may already be installed in your SysV init
|
|
scripts. The first part starts kerneld itself. The second calls
|
|
<command>depmod -a</command> 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. </para >
|
|
|
|
<note>
|
|
<para>Recent versions of kerneld have an option to link with the
|
|
GNU gdbm library, <productname>libgdbm</productname>. If you
|
|
enable this when building the module utilities,
|
|
<emphasis>kerneld will not start if libgdbm is not
|
|
available</emphasis> which may well be the case if you have
|
|
<filename>/usr</filename> on a separate partition and start
|
|
kerneld before <filename>/usr</filename> is mounted. The
|
|
recommended solution is to move
|
|
<filename>/usr/lib/libgdbm</filename> to
|
|
<filename>/lib</filename>, or to link kerneld
|
|
statically.</para></note>
|
|
|
|
<para>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 <emphasis>make xconfig</emphasis>
|
|
to configure the kernel, you should pay attention to some
|
|
questions that appear early on: </para >
|
|
|
|
<screen>
|
|
Enable loadable module support (CONFIG_MODULES) [Y/n/?] Y
|
|
</screen
|
|
|
|
<para>You need to select the loadable module support, or there
|
|
will be no modules for kerneld to load! Just say Yes. </para>
|
|
|
|
<screen>
|
|
Kernel daemon support (CONFIG_KERNELD) [Y/n/?] Y
|
|
</screen>
|
|
|
|
<para>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 </para >
|
|
|
|
<screen>
|
|
Normal floppy disk support (CONFIG_BLK_DEV_FD) [M/n/y/?]
|
|
</screen>
|
|
|
|
<para>where you can answer with an <keysym>M</keysym> for
|
|
<quote>Module</quote>. 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. </para>
|
|
|
|
<caution>
|
|
<title>Essential drivers</title> <para>Essential drivers
|
|
required to boot your system must be compiled into the core
|
|
kernel and cannot be loaded as modules. Typically this will
|
|
include the hard-disk driver and the driver for the root
|
|
filesystem. If you have a dual-boot machine and rely on files
|
|
found in the foreign partition, you must also compile support
|
|
for that filesystem into the core kernel.</para>
|
|
</caution>
|
|
|
|
<para>When you have gone through the <command>make
|
|
config</command>, compile and install the new
|
|
kernel and the modules with <command>make dep clean bzlilo
|
|
modules modules_install</command>.</para >
|
|
|
|
<para>Phew. </para>
|
|
|
|
<tip>
|
|
<title>Compiling a Kernel Image</title> <para>The
|
|
<command>make zImage</command> command will stop short of
|
|
installing a kernel and will leave the new kernel image in the
|
|
file <filename>arch/i386/boot/zImage</filename>. To use this
|
|
image, you will
|
|
need to copy it to where you keep your boot-image and install it
|
|
manually with LILO. </para >
|
|
|
|
<para>For more information about configuring, building and
|
|
installing your own kernel, check out the Kernel-HOWTO posted
|
|
regularly to <filename>comp.os.linux.answers</filename>, and
|
|
available from <ulink url="http://www.linuxdoc.org">the Linux
|
|
Documentation Project</ulink> and its mirrors.</para ></tip>
|
|
|
|
<sect2 ID="Testing"><title>Trying out kerneld</title>
|
|
|
|
<para>Now reboot with the new kernel. When the system comes back
|
|
up, you can run <command>ps ax</command>, and you should see a
|
|
line for kerneld: </para >
|
|
|
|
<screen>
|
|
PID TTY STAT TIME COMMAND
|
|
59 ? S 0:01 /sbin/kerneld
|
|
</screen>
|
|
|
|
<para>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</para>
|
|
|
|
<screen>
|
|
osiris:~ $ mdir a:
|
|
Volume in drive A has no label
|
|
Volume Serial Number is 2E2B-1102
|
|
Directory for A:/
|
|
|
|
binuti~1 gz 1942 02-14-1996 11:35a binutils-2.6.0.6-2.6.0.7.diff.gz
|
|
libc-5~1 gz 24747 02-14-1996 11:35a libc-5.3.4-5.3.5.diff.gz
|
|
2 file(s) 26689 bytes
|
|
</screen>
|
|
|
|
<para>The floppy driver works! It gets loaded automatically
|
|
by kerneld when I try to use the floppy disk. </para >
|
|
|
|
<para>To see that the floppy module is indeed loaded, you can
|
|
run <command>/sbin/lsmod</command> to list all currently
|
|
loaded modules: </para>
|
|
|
|
<screen>
|
|
osiris:~ $ /sbin/lsmod
|
|
Module: #pages: Used by:
|
|
floppy 11 0 (autoclean)
|
|
</screen>
|
|
|
|
<para>The <quote>(autoclean)</quote> 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! </para >
|
|
|
|
</sect2>
|
|
</sect1>
|
|
|
|
|
|
<sect1 id="configuration"><title>How does kerneld know what module
|
|
to load?</title>
|
|
|
|
<para>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. </para >
|
|
|
|
<para>The requests that the kerneld daemon gets from the kernel
|
|
is for one of the following items: </para >
|
|
|
|
<itemizedlist>
|
|
<LISTITEM><PARA>a block-device driver </PARA></LISTITEM>
|
|
|
|
<LISTITEM><PARA>a character-device driver </PARA></LISTITEM>
|
|
|
|
<LISTITEM><PARA>a binary format </PARA></LISTITEM>
|
|
|
|
<LISTITEM><PARA>a tty line discipline </PARA></LISTITEM>
|
|
|
|
<LISTITEM><PARA>a filesystem </PARA></LISTITEM>
|
|
|
|
<LISTITEM><PARA>a network device </PARA></LISTITEM>
|
|
|
|
<LISTITEM><PARA>a network service (e.g. rarp) </PARA></LISTITEM>
|
|
|
|
<LISTITEM><PARA>a network protocol (e.g. IPX)
|
|
</PARA></LISTITEM>
|
|
</itemizedlist>
|
|
|
|
<para>The kerneld determines what module should be loaded by
|
|
scanning the configuration file
|
|
<filename>/etc/conf.modules</filename><footnote> <para>Some
|
|
distributions call this file
|
|
<filename>modules.conf</filename></para> </footnote>. 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
|
|
</para >
|
|
|
|
<screen>
|
|
/sbin/modprobe -c | grep -v '^path' /etc/conf.modules
|
|
</screen>
|
|
|
|
<para>If you want to add yet another path directive to the
|
|
default paths, you <emphasis>must include all the default paths
|
|
as well</emphasis>, since a path directive in
|
|
<filename>/etc/conf.modules</filename> will
|
|
<emphasis>replace</emphasis>all the ones that modprobe knows by
|
|
default! </para>
|
|
|
|
<para>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! </para >
|
|
|
|
<para>On the other hand, if you just want to add an alias or an
|
|
option directive, your new entries in
|
|
<filename>/etc/conf.modules</filename> will be
|
|
<emphasis>added</emphasis> to the ones that modprobe already
|
|
knows. If you should <emphasis>redefine</emphasis> an alias or
|
|
an option, your new entries in
|
|
<filename>/etc/conf.modules</filename> will override the
|
|
built-in ones.</para >
|
|
|
|
<sect2 id="blockdev"><title>Block devices</title>
|
|
|
|
<para>If you run <command>/sbin/modprobe -c</command>, 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: </para >
|
|
|
|
<screen>
|
|
osiris:~ $ /sbin/modprobe -c | grep floppy
|
|
alias block-major-2 floppy
|
|
</screen>
|
|
|
|
<para>Why <filename>block-major-2</filename> ? Because the
|
|
floppy devices <filename>/dev/fd*</filename> use major device 2
|
|
and are block devices:
|
|
</para >
|
|
|
|
<screen>
|
|
osiris:~ $ ls -l /dev/fd0 /dev/fd1
|
|
brw-rw-rw- 1 root root 2, 0 Mar 3 1995 /dev/fd0
|
|
brw-r--r-- 1 root root 2, 1 Mar 3 1995 /dev/fd1
|
|
</screen>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="chardev"><title>Character devices</title>
|
|
<para>Character devices are dealt with in a similar
|
|
way. E.g. the ftape floppy tape driver sits on major-device
|
|
27: </para >
|
|
|
|
<screen>
|
|
osiris:~ $ ls -lL /dev/ftape
|
|
crw-rw---- 1 root disk 27, 0 Jul 18 1994 /dev/ftape
|
|
</screen>
|
|
|
|
<para>However, kerneld does not by default know about the
|
|
ftape driver - it is not listed in the output from
|
|
<command>/sbin/modprobe -c</command>. So to setup kerneld to
|
|
load the ftape driver, I must add a line to the kerneld
|
|
configuration file, <filename>/etc/conf.modules</filename>:
|
|
</para>
|
|
|
|
<screen>
|
|
alias char-major-27 ftape
|
|
</screen>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="eth0"><title>Network devices</title>
|
|
|
|
<para>You can also use the device name instead of the
|
|
<literal>char-major-xxx</literal> or
|
|
<literal>block-major-yyy</literal> setup. This is especially
|
|
useful for network drivers. For example, a driver for an
|
|
ne2000 netcard acting as <filename>eth0</filename> would be
|
|
loaded with </para >
|
|
|
|
<screen>
|
|
alias eth0 ne
|
|
</screen>
|
|
|
|
<para>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 <quote>options</quote> line: </para >
|
|
|
|
<screen>
|
|
options ne irq=5
|
|
</screen>
|
|
|
|
<para>This will cause kerneld to load the NE2000 driver with
|
|
the command </para>
|
|
|
|
<screen>
|
|
/sbin/modprobe ne irq=5
|
|
</screen>
|
|
|
|
<para>Of course, the actual options available are specific to
|
|
the module you are loading. </para >
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="binfmt"><title>Binary formats</title>
|
|
|
|
<para>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
|
|
<literal>binfmt-</literal><varname>xxx</varname>, where
|
|
<varname>xxx</varname> 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
|
|
</para>
|
|
|
|
<screen>
|
|
alias binfmt-267 binfmt_aout
|
|
</screen>
|
|
|
|
<para>Since the magic number for ZMAGIC files is 267, if you
|
|
check <filename>/etc/magic</filename>, you will see the number
|
|
0413; keep in mind that <filename>/etc/magic</filename> 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
|
|
</para>
|
|
|
|
<screen>
|
|
alias binfmt-264 binfmt_aout # pure executable (NMAGIC)
|
|
alias binfmt-267 binfmt_aout # demand-paged executable (ZMAGIC)
|
|
alias binfmt-204 binfmt_aout # demand-paged executable (QMAGIC)
|
|
</screen>
|
|
|
|
<para>a.out, Java and iBCS binary formats are recognized
|
|
automatically by kerneld, without any configuration. </para>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="ldisc"><title>Line disciplines (slip, cslip and ppp)</title>
|
|
|
|
<para>Line disciplines are requested with
|
|
<literal>tty-ldisc-</literal><varname>x</varname>, with
|
|
<varname>x</varname>
|
|
being usually 1 (for SLIP) or 3 (for PPP). Both of these are
|
|
known by kerneld automatically. </para>
|
|
|
|
<para>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
|
|
<filename>/etc/conf.modules</filename>:</para >
|
|
|
|
<screen>
|
|
alias tty-ldisc-3 bsd_comp
|
|
alias ppp0 bsd_comp
|
|
</screen>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="net-pf"><title>Network protocol families (IPX,
|
|
AppleTalk, AX.25)</title>
|
|
|
|
<para>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
|
|
<literal>net-pf-</literal><varname>X</varname> where
|
|
<varname>X</varname> is a number indicating what family is
|
|
wanted. E.g. <literal>net-pf-3</literal> is AX.25,
|
|
<literal>net-pf-4</literal> is IPX and
|
|
<literal>net-pf-5</literal> is AppleTalk; These numbers are
|
|
determined by the AF_AX25, AF_IPX etc. definitions in the
|
|
linux source file <filename>include/linux/socket.h</filename>.
|
|
So to autoload the IPX module, you would need an entry like
|
|
this in <filename>/etc/conf.modules</filename>:</para>
|
|
|
|
<screen>
|
|
alias net-pf-4 ipx
|
|
</screen>
|
|
|
|
<para>See <xref linkend="commonproblems"> for information
|
|
about how you can avoid some annoying boot-time messages
|
|
related to undefined protocol families. </para>
|
|
</sect2>
|
|
|
|
<sect2 id="fs"><title>File systems</title>
|
|
|
|
<para>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: </para >
|
|
|
|
<screen>
|
|
alias iso9660 isofs
|
|
</screen>
|
|
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="special-devs"><title>Devices requiring special
|
|
configuration</title>
|
|
|
|
<para >Some devices require a bit of extra configuration beyond the
|
|
normal aliasing of a device to a module. </para >
|
|
|
|
<itemizedlist>
|
|
<LISTITEM><PARA>Character devices on major number 10: <link
|
|
linkend="miscdevs">The miscellaneous
|
|
devices</link></PARA></LISTITEM>
|
|
|
|
<LISTITEM><PARA><link linkend="scsidevs">SCSI devices</link>
|
|
</PARA></LISTITEM>
|
|
|
|
<LISTITEM><PARA><link linkend="pre-post">Devices that require
|
|
special initialization</link></PARA></LISTITEM>
|
|
</itemizedlist>
|
|
|
|
<sect2 id="miscdevs">
|
|
<title>char-major-10 : Mice, watchdogs and randomness</title>
|
|
|
|
<para>Hardware devices are usually identified through their
|
|
major device numbers, e.g. ftape is
|
|
<literal>char-major-27</literal>. However, if you look through
|
|
the entries in <filename>/dev</filename> for char major 10,
|
|
you will see that this is a bunch of very different devices,
|
|
including </para >
|
|
|
|
<itemizedlist>
|
|
<LISTITEM><PARA>Mice of various sorts (bus mice, PS/2
|
|
mice)</PARA></LISTITEM>
|
|
|
|
<LISTITEM><PARA>Watchdog devices </PARA></LISTITEM>
|
|
|
|
<LISTITEM><PARA>The kernel <filename>random</filename>
|
|
device </PARA></LISTITEM>
|
|
|
|
<LISTITEM><PARA>APM (Advanced Power Management) interface
|
|
</PARA></LISTITEM>
|
|
|
|
</itemizedlist>
|
|
|
|
<para>These devices are controlled by several different
|
|
modules, not a single one, and therefore the kerneld
|
|
configuration for these <emphasis>misc. devices</emphasis>
|
|
use the major number <emphasis>and</emphasis> the minor
|
|
number: </para >
|
|
|
|
<screen>
|
|
alias char-major-10-1 psaux # For PS/2 mouse
|
|
alias char-major-10-130 wdt # For WDT watchdog
|
|
</screen>
|
|
|
|
<para>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. </para>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="scsidevs">
|
|
<title>Loading SCSI drivers: The
|
|
<literal>scsi_hostadapter</literal> entry</title>
|
|
|
|
<para>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 <filename>sr_mod</filename>
|
|
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. </para >
|
|
|
|
<para>To resolve this, you can add an entry for the SCSI
|
|
driver module to your <filename>/etc/conf.modules</filename>
|
|
that tells kerneld which of the many possible SCSI controller
|
|
modules it should load: </para >
|
|
|
|
<screen>
|
|
alias scd0 sr_mod # sr_mod for SCSI CD-ROM's ...
|
|
alias scsi_hostadapter aha1542 # ... need the Adaptec driver
|
|
</screen>
|
|
|
|
<para>This only works with kernel version 1.3.82 or later. </para>
|
|
|
|
<para>This works if you have only one SCSI controller. If you
|
|
have more than one, things become a little more
|
|
difficult.</para>
|
|
|
|
<para>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.</para >
|
|
|
|
<tip> <para>There <emphasis>is</emphasis> a way that you can
|
|
have kerneld load multiple SCSI drivers. James Tsiao came up
|
|
with this idea:</para >
|
|
|
|
<blockquote>
|
|
<para> You can easily have kerneld load the second scsi
|
|
driver by setting up the dependency in your modules.dep by
|
|
hand. You just need an entry like:</para>
|
|
|
|
<screen>
|
|
/lib/modules/2.0.30/scsi/st.o: /lib/modules/2.0.30/scsi/aha1542.o
|
|
</screen>
|
|
<para>To have kerneld load the
|
|
<filename>aha1542.o</filename> before it loads
|
|
<filename>st.o</filename>. My machine at home is set up
|
|
almost exactly like the setup above, and it works fine for
|
|
all my secondary scsi devices, including tape, cd-rom, and
|
|
generic scsi devices. The drawback is that
|
|
<command>depmod -a</command> can't autodetect these
|
|
dependencies, so the user needs to add them by hand, and
|
|
not run <command>depmod -a</command> on boot up. But once
|
|
it is set up, kerneld will autoload the
|
|
<filename>aha1542.o</filename> just
|
|
fine.</para></blockquote></tip>
|
|
|
|
<para>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.</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="pre-post" xreflabel="Pre/Post Install">
|
|
<title>When loading a module isn't enough: The
|
|
<literal>post-install</literal> entry</title>
|
|
|
|
<para>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 (<email>bgallia@luc.edu</email>): </para >
|
|
|
|
<blockquote>
|
|
<para>The final solution required installing the <ulink
|
|
url="ftp://sunsite.unc.edu/pub/Linux/apps/sound/mixers/">
|
|
<productname>setmix</productname> package</ulink> and then
|
|
adding the following line to my
|
|
<filename>/etc/conf.modules</filename>: </para>
|
|
<programlisting>
|
|
post-install sound /usr/local/bin/setmix -f /etc/volume.conf
|
|
</programlisting>
|
|
</blockquote>
|
|
|
|
<para>What this does is that after the sound module is loaded,
|
|
kerneld runs the command indicated by the
|
|
<literal>post-install sound</literal> entry. So the sound
|
|
module gets configured with the command
|
|
<command>/usr/local/bin/setmix -f
|
|
/etc/volume.conf</command>.</para >
|
|
|
|
<para>This may be useful for other modules as well, for
|
|
example the <filename>lp</filename> module can be configured
|
|
with the <filename>tunelp</filename> program by adding
|
|
</para >
|
|
|
|
<programlisting>
|
|
post-install lp tunelp options
|
|
</programlisting>
|
|
|
|
<para>For kerneld to recognize these options, you will need a
|
|
version of kerneld that is 1.3.69f or later.</para >
|
|
|
|
<note>
|
|
|
|
<para>An earlier version of this mini-HOWTO mentioned a
|
|
pre-remove option, that might be used to run a command just
|
|
before kerneld removed a module. However, this has never
|
|
worked and its use is therefore discouraged - most likely,
|
|
this option will disappear in a future kerneld release. The
|
|
whole issue of module settings is undergoing some change at
|
|
the moment, and may look different on your system by the
|
|
time you read this. </para ></note>
|
|
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="spying"><title>Spying on kerneld</title>
|
|
|
|
<para>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 <filename>/etc/conf.modules</filename>:
|
|
The <command>kdstat</command> utility. </para >
|
|
|
|
<para>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
|
|
<command>make kdstat</command>. Then, to make kerneld display
|
|
information about what it is doing, run <command>kdstat debug
|
|
</command> 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 <filename>/etc/conf.modules</filename> and
|
|
aliased to the module needed to get the job done. </para>
|
|
|
|
<para>To turn off the debugging, run <command>/sbin/kdstat
|
|
nodebug</command>. </para >
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="goodies"><title>Special kerneld uses</title>
|
|
|
|
<para>I knew you would ask about how to setup the screen-saver
|
|
module!</para >
|
|
|
|
<para>The <filename>kerneld/GOODIES</filename> 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. </para >
|
|
|
|
<para>To install a patch, you use the patch command: </para>
|
|
|
|
<screen>
|
|
cd /usr/src/linux
|
|
patch -s -p1 /usr/src/modules-*/kerneld/GOODIES/blanker_patch
|
|
</screen>
|
|
|
|
<para>Then rebuild and install the new kernel. </para>
|
|
|
|
<para>When the screen-saver triggers, kerneld will run the
|
|
command <filename>/sbin/screenblanker</filename>; this file may
|
|
be anything you like, for example, a shell script that runs your
|
|
favorite screen-saver. </para >
|
|
|
|
<para>When the kernel wants to unblank the screen, it sends a
|
|
<token>SIGQUIT</token> signal to the process running
|
|
<filename>/sbin/screenblanker</filename>. Your shell script or
|
|
screen-saver should trap this, and terminate. Remember to restore
|
|
the screen to the original text mode! </para >
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="commonproblems" xreflabel="Common Problems">
|
|
<title>Common problems and things that make you wonder</title>
|
|
|
|
<qandaset>
|
|
<qandaentry>
|
|
<question>
|
|
<para>Why do I get <errorname>Cannot locate module for
|
|
net-pf-</errorname><varname>X</varname> messages when I
|
|
run <command>/sbin/ifconfig</command>?</para></question>
|
|
|
|
<answer>
|
|
<para>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:
|
|
<literal>net-pf-</literal><varname>X</varname>, where
|
|
<varname>X</varname> is a number identifying the protocol
|
|
(see
|
|
<filename>/usr/src/linux/include/linux/socket.h</filename>
|
|
for the meaning of the various numbers). Unfortunately,
|
|
<command>ifconfig</command> accidentally triggers these
|
|
messages, so a lot of people get a couple of messages
|
|
logged when the system boots and it runs
|
|
<command>ifconfig</command> to setup the loopback
|
|
device. The messages are harmless, and you can disable
|
|
them by adding the lines</para>
|
|
|
|
<screen>
|
|
alias net-pf-3 off # Forget AX.25
|
|
alias net-pf-4 off # Forget IPX
|
|
alias net-pf-5 off # Forget AppleTalk
|
|
</screen>
|
|
|
|
<para>to <filename>/etc/conf.modules</filename>. Of
|
|
course, if you do use IPX as a module, you should not add
|
|
a line to disable IPX. </para>
|
|
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>After starting kerneld, my system slows to a crawl
|
|
when I activate my ppp-connection</para> </question>
|
|
|
|
<answer>
|
|
<para>There have been a couple of reports of this. It
|
|
seems to be an unfortunate interaction between kerneld and
|
|
the <productname>tkPPP</productname> script that is used
|
|
on some systems to setup and monitor the PPP
|
|
connection. The script apparently runs loops while running
|
|
<command>ifconfig</command>. This triggers kerneld, to
|
|
look for the
|
|
<literal>net-pf-</literal><varname>X</varname> modules
|
|
(see above), keeping the system load high and possibly
|
|
pouring lots of Cannot locate module for
|
|
<literal>net-pf-</literal><varname>X</varname> messages
|
|
into the system log. There is no known workaround, other
|
|
than not use <productname>tkPPP</productname>, or change
|
|
it to use some other way of monitoring the
|
|
connection.</para >
|
|
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>kerneld does not load my SCSI driver!</para></question>
|
|
<answer>
|
|
<para>Add an entry for the SCSI hostadapter to your
|
|
<filename>/etc/conf.modules</filename>. See the
|
|
description of the <link
|
|
linkend="scsidevs"><literal>scsi_hostadapter</literal></link>
|
|
entry above.</para>
|
|
|
|
</answer></qandaentry>
|
|
<qandaentry>
|
|
<question>
|
|
<para>modprobe complains about
|
|
<errorname>gcc2_compiled</errorname> being
|
|
undefined</para></question>
|
|
<answer>
|
|
<para>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. </para >
|
|
|
|
</answer></qandaentry>
|
|
<qandaentry>
|
|
<question>
|
|
<para>My sound driver keeps forgetting its settings for
|
|
volume etc</para></question>
|
|
<answer>
|
|
<para>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. </para >
|
|
|
|
<para>You can tell kerneld to configure a module by
|
|
running a program after the module has been
|
|
auto-loaded. See <xref linkend="pre-post"> on the
|
|
<literal>post-install</literal> entry. </para>
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>DOSEMU needs some modules; how can I get kerneld to
|
|
load those ?</para></question>
|
|
<answer>
|
|
<para>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.</para >
|
|
|
|
</answer></qandaentry>
|
|
<qandaentry>
|
|
<question>
|
|
<para>Why do I get <errorname>Ouch, kerneld timed out,
|
|
message failed</errorname> messages ?</para></question>
|
|
<answer>
|
|
<para>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. </para >
|
|
|
|
<para>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. </para >
|
|
|
|
<para>If this happens even when the load is light, try
|
|
restarting kerneld. Kill the kerneld process, and start
|
|
it again with the command <command
|
|
>/usr/sbin/kerneld</command>. If the problem persists,
|
|
you should mail a bug report to
|
|
<email>linux-kernel@vger.rutgers.edu</email>, but
|
|
<emphasis>please</emphasis> 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
|
|
<filename>linux/Documentation/Changes</filename></para >
|
|
|
|
</answer></qandaentry>
|
|
<qandaentry>
|
|
<question>
|
|
<para>Mount doesn't wait for kerneld to load the
|
|
filesystem module</para></question>
|
|
<answer>
|
|
<para>There has been a number of reports that the mount(8)
|
|
command does not wait for kerneld to load the filesystem
|
|
module. <command>lsmod</command> 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. </para >
|
|
|
|
</answer></qandaentry>
|
|
<qandaentry>
|
|
<question>
|
|
<para>kerneld fails to load the <literal>ncpfs</literal>
|
|
module</para></question>
|
|
<answer>
|
|
<para>You need to compile the ncpfs utilities with
|
|
<token>-DHAVE_KERNELD</token>. See the
|
|
<productname>ncpfs</productname>
|
|
<filename>Makefile</filename>. </para >
|
|
|
|
</answer></qandaentry>
|
|
<qandaentry>
|
|
<question>
|
|
<para>kerneld fails to load the <filename>smbfs</filename>
|
|
module</para></question>
|
|
<answer>
|
|
<para >You are using an older version of the
|
|
<productname>smbmount</productname> utilities. Get the
|
|
latest version (0.10 or later) from <ulink
|
|
url="ftp://tsx-11.mit.edu/pub/linux/filesystems/smbfs/">the
|
|
SMBFS archive one TSX-11</ulink></para >
|
|
</answer>
|
|
</qandaentry>
|
|
<qandaentry>
|
|
<question>
|
|
<para>I built everything as modules, and now my system
|
|
cannot boot or kerneld fails to load the root filesystem
|
|
module!</para></question>
|
|
|
|
<answer>
|
|
<para>You cannot modularize
|
|
<emphasis>everything</emphasis>: 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<footnote> <para >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
|
|
<filename>linux/Documentation/initrd.txt</filename> file
|
|
that comes with the kernel source-files. </para >
|
|
</footnote>. You cannot modularize </para >
|
|
|
|
<itemizedlist>
|
|
<LISTITEM><PARA>the driver for the hard disk
|
|
where your root filesystem lives </PARA></LISTITEM>
|
|
|
|
<LISTITEM><PARA>the root filesystem driver itself
|
|
</PARA></LISTITEM>
|
|
|
|
<LISTITEM><PARA>the binary format loader for init,
|
|
kerneld and other programs </PARA></LISTITEM>
|
|
</itemizedlist>
|
|
|
|
</answer></qandaentry>
|
|
<qandaentry>
|
|
<question>
|
|
<para>kerneld will not load at boot time; it complains
|
|
about libgdbm</para></question>
|
|
<answer>
|
|
<para>Newer versions of kerneld need the GNU dbm library,
|
|
<filename>libgdbm.so</filename>, to run. Most
|
|
installations have this file in
|
|
<filename>/usr/lib</filename>, but you are probably
|
|
starting kerneld before the <filename>/usr</filename>
|
|
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 <filename>/usr</filename> is mounted, or move
|
|
the gdbm library to your root filesystem, e.g. to
|
|
<filename>/lib</filename>.</para >
|
|
</answer>
|
|
</qandaentry>
|
|
<qandaentry>
|
|
<question>
|
|
<para>I get Cannot load module <varname>xxx</varname> but
|
|
I just reconfigured my kernel without
|
|
<varname>xxx</varname> support!</para></question>
|
|
<answer>
|
|
<para>The Slackware installation (possibly others) builds
|
|
a default <filename>/etc/rc.d/rc.modules</filename> 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
|
|
<filename>rc.modules</filename> entirely and let kerneld
|
|
load the modules when they are needed.</para >
|
|
</answer>
|
|
</qandaentry>
|
|
<qandaentry>
|
|
<question>
|
|
<para>I rebuilt my kernel and modules, and still get
|
|
messages about unresolved symbols when
|
|
booting</para></question>
|
|
<answer>
|
|
<para>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
|
|
<filename>/lib/modules</filename> directory. The easiest
|
|
fix is to delete your
|
|
<filename>/lib/modules/</filename><varname>x.y.z</varname>
|
|
directory and do a <command>make modules_install</command>
|
|
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.</para>
|
|
</answer>
|
|
</qandaentry>
|
|
<qandaentry id="kernel2-1-problems">
|
|
<question><para>I installed Linux 2.1/2.3 and now I cannot
|
|
load <emphasis>any</emphasis> modules!</para></question>
|
|
<answer>
|
|
<para>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.</para >
|
|
|
|
<para>In brief, if you want to use modules with a
|
|
development kernel, you must</para >
|
|
|
|
<itemizedlist>
|
|
<LISTITEM><PARA>read the
|
|
<filename>Documentation/Changes</filename> file and see
|
|
what packages need upgrading on your system</PARA ></LISTITEM>
|
|
|
|
<LISTITEM ><PARA >use the latest modutils package,
|
|
available from <ulink
|
|
url="ftp://ftp.redhat.com/pub/alphabits/">AlphaBits on
|
|
Red Hat</ulink> or the mirror site at <ulink
|
|
url="ftp://tsx-11.mit.edu/pub/linux/packages/alphabits/">TSX-11</ulink></PARA></LISTITEM>
|
|
</itemizedlist>
|
|
|
|
<para>I recommend using at least kernel 2.1.29, if you
|
|
want to use modules with a 2.1 kernel.</para>
|
|
</answer>
|
|
</qandaentry>
|
|
<qandaentry>
|
|
<question>
|
|
<para>What about dial-on-demand networking?</para>
|
|
</question>
|
|
<answer>
|
|
<para>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
|
|
<filename>/sbin/request_route</filename> script to setup a
|
|
PPP or SLIP connection.</para >
|
|
|
|
<para>This turned out to be a bad idea. Alan Cox of Linux
|
|
networking fame wrote on the linux-kernel mailing list</para>
|
|
|
|
<blockquote>
|
|
<para>The request-route stuff is obsolete, broken and
|
|
not required [...] Its also removed from 2.1.x
|
|
trees.</para></blockquote>
|
|
|
|
<para>Instead of using the request-route script and
|
|
kerneld, I highly recommend Eric Schenk's <ulink
|
|
url="http://www.dna.lth.se/~erics/diald.html">diald
|
|
package</ulink> to manage your demand dialing.</para >
|
|
</answer>
|
|
</qandaentry>
|
|
</qandaset>
|
|
</sect1>
|
|
|
|
</article>
|
|
<!--
|
|
Local Variables:
|
|
mode:sgml
|
|
mode:auto-fill
|
|
sgml-doctype:("kerneld.sgml" "article" "chapter")
|
|
sgml-insert-missing-element-comment: nil
|
|
sgml-indent-step: 2
|
|
sgml-default-dtd-file:"kerneld.ced"
|
|
End:
|
|
-->
|