Managing the state-of-the-art Linux kernel
The kernel is the heart and soul of your operating system. It manages the memory, CPU, and disks; every piece of hardware in your system needs it to function. The Linux kernel is one of the most flexible and customizable in existence, and managing it is fairly straightforward, but can be tricky at times.
In virtually every flavor of UNIX, it is possible to configure the kernel to some extent. Usually this is done by specifying a set of external, loadable modules to insert into the kernel at boot-time. With Linux, you can do this and much more. In addition to being able to insert code modules manually at bootup, Linux can also load modules on-demand and later unload them.
On top of all that, you can, since the code for the Linux kernels is freely available, compile your own custom kernel. This includes specifying which drivers and features you wish to compile directly into the kernel and which you wish to leave as loadable modules.
The Linux developers have worked hard to make this as painless as possible, so this flexibility has not cost as much in ease of use as you might have expected. The kernel has two menu-driven configuration options: one X-based and the other screen-based. Additionally, there is the simple line-based, linear configuration.
If you are familiar with Linux, you probably already know that at any given time, there are two current kernel versions: a production version and a developmental version. The developmental (sometimes called experimental) kernels typically have experimental and sometimes buggy or unstable features, though it should be noted that a truly buggy release of either a production or developmental kernel will be fixed very quickly with a new release.
Production kernels always have an even minor release number, while development kernels have odd minor releases. The minor release number is the second of the three numbers that make up the kernel version number. For example, 2.1.121 is a development kernel, and 2.2.3 is a production kernel. The next minor revision up from a production kernel is developed in parallel with the production kernel.
In general, unless you need a feature available only in a developmental kernel, it is usually best to stick with a recent production kernel.
Since Red Hat includes most kernel options as modules, it is very easy to include support for one device or another by loading in the module, or by letting kmod do it for you. There are, however, a few features that cannot be included as modules such as APM support. In these cases, you'll need to recompile the kernel.
There are a few things you will need or want to have handy while you are rolling out a new kernel. The manuals for your peripherals and your motherboard are good starting points. You will at least need to know the model number of your various peripherals and, in some cases, some hardware settings like interrupt request lines (IRQs) and memory addresses.
You will also want to make a copy of your existing kernel and set up LILO, so you are able to boot in case your new kernel has something wrong with it or simply won't boot.
Also, you will want to have a bootable floppy (which you should have already) in case things really go awry. If you need to make a boot floppy, see the chapter on bootup and shutdown. Also, if you are a little paranoid, you might want to back up your root partition.
As mentioned above, it is good practice to keep an old, reliable kernel around that you can boot up in a pinch. LILO is the utility that allows you to choose which kernel to boot at startup. With LILO, you can also boot 386BSD, DOS, Windows 98, UNIXware, and most other operating systems.
LILO uses a configuration file, lilo.conf, located in /etc. Here is an example of one:
# # LILO config file: /etc/lilo.conf # boot=/dev/hda1 map=/boot/map install=/boot/boot.b verbose=2 prompt timeout=100 message=/boot/message image=/vmlinuz label=apm root=/dev/hda1 read-only image=/boot/vmlinuz label=linux root=/dev/hda1 read-only
The first line simply tells LILO what partition contains the boot sector, or if a device is specified (i.e., /dev/hda instead of /dev/hda1), which device contains the MBR (Master Boot Record). Next, the map file is specified (/boot/map is the default); it tells LILO where all the files are that it needs to boot an OS. Third is the boot loader. It is loaded into the BIOS and subsequently loads the selected kernel. Next is the verbosity level—higher is more verbose. The prompt entry tells LILO to present a prompt to allow you to choose which kernel to boot. The timeout is how long LILO will wait in tenths of a second before booting the default kernel. If no timeout line is present, LILO will wait indefinitely. In either case, simply pressing ENTER at the prompt boots the default kernel. The next line specifies the message file that contains text to be displayed before the LILO prompt.
The next three sections tell LILO about the specific kernels you want to boot. As expected, the first entry is the default one. In this case (as is typical), it points to where the kernel is installed by default: /vmlinuz. The label sub-entry is the text that is given at the LILO: prompt to boot this kernel, apm in this case. This represents a kernel recompiled to take advantage of APM support. The root line specifies the partition containing the root directory for the OS or kernel. The read-only line tells Linux to mount the root partition read only, so that fsck can be run at boot-time. The fsck program cannot run on a partition that is mounted read-write.
Subsequent entries specify additional Linux kernels, each with their own, unique label, but otherwise the same as the first. A good portion of the time, this is all you will need to know about LILO, especially if you bought your Linux system already configured. However, you may also still want to use DOS and MS Windows or Windows 98 (for games, etc.). Adding entries into your /etc/lilo.conf for other OSes is fairly straightforward. Here is an example of an entry to boot MS DOS from a different partition:
other=/dev/hda5
label = dos
table = /dev/hda
loader = /boot/chain.b
There are two new parameters here: table and loader. The first specifies the location of the partition table for the foreign OS and the second what chain loader to use to boot up the OS's kernel.
The most important thing to remember with regard to LILO is to run /sbin/lilo after changing anything to do with LILO (editing any of the files associated with it, updating a kernel with an existing lilo.conf entry, and so forth). Failure to do so could potentially prevent your machine from booting.
One thing to note here is that not all drivers behave the same as a module does when compiled into the kernel. This can range from slight differences in functionality to their simply not working at all.
The choice of when to make a particular feature available as a module or to compile it is usually fairly straightforward. In general, if it is infrequently used and performs as needed as a module, you should compile it as a module. This often includes things like floppy disk drivers (in this day of networking, how often do you really use the thing anyhow?), drivers for other filesystem types, CD-ROM drivers, drivers for sound cards, and networking drivers on a machine that uses dial-in PPP for its access.
If a feature is used frequently or continually, then there really isn't much point in compiling it as a module since it will be loaded all the time anyhow. This includes items such as your hard disk controller or SCSI controller, network drivers on a machine permanently networked, AppleTalk drivers on a fileserver for your Mac network, and so forth.
In cases where functionality between the compiled version and module version differs, it is usually noted in the help pop-up for that option and in any related HOWTOs.
It should be noted that these are, for the most part, just guidelines. Ultimately, you need to compile in your kernel only what you need to boot your machine.
Let's go through and outline how you might roll a kernel for a networked Linux machine you are using as your desktop machine and a file server for a network of Windows and Mac machines. You also have a sound card (they're cheap and you have a hundred CDs at home you could also listen to at work). The machine has a SCSI controller with a CD-ROM and hard drives attached to it.
First, make sure you have the kernel sources installed. Even if you do, you may decide you want to get more recent versions. The default location is in /usr/src/linux (linux may be a link to linux-x.y.z, where x.y.z is a kernel revision). Once you make your way into /usr/src/linux, type make xconfig (assuming you are in X, which is highly recommended). This will do some preliminary work and then bring up a window with buttons that take you to various sections of the kernel configuration.
As you may have guessed, the first time through it is best to start at the top and go through all the menus.
To the right of each button is a help button that gives a small amount of information on the driver and some hints to help you decide if you want to enable it or not.
If you are in X, run make
xconfig from /usr/src/linux. If you are using a character terminal, run make menuconfig. And, if you are using a character terminal with poor emulation, you are stuck running make config.
When you run make with the xconfig option, a nice GUI pops up as seen in Figure 17-1.
Once you go into a submenu, you can get help on the various options there. See Figures 17-2 and 17-3 for examples.
Now you are ready to start configuring your new kernel.
Answering Yes to the one option here will not change the kernel. It will simply give you options later on for various experimental or incomplete drivers. Say Yes; it doesn't hurt anything. You can always say No to any experimental drivers you are offered.
Some experimental modules available in the current 2.2 kernels include enhanced support for some IDE controller chipsets, IPv6, Ethernet bridging, write support for UFS and NTFS filesystem types, CODA (a next-generation network filesystem), and support for numerous pieces of less common hardware.
Set the processor type appropriately, unless you have an old version of GCC for some reason. In that case, you will have to say 386 or 486. If you have mulitple CPUs, enable SMP as well. If you have a Pentium Pro or Pentium II/III and are using the machine as a workstation, i.e., you will be running X windows, enable MTRR as it should improve video performance.
As you might guess, we highly recommend that you enable the use of loadable modules and kernel daemon support. Under the 2.0 series of kernels, the kernel daemon, kerneld, is the program that manages the loading and unloading of modules. It is available separately from the kernel distribution, but ships with Red Hat. Under Linux 2.2 (Red Hat 6.0 and later), kernel modules are loaded and unloaded by the kernel itself, using the kmod facility. If you are using a 2.2 kernel, you should therefore enable the kernel module loader option as well.
While kmod is not as flexible as kerneld, it removes a step in the locating and loading of a module. Since the kernel never used any of the other features of kerneld, the replacement was made.
Both kerneld and kmod call modprobe to load a module, as well as modules it may depend on. Often it is desirable to tune modprobe's behavior. This is done in its configuration file, /etc/conf.modules. Those that find this name backwards can move it to /etc/modules.conf, which modprobe also knows to check.
This file has several types of entries, but two are the most common: alias and options.
An alias line does pretty much what one would expect. It assigns an alias name to a real module name. This can also be used to turn a module off. Options lines set up options for use with specified modules. Examples are things like i/o memory addresses of peripherals and IRQ settings.
One module that almost always requires an options entry in /etc/conf.modules is the sound module. For example, the entries for a Crystal CS423x on-board sound chipset would look something like this:
alias sound cs4232 alias midi opl3 options opl3 io=0x388 options cs4232 io=0x534 irq=5 dma=1 dma2=0
Options lines can use a real module name or an alias. The main benefit of alias entries is to make it easier to use modules in general. It is easier to remember that your sound card support can be referenced by sound instead of the module named after the chipset.
To turn a module off, use an entry like this:
alias net-pf-4 off
This turns off the IPX module and also prevents the display of warning messages about it being missing should an attempt to load it be made if it isn't present.
For more details about kmod and modules in general, read the man page on modprobe and the kernel documentation on modules, typically found at /usr/src/linux/Documentation/modules.txt.
We don't recommend that you enable version information on loadable modules, but rather that you reinstall modules each time you install a new kernel.
When compiling the kernel, it is generally better to enable more options as modules than not compile them or build them into the kernel. Since modules do not take up any memory or CPU space when not in use, they allow you to have more options available for when you need them. Also, modules allow you to change options when you change cards. Installing a new sound card no longer requires recompiling the kernel; you just change the options in /etc/conf.modules.
You will definitely want to enable networking support and System V IPC. Unless you have a very old system without a PCI bus, enable PCI support as well. You should also enable a.out, probably as a module, since nearly every executable binary is in ELF format. Choose either support for ELF or MISC. Select MISC if you want to be able to run other binary formats via a wrapper. This includes things like Python, Java, LISP, or even DOS programs via DOSEMU. You should also read binfmt_mic.txt and java.txt in the Documentation/ directory for more detailed instructions on using this feature. Most people, however, will be fine with just ELF support and running their Python scripts the old-fashioned way.
Enable floppy disk support, probably as a module, unless you use the floppy drive a lot. Leave out (E)IDE support if you are sure you do not need it, i.e., you have a SCSI-only system.
The various chipset support options and bug fixes can be left off unless you have an older motherboard, particularly one that uses Intel's Neptune chipset.
For the rest of the options, it should be obvious if you need them or not. Enable as you see fit.
There are several options you will definitely want here—namely, TCP/IP networking, UNIX domain sockets, and packet sockets.
Most of the rest of the IP and network-related options you will not need unless your machine is acting as a TCP/IP router/gateway or firewall. You might need to enable multicasting if you are going to be accessing the MBONE (the multicast backbone, which sits on top of the Internet). If you enable routing, you will be presented with options for routing strategies in the QoS and/or Fair Queuing menu.
Further down you will find support for other networking protocols: IPX, AppleTalk, and AX.25. Enable these if you need them. If your machine is going to be a server using one of these protocols, you might as well compile it into the kernel. It will likely end up being loaded nearly all of the time anyhow.
You can also enable support for IPv6. IPv6 is the next generation IP protocol. Its most compelling features are a vastly expanded address space (128 bits instead of 32), authentication, and privacy. Most Internet providers do not support IPv6 yet, but Linux will be ready when they do.
Assuming we have beaten the dead horse enough, you will need at least SCSI support and SCSI disk support for your SCSI-based machine. You might also need SCSI tape and CD-ROM support as well. If you have other SCSI devices, like a scanner, you will also need to enable generic SCSI support. Unless you have a device with multiple logical unit numbers, you should say No to the option for probing all logical unit numbers (LUNs). An example of such a device is a CD jukebox.
If you are having problems with your SCSI bus, you may want to enable verbose error reporting to help track the errors.
Enable the driver(s) for your SCSI adapters. If you are using a built-in ZIP or JAZ drive on your controller, you will need to enable its driver. See the chapter on peripherals for more information.
If you are using a ZIP drive on the parallel port, you will need to enable support for it here, too. This type of drive contains a parallel-to-SCSI converter that essentially turns the port into a SCSI host.
Enable network device support (duh). After that, enable other options as you need them. In most cases, your choice should be clear. Further down in this pop-up is a list of Ethernet cards. Once again, the correct choice should be obvious, assuming you know what kind of card is in your system. Enable more than one if you have multiple cards.
These two menus control support for amateur (HAM or AX25) radio and infrared ports. Infrared ports are commonly found on laptops and PDAs.
Amatuer radio users should consult the HAM HOWTO or the AX25 HOWTO and http://www.tapr.org/tapr/html/pkthome.html.
More documentation on IR support can be found in the IR HOWTO.
Enable this if you need it. You will likely have to contact your service provider to find out if they support synchronous PPP and compression. Enable the driver for your ISDN adapter as well. Enable the remaining options as needed.
Hopefully you will not need this. But if your CD-ROM interface is not ATAPI-(IDE) or SCSI-based, you will require this. In many cases, older sound cards or proprietary CD-ROM interfaces will require this setup. This should only be the case on older systems, however.
You will almost definitely want to have virtual terminal support, unless you plan to only use the machine from the network and/or serial port. It is also likely that you will want standard serial port support, though you can leave it out if you have a bus mouse and no modem.
Intelligent multiport serial card support is also set here. If you have a dumb serial port card (based on the 16550 or similar), it is enabled as part of the standard serial port support.
Further down are options for Unix98 pty support, which you should always have enabled; parallel printer support, which you should enable also if you have a parallel port ZIP drive; non-serial, i.e., bus, mice; non-SCSI tape drives; speech cards; and various devices related to timing.
If you said Yes to bus mice, you will be given a list of drivers to choose from in the Mice menu. Similarly, if you enabled watchdog timer support, a list of drivers for watchdog cards will appear.
This supports video and audio capture devices and FM tuners. User programs for accessing the devices can be found at ftp://ftp.uk.linux.org/pub/linux/video4linux.
Here is another pair of fairly self-explanatory devices, at least if you've been using PCs for awhile. Enable and select the appropriate driver if you have this hardware. The joystick driver is recommended if you're going to play games, and Ftape is needed for some of the older 250MB tape systems. We don't recommend using these tapes for most systems due to the low capacity and slow speed. Most newer tape backup systems use either SCSI or ATAPI and have higher capacities and higher backup and restore rates.
If your machine is used for shell access, you may want to enable quota support. Quota support will also work with AppleTalk users since they are "real" users and have /etc/passwd entries. Depending on how Samba or IPX is set up, it may be useful to enable quota for their users as well.
Leave mandatory lock support off unless you know you'll need it or you have newer AppleTalk, NFS, and/or Samba daemons.
Enable the second extended filesystem support. This is Linux's native filesystem type. It will likely be safe to leave Minix, the first extended filesystem, and xiafs off as they are older and not needed in newer Linux systems.
It may be useful to enable the DOS- and Windows-related filesystem types since these machines are so ubiquitous. Enable them as modules unless you use them frequently.
Enable /proc. It's needed by several programs. You really should not even be given the option to turn it off.
You will know whether or not you need the rest of the options; enable them as necessary. In particular, you will want to include CD-ROM (ISO9660) filesystem support.
If you have a very heterogeneous LAN, you may want to enable virtually all of these for use with removable media (floppy, ZIP or JAZ drives).
If you enabled support for Microsoft filesystems, you can also enable support for internationalization and foreign language character sets here.
If you use the console of the machine and have a sound card, you will want to enable support for it here. You will definitely need the manual for your sound card, as there are a number of hardware parameters you need to compile into the kernel.
There are a large number of combinations of hardware and parameters—too many to try to cover here. If you are careful and keep your card's manual handy, you should not have any serious trouble getting your card fully supported (at least as far as the current drivers will allow) under Linux. Some manuals can be a little sparse, and you may have to fiddle with the settings to get your card working.
Depending on the driver you enable on the Sound menu, you will be given options for additional drivers in the Low Level Sound Drivers menu.
To properly build the kernel the first time, issue the following commands:
Now, to install the compressed kernel in the root partition, type:
# make zlilo <output ending in...> tools/build bootsect setup compressed/vmlinux.out CURRENT > zImage Root device is (8, 1) Boot sector 512 bytes. Setup is 4348 bytes. System is 368 kB sync if [ -f /vmlinuz ]; then mv /vmlinuz /vmlinuz.old; fi if [ -f /System.map ]; then mv /System.map /System.old; fi cat zImage > /vmlinuz cp /usr/src/linux/System.map / if [ -x /sbin/lilo ]; then /sbin/lilo; else /etc/lilo/install; fi Added l * Added l2 Added l3 make [1]: Leaving directory `/usr/src/linux-2.0.36/arch/i386/boot'
If you enable any drivers as modules, you must build and install them as follows:
# make modueles <a few bucketloads of output> # make modules_install Installing modules under /lib/modules/2.0.36/block Installing modules under /lib/modules/2.0.36/net Installing modules under /lib/modules/2.0.36/ipv4 Installing modules under /lib/modules/2.0.36/fs <or something similar>
This last command installs the kernel and reruns LILO to update the boot map. To install it on a floppy instead, run makezImage (instead of zlilo) and then copy the image to a high-density floppy.
# cp /usr/src/linux/arch/i386/boot/zImage /dev/fd0
Reboot your machine with your new kernel like this:
# /sbin/reboot
If the new kernel doesn't boot, you can reboot again (using the familiar CONTROL-ALT-DELETE) and at the LILO: prompt, enter another kernel to boot. As you can see from the output above, there are three kernels installed in /etc/lilo.conf. If you type l2 at the prompt, the kernel corresponding to the l2 label will be booted. Recheck your hardware and the drivers you have enabled and recompile if you need to. It is also possible that the particular kernel revision simply doesn't work on your system.
Hopefully, we have managed to take some of the intimidation out of the process of compiling your own kernel. On the other hand, we also want to be sure that you take a few simple precautions in case you make a kernel that won't boot up on your system.
If you are interested in the inner workings of the kernel, you can consult various HOWTOs, in particular the Kernel Hacking HOWTO for Linux-specific information, or any of a number of books on general OS theory and design.
For more detailed information on booting and LILO, see the chapter on booting and shutdown.