Chapter 5. Essential System Management
Chapter 4. Basic Unix Commands and Concepts
need to know grub or lilo configure file
Chapter 6. Managing Filesystems, Swap Space, and
Devices
三单元哦，不过简单。只是看看自己不清楚的了。
auto mount:
If you have compiled the autofs package yourself, it might be a good idea to start by copying
the sample configuration files that you can find in sample directory, and adapt them to your
needs. To do this, copy the files sample/auto.master and sample/auto.misc into the /etc
directory, and the file sample/rc.autofs under the name autofs wherever your distribution
stores its boot scripts. We'll assume here that you use /etc/init.d.
The first configuration file to edit is /etc/auto.master. This lists all the directories (the socalled
mount points) below which the automounter should mount partitions. Because we have
decided to use only one partition in this chapter's example, we will need to make only one
entry here. The file could look like this:
/automount /etc/auto.misc
This file consists of lines with two entries each, separated by whitespace. The first entry
specifies the mount point, and the second entry names a so-called map file that specifies how
and where to mount the devices or partitions to be automounted. You need one such map file
for each mount point.
In our case, the file /etc/auto.misc looks like the following:
cd -fstype=iso9660,ro :/dev/scd0
floppy -fstype=auto :/dev/fd0
Again, this file consists of one-line entries that each specify one particular device or partition
to be automounted. The lines have two mandatory and one optional field, separated by
whitespaces. The first value is mandatory and specifies the directory onto which the device or
partition of this entry is automounted. This value is appended to the mount point so that the
CD-ROM will be automounted onto /automount/cd.
The second value is optional and specifies flags to be used for the mount operation. These are
equivalent to those for the mount command itself, with the exception that the type is specified
with the option -fstype= instead of -t.
Finally, the third value specifies the partition or device to be mounted. In our case, we specify
the first SCSI CD-ROM drive and the first floppy drive, respectively. The colon in front of
the entry is mandatory; it separates the host part from the device/directory part, just as with
mount. Because those two devices are on a local machine, there is nothing to the left of the
colon. If we wanted to automount the directory sources from the NFS server
sourcemaster, we would specify something, such as:
sources -fstype=nfs,soft sourcemaster:/sources
After editing the configuration files to reflect your system, you can start the automount
daemon by issuing (replace the path with the path that suits your system):
tigger# /etc/init.d/autofs start
Because this command is very taciturn, you should check whether the automounter has really
started. One way to do this is to issue:
tigger# /etc/init.d/autofs status
but it is difficult to determine from the output whether the automounter is really running.
Your best bet, therefore, is to check whether the automount process exists:
tigger# ps aux | grep automount
If this command shows the automount process, everything should be all right. If it doesn't,
you need to check your configuration files again. It could also be the case that the necessary
kernel support is not available: either the automount support is not in your kernel, or you have
compiled it as a module but not installed this module. If the latter is the case, you can fix the
problem by issuing:
tigger# modprobe autofs
If that doesn't work, you need to use:
tigger# modprobe autofs4
instead.2 When your automounter works to your satisfaction, you might want to put the
modprobe call as well as the autofs call in one of your system's startup configuration files like
/etc/rc.local, /etc/init.d/boot.local, or whatever your distribution uses.
If everything is set up correctly, all you need to do is access some directory below the mount
point, and the automounter will mount the appropriate device or partition for you. For
example, if you type:
tigger$ ls /automount/cd
the automounter will automatically mount the CD-ROM so that ls can list its contents. The
only difference between normal and automounting is that with automounting you will notice a
slight delay before the output comes.
In order to conserve resources, the automounter unmounts a partition or device if it has not
been accessed for a certain amount of time (the default is five minutes).
The automounter supports a number of advanced options; for example, you do not need to
read the map table from a file but can also access system databases or even have the
automounter run a program and use this program's output as the mapping data. See the
manpages for autofs(5) and automount(8) for further details
Repairing Filesystems
It is sometimes necessary to check your Linux filesystems for consistency and repair them if
there are any errors or if you lose data. Such errors commonly result from a system crash or
loss of power, making the kernel unable to sync the filesystem buffer cache with the contents
of the disk. In most cases, such errors are relatively minor. However, if the system were to
crash while writing a large file, that file may be lost and the blocks associated with it marked
as "in use," when in fact no file entry is corresponding to them. In other cases, errors can be
caused by accidentally writing data directly to the hard-drive device (such as /dev/hda), or to
one of the partitions.
The program fsck is used to check filesystems and correct any problems. Like mkfs, fsck is a
frontend for a filesystem-type-specific fsck.type, such as fsck.ext2 for Second Extended
filesystems. (As with mkfs.ext2, fsck.ext2 is a symbolic link to e2fsck, either of which you can
execute directly if the fsck frontend is not installed.)
Use of fsck is quite simple; the format of the command is:
fsck -t type device
where type is the type of filesystem to repair, as given in Table 6-1, and device is
the device (drive partition or floppy) on which the filesystem resides.
For example, to check an ext2 filesystem on /dev/hda2, you use:
rutabaga# fsck -t ext2 /dev/hda2
Parallelizing fsck version 1.06 (7-Oct-96)
e2fsck 1.06, 7-Oct-96 for EXT2 FS 0.5b, 95/08/09
/dev/hda2 is mounted. Do you really want to continue (y/n)? y
/dev/hda2 was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts.
Pass 5: Checking group summary information.
Free blocks count wrong for group 3 (3331, counted=3396). FIXED
Free blocks count wrong for group 4 (1983, counted=2597). FIXED
Free blocks count wrong (29643, counted=30341). FIXED
Inode bitmap differences: -8280. FIXED
Free inodes count wrong for group #4 (1405, counted=1406). FIXED
Free inodes count wrong (34522, counted=34523). FIXED
/dev/hda2: ***** FILE SYSTEM WAS MODIFIED *****
/dev/hda2: ***** REBOOT LINUX *****
/dev/hda2: 13285/47808 files, 160875/191216 blocks
First of all, note that the system asks for confirmation before checking a mounted filesystem.
If any errors are found and corrected while using fsck, you'll have to reboot the system if
the filesystem is mounted. This is because the changes made by fsck may not be propagated
back to the system's internal knowledge of the filesystem layout. In general, it's not a good
idea to check mounted filesystems.
As we can see, several problems were found and corrected, and because this filesystem was
mounted, the system informed us that the machine should be rebooted.
How can you check filesystems without mounting them? With the exception of the root
filesystem, you can simply umount any filesystems before running fsck on them. The root
filesystem, however, can't be unmounted while running the system. One way to check your
root filesystem while it's unmounted is to use a boot/root floppy combination, such as the
installation floppies used by your Linux distribution. This way, the root filesystem is
contained on a floppy, the root filesystem (on your hard drive) remains unmounted, and you
can check the hard-drive root filesystem from there. See Section 8.6 in Chapter 8 for more
details about this.
Another way to check the root filesystem is to mount it as read-only. This can be done using
the option ro from the LILO boot prompt (see Section 5.2.2.3 in Chapter 5). However, other
parts of your system configuration (for example, the programs executed by /etc/init at boot
The ldd command can be used to list the shared libraries on which a given executable
depends. For example:
rutabaga% ldd /usr/bin/X11/xterm
libXft.so.1 => /usr/X11R6/lib/libXft.so.1 (0x40032000)
libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x40088000)
libXaw.so.7 => /usr/X11R6/lib/libXaw.so.7 (0x4008d000)
libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x400e4000)
libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x400fa000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40148000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40152000)
libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x4016a000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40179000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40188000)
libncurses.so.5 => /lib/libncurses.so.5 (0x4026b000)
libc.so.6 => /lib/libc.so.6 (0x402b5000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
files. An example of such a file is:
/usr/lib
/usr/local/lib
/usr/X11R6/lib
ld.so always looks in /lib and /usr/lib, regardless of the contents of ld.so.conf. Usually, there's
no reason to modify this file, and the environment variable LD_LIBRARY_PATH can add
additional directories to this search path (e.g., if you have your own private shared libraries
that shouldn't be used systemwide). However, if you do add entries to /etc/ld.so.conf or
upgrade or install additional libraries on your system, be sure to use the ldconfig command
which will regenerate the shared library cache in /etc/ld.so.cache from the ld.so search path.
This cache is used by ld.so to find libraries quickly at runtime without actually having tosearch the directories on its path. For more information, check the manual pages for ld.so and
ldconfig.
Now that you understand how shared libraries are used, let's move on to upgrading them. The
two libraries that are most commonly updated are libc (the standard C library) and libm (the
math library). Because naming is a little bit special for these, we will look at another library
here, namely libncurses, which "emulates" a graphical windowing system on the text console.
For each shared library, there are two separate files:
library.a
This is the static version of the library. When a program is statically linked, routines
are copied from this file directly into the executable, so the executable contains its
own copy of the library routines.2
library.so.version
This is the shared library image itself. When a program is dynamically linked, the stub
routines from this file are copied into the executable, allowing ld.so to locate the
shared library at runtime. When the program is executed, ld.so copies routines from
the shared library into memory for use by the program. If a program is dynamically
linked, the library.a file is not used for this library.
For the libncurses library, you'll have files, such as libncurses.a and libncurses.so.5.2. The .a
files are generally kept in /usr/lib, while .so files are kept in /lib. When you compile a
program, either the .a or the .so file is used for linking, and the compiler looks in /lib and
/usr/lib (as well as a variety of other places) by default. If you have your own libraries, you
can keep these files anywhere, and control where the linker looks with the -L option to the
compiler. See Section 13.1.7 in Chapter 13 for details.
The shared library image, library.so.version, is kept in /lib for most systemwide
libraries. Shared library images can be found in any of the directories that ld.so searches at
runtime; these include /lib, /usr/lib, and the files listed in ld.so.conf. See the ld.so manual page
for details.
If you look in /lib, you'll see a collection of files such as the following:
lrwxrwxrwx 1 root root 17 Jul 11 06:45 /lib/libncurses.so.5 \
-> libncurses.so.5.2
-rwxr-xr-x 1 root root 319472 Jul 11 06:45 /lib/libncurses.so.5.2
lrwxrwxrwx 1 root root 13 Jul 11 06:45 libz.so.1 -> libz.so.1.1.3
-rwxr-xr-x 1 root root 62606 Jul 11 06:45 libz.so.1.1.3
Here, we see the shared library images for two libraries — libncurses and libz. Note that each
image has a symbolic link to it, named library.so.major, where major is the major
version number of the library. The minor number is omitted because ld.so searches for a
library only by its major version number. When ld.so sees a program that has been compiledwith the stubs for Version 5.2 of libncurses, it looks for a file called libncurses.so.5 in its
search path. Here, /lib/libncurses.so.5 is a symbolic link to /lib/libncurses.so.5.2, the actual
version of the library we have installed.
When you upgrade a library, you must replace the .a and .so.version files corresponding to
the library. Replacing the .a file is easy: just copy over it with the new versions. However,
you must use some caution when replacing the shared library image, .so.version; many of
the text-based programs on the system depend on shared library images, so you can't simply
delete them or rename them. To put this another way, the symbolic link library.so.major
must always point to a valid library image. To accomplish this, first copy the new image file
to /lib, and then change the symbolic link to point to the new file in one step, using ln -sf. This
is demonstrated in the following example.
Let's say you're upgrading from Version 5.2 of the libncurses library to Version 5.4. You
should have the files libncurses.a and libncurses.so.5.4. First, copy the .a file to the
appropriate location, overwriting the old version:
rutabaga# cp libncurses.a /usr/lib
Now, copy the new image file to /lib (or wherever the library image should be):
rutabaga# cp libncurses.so.5.4 /lib
Now, if you use the command ls -l /lib/libncurses, you should see something like:
lrwxrwxrwx 1 root root 17 Dec 10 1999 /lib/libncurses.so.5 ->
libncurses.so.4.2
-rwxr-xr-x 1 root root 319472 May 11 2001 /lib/libncurses.so.5.2
-rwxr-xr-x 1 root root 321042 May 11 2001 /lib/libncurses.so.5.4
To update the symbolic link to point to the new library, use the command:
rutabaga# ln -sf /lib/libncurses.so.5.4 /lib/libncurses.so.5
This gives you:
lrwxrwxrwx 1 root root 14 Oct 23 13:25 libncurses.so.5 ->\
/lib/libncurses.so.5.4
-rwxr-xr-x 1 root root 623620 Oct 23 13:24 libncurses.so.5.2
-rwxr-xr-x 1 root root 720310 Nov 16 11:02 libncurses.so.5.4
Now you can safely remove the old image file, libncurses.so.5.2. You must use ln -sf to
replace the symbolic link in one step, especially when updating crucial libraries, such as libc.
If you were to remove the symbolic link first, and then attempt to use ln -s to add it again,
more than likely ln would not be able to execute because the symbolic link is gone, and as far
as ld.so is concerned, the libc library can't be found. Once the link is gone, nearly all the
programs on your system will be unable to execute. Be very careful when updating shared
library images. For libncurses, things are less critical because you will always have
command-line programs left to clean up any mess you have made, but if you are used to using
ncurses-based programs, such as Midnight Commander, this might still be an inconvenience
for you.Whenever you upgrade or add a library to the system, it's not a bad idea to run ldconfig to
regenerate the library cache used by ld.so. In some cases, a new library may not be recognized
by ld.so until you run ldconfig.
One question remains: where can you obtain the new versions of libraries? Several of the
basic system libraries (libc, libm, and so on) can be downloaded from the directory
/pub/Linux/GCC on . It contains the Linux versions of the gcc compiler,
libraries, include files, and other utilities. Each file there should have a README or release
file that describes what to do and how to install it. Other libraries are maintained and archived
separately. At any rate, all libraries you install should include the .so.version files and
possibly the .a files, as well as a set of include files for use with the compiler.
(加载module) Upgrading the Compiler
If you are applying any patch files, you use the patch program. Let's say that you have the
files patch1.gz through patch4.gz, which are gzipped. These patches should be applied from
the kernel sources main directory. That doesn't mean the patch files themselves should be
located there, but rather that patch should be executed from e.g. /usr/src/linux. For each patch
file, use the command:gunzip -c patchfile | patch -p1
from /usr/src. The -p1 option tells patch it shouldn't strip any part of the filenames contained
within the patch file except for the first one.
You must apply each patch in numerical order by patch level. This is very important. Note
that using a wildcard such as patch* will not work because the * wildcard uses ASCII order,
not numeric order. (Otherwise, if you are applying a larger number of patches, patch1 might
be followed by patch10 and patch11, as opposed to patch2 and patch3.) It is best to run the
previous command for each patch file in succession, by hand. This way you can ensure you're
doing things in the right order.
You shouldn't encounter problems when patching your source tree in this way unless you try
to apply patches out of order or apply a patch more than once. Check the patch manual page if
you do encounter trouble. If all else fails, remove the new kernel source tree and start over
from the original tar file.
To double-check that the patches were applied successfully, use the commands:
find /usr/src/linux -follow -name "*.rej" -print
find /usr/src/linux -follow -name "*#" -print
This lists any files that are "rejected" portions of the patch process. If any such files exist, they
contain sections of the patch file that could not be applied for some reason. Look into these,
and if there's any doubt, start over from scratch. You cannot expect your kernel to compile or
work correctly if the patch process did not complete successfully and without rejections.
A handy script for patching the kernel is available and can be found in scripts/patch-kernel.
But as always, you should know what you are doing before using automated tools, even more
so when it comes to the very core of the operating system, the kernel.
7.4.2 Building the Kernel
There are six steps to building the kernel, and they should be quite painless. All these steps
are described in more detail in the following pages.
1. Make sure that all the required tools and utilities are installed and at the appropriate
versions. See the file Documentation/Changes in the kernel source for the list of
requirements.
2. Run make config, which asks you various questions about which drivers you wish to
include. You could also use the more comfortable variants make menuconfig or (only
when you are running the X Window System) make xconfig.
If you have previously built a kernel and then applied patches to a new version, you
can run make oldconfig to use your old config but be prompted for any new options
that may not have been in the old kernel.
3. Run make dep to gather dependencies for each source file and include them in the
various makefiles.
4. If you have built a kernel from this source tree before, run make clean to clear out old
object files and force a complete rebuild.
5. Run make bzImage to build the kernel itself.
6. Go have a coffee (or two, depending on the speed of your machine and amount of
available memory).
7. Install the new kernel image, either on a boot floppy or via LILO. You can use make
bzDisk to put the kernel on a boot floppy.
All these commands are executed from /usr/src/linux, except for Step 5, which you can do
anywhere.
A README is included in the kernel sources, which should be located at
/usr/src/linux/README on your system. Read it. It contains up-to-date notes on kernel
compilation, which may be more current than the information presented here. Be sure to
follow the steps described there, using the descriptions given later in this section as a guide.
The first step is to run make config. This executes a script that asks you a set of yes/no
questions about which drivers to include in the kernel. There are defaults for each question,
but be careful: the defaults probably don't correspond to what you want. (When several
options are available, the default will be shown as a capital letter, as in [Y/n].) Your answers
to each question will become the default the next time you build the kernel from this source
tree.
Simply answer each question, either by pressing Enter for the default, or pressing y or n
(followed by Enter). Some questions don't have a yes/no answer; you may be asked to enter a
number or some other value. A number of the configuration questions allow an answer of m in
addition to y or n. This option allows the corresponding kernel feature to be compiled as a
loadable kernel module, as opposed to building it into the kernel image itself. Loadable
modules, covered in the following section, Section 7.5, allow portions of the kernel (such as
device drivers) to be loaded and unloaded as needed on a running system. If you are unsure
about an option, type ? at the prompt; for most options, a message will be shown that tells you
more about the option.
Some people say that make config has so many options now that it is hardly feasible to run it
by hand any longer, as you have to concentrate for a long time to press the right keys in
response to the right questions. Therefore, people are moving to the alternatives described
next.
An alternative to running make config is make xconfig, which compiles and runs an XWindow-
based kernel configuration program. In order for this to work, you must have the X
Window System running, have the appropriate X11 and Tcl/Tk libraries installed, and so
forth. Instead of asking a series of questions, the X-based configuration utility allows you to
use checkboxes to select which kernel options you want to enable. The system remembers
your configuration options each time you run make config, so if you're adding or removing
only a few features from your kernel, you need not reenter all the options.
Also available is make menuconfig, which uses the text-based curses library, providing a
similar menu-based kernel configuration if you don't have X installed. make menuconfig and
make xconfig are much more comfortable than make config, especially because you can go
back to an option and change your mind up to the point where you save your configuration.
The following is part of a session with make config. When using make menuconfig or make
xconfig, you will encounter the same options, only presented in a more user-friendly fashion
(and we actually recommend the use of these tools if at all possible, as it is very easy to get
confused by the myriad of configuration options):
rm -f include/asm
( cd include ; ln -sf asm-i386 asm)
/bin/sh scripts/Configure arch/i386/config.in
#
# Using defaults found in .config
#
*
* Code maturity level options
*
Prompt for development and/or incomplete code/drivers (CONFIG_EXPERIMENTAL) [Y/n/?]
*
* Loadable module support
*
Enable loadable module support (CONFIG_MODULES) [Y/n/?]
Set version information on all module symbols (CONFIG_MODVERSIONS) [N/y/?]
Kernel module loader (CONFIG_KMOD) [Y/n/?]
*
* Processor type and features
*
Processor family (386, 486, 586/K5/5x86/6x86/6x86MX, Pentium-Classic, ...
defined CONFIG_MPENTIUMIII
Toshiba Laptop support (CONFIG_TOSHIBA) [N/y/m/?]
/dev/cpu/microcode - Intel IA32 CPU microcode support (CONFIG_MICROCODE) [M/n/y/?]
/dev/cpu/*/msr - Model-specific register support (CONFIG_X86_MSR) [M/n/y/?]
/dev/cpu/*/cpuid - CPU information support (CONFIG_X86_CPUID) [M/n/y/?]
High Memory Support (off, 4GB, 64GB) [4GB]
defined CONFIG_HIGHMEM4G
Math emulation (CONFIG_MATH_EMULATION) [N/y/?]
MTRR (Memory Type Range Register) support (CONFIG_MTRR) [Y/n/?]
Symmetric multi-processing support (CONFIG_SMP) [Y/n/?]
*
* General setup
*
Networking support (CONFIG_NET) [Y/n/?]
...and so on...
*** End of Linux kernel configuration.
*** Check the top-level Makefile for additional configuration.
*** Next, you may run 'make bzImage', 'make bzdisk', or 'make
install'.
If you have gathered the information about your hardware when installing Linux, that
information is probably sufficient to answer the configuration questions, most of which
should be straightforward. If you don't recognize some feature, it's a specialized feature that
you don't need. The following questions are found in the kernel configuration for
Version 2.4.4. If you have applied other patches, additional questions might appear. The same
is true for later versions of the kernel. Note that in the following list we don't show all
the kernel configuration options; there are simply too many of them, and most are
self-explanatory. We have highlighted only those that may require further explanation.
Remember that if you're not sure how to answer a particular question, the default answer is
often the best choice. When in doubt, it is also a good idea to type ? and check the help
message.
It should be noted here that not all Linux device drivers are actually built into the kernel.
Instead, some drivers are available only as loadable modules, distributed separately from the
kernel sources. (As mentioned earlier, some drivers can be either built into the kernel orcompiled as modules.) One notable kernel driver available only as a module is the "floppy
tape" driver for QIC-117 tape drives that connect to the floppy controller.
If you can't find support for your favorite hardware device in the list presented by make
config, it's quite possible that the driver is available as a module or a separate kernel patch.
Scour the FTP sites and archive CD-ROMs if you can't find what you're looking for. In
the next section, Section 7.5, kernel modules are covered in detail.
Prompt for development and/or incomplete code/drivers
Answer yes for this item if you want to try new features that aren't considered stable
enough by the developers. You do not want this option unless you want to help test
new features.
Processor family (386, 486, 586/K5/5x86/6x86/6x86MX,
Pentium-Classic, Pentium-MMX, Pentium-Pro/Celeron/Pentium-II,
Pentium-III/Celeron/Coppermine, Pentium-4, K6/K6-II/K6-III,
Athlon/Duron/K7, Crusoe, Winchip-C6, Winchip-2, Winchip-
2A/Winchip-3, CyrixIII/C3) [Pentium-III/Celeron/Coppermine]
Here, you have to specify the CPU type that you have. The kernel will then be
compiled with optimizations especially geared toward your machine. Note that if you
specify a higher processor here than you actually have, the kernel might not work.
Also, the Pentium II MMX is a 686, not a 586 chip.
Math emulation
Answer no if you have a Pentium or better. Answer yes to this item if you do not have
a floating-point coprocessor in your machine. This is necessary for the kernel to
emulate the presence of a math coprocessor.
Symmetric multi-processing support
This enables kernel support for more than one CPU. If your machine has more than
one CPU, say yes here; if not, say no.
Enable loadable module support
This enables the support for dynamically loading additional modules. You definitely
want to enable this.
Set version information on all symbols for modules
This is a special option that makes it possible to use a module compiled for one kernel
version with another kernel version. A number of problems are attached to this; say no
here unless you know exactly what you are doing.Kernel module loader
If you enable this option, the kernel can automatically load and unload dynamically
loadable modules as needed.
Networking support
Answer yes to this option if you want any sort of networking support in your kernel
(including TCP/IP, SLIP, PPP, NFS, and so on).
PCI support
Enable this option if your motherboard includes the PCI bus and you have PCI-bus
devices installed in your system. The PCI BIOS is used to detect and enable PCI
devices; kernel support for it is necessary for use of any PCI devices in your system.
System V IPC
Answering yes to this option includes kernel support for System V interprocess
communication (IPC) functions, such as msgrcv and msgsnd. Some programs ported
from System V require this; you should answer yes unless you have a strong aversion
to these features.
Sysctl support
This option instructs the kernel to provide a way to change kernel parameters on-thefly,
without rebooting. It is a good idea to enable this unless you have very limited
memory and cannot tolerate the extra 8 KB that this option adds to the kernel.
Parallel port support
Enable this option if you have a parallel port in your system and want to access it from
Linux. Linux can use the parallel port not only for printers, but also for PLIP (a
networking protocol for parallel lines), ZIP drives, scanners, and other things. In most
cases, you will need an additional driver to attach a device to the parallel port.
Normal floppy disk support
Answer yes to this option unless you don't want support for floppy drives (this can
save some memory on systems where floppy support isn't required).
Enhanced IDE/MFM/RLL disk/cdrom/tape/floppy support
Answer yes to this option unless you don't need IDE/MFM/RLL drive support. After
answering yes, you will be prompted for types of devices (hard disks, CD-ROM
drives, tape drives, and floppy drives) you want to access over the IDE driver. If you
have no IDE hardware (only SCSI), it may be safe to disable this option.
XT harddisk support
Answer yes to this only if you have an older XT disk controller and plan to use it with
your Linux system.
Parallel port IDE device support
This option enables support for IDE devices that are attached to the parallel port, such
as portable CD-ROM drives.
Networking options
If you previously selected networking support, you will be asked a series of questions
about which networking options you want enabled in your kernel. Unless you have
special networking needs (in which case you'll know how to answer the questions
appropriately), answering the defaults for these questions should suffice. A number of
the questions are esoteric in nature (such as IP: Disable Path MTU
Discovery) and you should select the defaults for these in almost all cases.
SCSI support
If you have a SCSI controller of any kind, answer yes to this option. You will be asked
a series of questions about the specific SCSI devices on your system; be sure you
know what type of hardware you have installed. All these questions deal with specific
SCSI controller chips and boards; if you aren't sure what sort of SCSI controller you
have, check the hardware documentation or consult the Linux HOWTO documents.
You will also be asked if you want support for SCSI disks, tapes, CD-ROMs, and
other devices; be sure to enable the options appropriate for your hardware.
If you don't have any SCSI hardware, you should answer no to this option; it greatly
reduces the size of your kernel.
Network device support
This is a series of questions about the specific networking controllers Linux supports.
If you plan to use an Ethernet card (or some other networking controller), be sure to
enable the options for your hardware. As with SCSI devices, you should consult your
hardware documentation or the Linux HOWTO documents (such as the Ethernet
HOWTO) to determine which driver is appropriate for your network controller.
Amateur Radio support
This option enables basic support for networking over public radio frequencies. If you
have the equipment to use the feature, enable this option and read the AX25 and the
HAM HOWTO.
ISDN subsystem
If you have ISDN hardware in your system, enable this option and select the ISDN
hardware driver suitable for your hardware. You will most probably also want to
select Support synchronous PPP (see Section 15.3 in Chapter 15).
Old CD-ROM drivers
This is a series of questions dealing with the specific CD-ROM drivers supported by
the kernel, such as the Sony CDU31A/33A, Mitsumi, or SoundBlaster Pro CD-ROM,
and so on. If you have a SCSI or IDE CD-ROM controller (and have selected support
for it earlier), you need not enable any of these options. Some CD-ROM drives have
their own interface boards, and these options enable drivers for them.
Character devices
Linux supports a number of special "character" devices, such as serial and parallel port
controllers, QIC-02 tape drives, and mice with their own proprietary interfaces (not
mice that connect to the serial port, such as the Microsoft serial mouse). This section
also includes the joystick support and the "Video for Linux" drivers that support video
and frame-grabbing hardware. Be sure to enable the options corresponding to your
hardware.
Filesystems
This is a series of questions for each filesystem type supported by the kernel. As
discussed in the section Section 6.1, a number of filesystem types are supported by the
system, and you can pick and choose which to include in the kernel. Nearly all
systems should include support for the Second Extended and /proc filesystems. You
should include support for the MS-DOS filesystem if you want to access your MSDOS
files directly from Linux, and the ISO 9660 filesystem to access files on a CDROM
(most of which are encoded in this way).
Console drivers
Make sure you select at least VGA text console in this section, or you won't be
able to use your Linux system from the console.
Sound card support
Answering yes to this option presents you with several questions about your sound
card, which drivers you wish to have installed, and other details, such as the IRQ and
address of the sound hardware.
Kernel hacking
This section contains options that are useful only if you plan on hacking the Linux
kernel yourself. If you do not want to do this, answer no.
After running make config or its equivalent, you'll be asked to edit "the top-level Makefile,"
which means /usr/src/linux/Makefile. In most cases, it's not necessary to do this. If you
wanted to alter some of the compilation options for the kernel, or change the default root
device or SVGA mode, you could edit the makefile to accomplish this. Setting the root device
and SVGA mode can easily be done by running rdev on a compiled kernel image, as we saw
in Section 5.2.1 in Chapter 5.
If you wish to force a complete recompilation of the kernel, you should issue make clean at
this point. This removes from this source tree all object files produced from a previous build.
If you have never built the kernel from this tree, you're probably safe skipping this step
(although it can't hurt to perform it). If you are tweaking minor parts of the kernel, you might
want to avoid this step so that only those files that have changed will be recompiled. At any
rate, running make clean simply ensures the entire kernel will be recompiled "from scratch,"
and if you're in any doubt, use this command to be on the safe side.
Now you're ready to compile the kernel. This is done with the command make bzImage. It is
best to build your kernel on a lightly loaded system, with most of your memory free for the
compilation. If other users are accessing the system, or if you're trying to run any large
applications yourself (such as the X Window System, or another compilation), the build may
slow to a crawl. The key here is memory. If a system is low on memory and starts swapping,
it will be slow no matter how fast the processor is.
The kernel compilation can take anywhere from a few minutes to many hours, depending on
your hardware. There is a great deal of code — well over 10 MB — in the entire kernel, so
this should come as no surprise. Slower systems with 4 MB (or less) of RAM can expect to
take several hours for a complete rebuild; faster machines with more memory can complete it
in less than half an hour. Your mileage will most assuredly vary.
If any errors or warnings occur while compiling, you cannot expect the resulting kernel to
work correctly; in most cases, the build will halt if an error occurs. Such errors can be the
result of incorrectly applying patches, problems with the make config step, or actual bugs in
the code. In the "stock" kernels, this latter case is rare, but is more common if you're working
with development code or new drivers under testing. If you have any doubt, remove the kernel
source tree altogether and start over.
When the compilation is complete, you will be left with the file bzImage in the directory
/usr/src/linux/arch/i386/boot. (Of course, if you're attempting to build Linux on a platform
other than the Intel x86, the kernel image will be found in the corresponding subdirectory
under arch.) The kernel is so named because it is the executable image of the kernel, and it
has been internally compressed using the bzip2 algorithm. When the kernel boots, it
uncompresses itself into memory: don't attempt to use bzip2 or bunzip2 on bzImage yourself!
The kernel requires much less disk space when compressed in this way, allowing kernel
images to fit on a floppy. Earlier kernels supported both the gzip and the bzip2 compression
algorithms, the former resulting in a file called zImage. Because bzImage gives better
compression results, however, gzip should not be used, as the resulting kernels are usually too
big to be installed these days.
If you pick too much kernel functionality, you can get a kernel too big error at the end
of the kernel compilation. This happens rarely because you need only a very limited amount
of hardware support for one machine, but it can happen. In this case, there is one way out:
compile some kernel functionality as modules (see Section 7.5).
You should now run rdev on the new kernel image to verify that the root filesystem device,
console SVGA mode, and other parameters have been set correctly. This is described in
Section 5.2.1 in Chapter 5.
With your new kernel in hand, you're ready to configure it for booting. This involves either
placing the kernel image on a boot floppy, or configuring LILO to boot the kernel from the
hard drive. These topics are discussed in Section 5.2 in Chapter 5. To use the new kernel,
configure it for booting in one of these ways, and reboot the system.
A warning: you should always keep a known good kernel available for booting. Either keep a
previous backup kernel selectable from LILO or test new kernels using a floppy first. This
will save you if you make a mistake such as omitting a crucial driver in your new kernel,
making your system not bootable.
7.5 Loadable Device Drivers
Traditionally, device drivers have been included as part of the kernel. There are several
reasons for this. First of all, nearly all device drivers require the special hardware access
provided by being part of the kernel code. Such hardware access can't be obtained easily
through a user program. Also, device drivers are much easier to implement as part of the
kernel; such drivers would have complete access to the data structures and other routines in
the kernel and could call them freely.
A conglomerate kernel containing all drivers in this manner presents several problems. First
of all, it requires the system administrator to rebuild the kernel in order to selectively include
device drivers, as we saw in the previous section. Also, this mechanism lends itself to sloppy
programming on the part of the driver writers: there's nothing stopping a programmer from
writing code that is not completely modular — code which, for example, directly accesses
data private to other parts of the kernel. The cooperative nature of the Linux kernel
development compounds this problem, and not all parts of the code are as neatly contained as
they should be. This can make it more difficult to maintain and debug the code.
In an effort to move away from this paradigm, the Linux kernel supports loadable device
drivers — device drivers that are added to or removed from memory at runtime, with a series
of commands. Such drivers are still part of the kernel, but they are compiled separately and
enabled only when loaded. Loadable device drivers, or modules, are generally loaded into
memory using commands in one of the boot-time rc scripts.
Modules provide a cleaner interface for writing drivers. To some extent, they require the code
to be somewhat modular and to follow a certain coding convention. (Note that this doesn't
actually prevent a programmer from abusing the convention and writing nonmodular code.
Once the module has been loaded, it is just as free to wreak havoc as if it were compiled
directly into the kernel.) Using modules makes drivers easier to debug; you can simply unload
a module, recompile it, and reload it without having to reboot the system or rebuild the kernel
as a whole. Modules can be used for other parts of the kernel, such as filesystem types, in
addition to device drivers.
Most device drivers, and a lot of other kernel functionality under Linux, are implemented as
modules. One of them is the floppy tape driver (or ftape driver), for tape drives that connect to
the floppy controller, such as the Colorado Memory Jumbo 120/250 models. If you plan to
use this driver on your system, it is good to know how to build, load, and unload modules.
While nobody stops you from compiling this module statically into your kernel, a tape drive is
something that you need only rarely (normally once a day or so), and its driver shouldn't
occupy valuable RAM during the times it is not needed. See the Linux ftape HOWTO for
more about these devices and supported hardware.
The first thing you'll need is the modules package, which contains the commands used to load
and unload modules from the kernel. On the FTP archive sites, this is usually found as
modules.tar.gz in the directory where the kernel sources are kept. This package contains the
sources to the commands insmod, modprobe, rmmod, and lsmod. Most Linux distributions
include these commands (found in sbin). If you already have these commands installed, you
probably don't need to get the modules package. However, it can't hurt to get the package and
rebuild these commands, to be sure that you have the most up-to-date version.
To rebuild these commands, unpack modules.tar.gz (say, in a subdirectory of /usr/src). Follow
the installation instructions contained there; usually all you have to do is execute make
followed by make install (as root). The three commands will now be installed in /sbin and
will be ready to use.
A module is simply a single object file containing all the code for the driver. For example, the
ftape module might be called ftape.o. On many systems, the modules themselves are stored in
a directory tree below /lib/modules/kernelversion, where you can find different
directories for the various types of modules. For example, the modules compiled for the 2.4.4
kernel would be below /lib/modules/2.4.4. You might already have a number of modules on
your system; check the appropriate directory.
Modules can be either in the kernel sources or external to it. The former is the case for those
device drivers, filesystems, and other functionality that are used most often and are
maintained as part of the official kernel sources. Using these modules is very easy: during the
make config, make menuconfig, or make xconfig step, type m to build a feature as a module.
Repeat this for everything you want to compile as a module. Then, after the make bzImage
step, execute the commands make modules and make modules_install. This will compile the
modules and install them in /lib/modules/kernelversion. It is a good idea (for reasons to
be explained later in this section) to run the command depmod -a afterward to correct module
dependencies.
New modules that are not yet integrated into the official kernel sources, or those that are
simply too esoteric to be put into the kernel sources (e.g., a device driver for some custombuilt
hardware that is not publicly available) can be available as stand-alone, external
modules. Unpack the archive of this module, compile it according to the instructions that are
hopefully included, and copy the resulting module file to the appropriate subdirectory of
/lib/modules/kernelversion. Some modules might have an install script, or allow you to
issue the command make install to perform the last step.
Once you have a compiled module (either from the kernel sources or external), you can load it
using the command:
insmod module
where module is the name of the module object file. For example:
insmod /lib/modules/2.4.4/kernel/drivers/char/ftape/lowlevel/ftape.o
installs the ftape driver if it is found in that file.
Once a module is installed, it may display some information to the console (as well as to the
system logs), indicating that it is initialized. For example, the ftape driver might display the
following:
ftape v1.14 29/10/94 (c) 1993, 1994 Bas Laarhoven ()
QIC-117 driver for QIC-40 and QIC-80 tape drives
[000] kernel-interface.c (init_module) - installing QIC-117 ftape\
driver....
[001] kernel-interface.c (init_module) - 3 tape_buffers @ 001B8000.
[002] calibr.c (time_inb) - inb( ) duration: 1436 nsec.
[003] calibr.c (calibrate) - TC for 'udelay( )' = 2944 nsec (at 2049\
counts).
[004] calibr.c (calibrate) - TC for 'fdc_wait( )' = 2857 nsec (at 2049\
counts).
The exact messages printed depend on the module, of course. Each module should come with
ample documentation describing just what it does and how to debug it if there are problems.
It is likely that insmod will tell you it could not load the module into the kernel because there
were "symbols missing." This means that the module you want to load needs functionality
from another part of the kernel that is neither compiled into the kernel nor contained in a
module already loaded. You could now try to find out which module contains those functions,
load that module first with insmod, and try again. You will eventually succeed with this
method, but it can be cumbersome, and this would not be Linux if there weren't a better way.
You first need a module database in the file /lib/modules/kernelversion/modules.dep.
You can create this database by calling:
depmod -a
This goes through all the modules you have and records whether they need any other
modules. With this database in place, you can simply replace the insmod command with the
modprobe command, which checks the module database and loads any other modules that
might be needed before loading the requested module. For example, our modules.dep file
contains — among others — the following line:
/lib/modules/2.4.4/kernel/drivers/isdn/hisax/hisax.o: /lib/modules/2.4.4/
kernel/drivers/isdn/isdn.o
This means that in order to load the hisax module (a device driver for a number of ISDN
boards), the isdn module must be loaded. If we now load the hisax module with modprobe
(this example is slightly simplified because the hisax module needs additional parameters):
modprobe hisax
modprobe will detect the dependency and load the isdn module. If you have compiled a
module for the current kernel, you first need to run depmod -a, though, so that modprobe can
find it.
Some modules need so-called module parameters. For example, a device driver might need to
be assigned an IRQ. You can pass those parameters in the form
parameter_name=parameter_value with both the insmod and the modprobe
command. In the following example, several parameters are passed to the hisax module:
tigger # modprobe hisax type=3 protocol=2 io=0x280 irq=10
The documentation for each module should tell you which parameters the module supports. If
you are too lazy to read the documentation, a nifty tool you can use is modinfo which tells you
— among other things — which parameters the module specified as the argument accepts.
One caveat about modules if you use the Debian distribution: Debian uses a file called
/etc/modules that lists the modules that should be loaded at boot time. If a module that you do
not want keeps reappearing, check whether it is listed here.
You can list the drivers that are loaded with the command lsmod, as in:
rutabaga% lsmod
Module: #pages: Used by
ftape 40
The memory usage of the module is displayed as well; under Linux on an Intel x86 system, a
page is 4 KB. The ftape driver here is using 160 KB of memory. If any other modules are
dependent on this module, they are shown in the third column.
A module can be unloaded from memory using the rmmod command, as long as it is not in
use. For example:
rmmod ftape
The argument to rmmod is the name of the driver as it appears in the lsmod listing.
Once you have modules working to your satisfaction, you can include the appropriate insmod
commands in one of the rc scripts executed at boot time. One of your rc scripts might already
include a place where insmod commands can be added, depending on your distribution.
One feature of the current module support is that you must rebuild a module any time you
upgrade your kernel to a new version or patch level. (Rebuilding your kernel while keeping
the same kernel version doesn't require you to do this.) This is done to ensure that the module
is compatible with the kernel version you're using. If you attempt to load a module with a
kernel that is newer or older than that for which it was compiled, insmod will complain and
not allow the module to be loaded. When rebuilding a module, you must be running the kernel
under which it will be used. Therefore, when upgrading your kernel, upgrade and reboot the
new kernel first, then rebuild your modules and load them. There is an option that allows you
to keep your modules when switching kernels, but a number of problems are associated with
it, and we recommend against using it.
7.6 Loading Modules Automatically
The automatic loading of modules is an especially useful feature which is implemented by a
kernel component called kmod. With the help of kmod, the kernel can load needed device
drivers and other modules automatically and without manual intervention from the system
administrator. If the modules are not needed after 60 seconds, they are automatically unloaded
as well.
In order to use kmod, you need to turn on support for it (Kernel module loader) during
kernel configuration in the Loadable module support section.
Modules that need other modules must be correctly listed in
/lib/modules/kernelversion/modules.dep, and there must be aliases for the major and
minor number in /etc/conf.modules. See the documentation from the modules package for
further information.
If a module has not been loaded manually with insmod or modprobe, but was loaded
automatically by the kernel, the module is listed with the addition (autoclean) in the
lsmod output. This tells you that the kernel will remove the module if it has not been used for
more than one minute.
We have gone through quite a lot of material now, and you should have all the tools you'll
need to build and maintain your own kernels.
