Section 25.1. Objective 1: Kernel Components

25.1. Objective 1: Kernel Components

A quick look at the contents of a kernel source directory and you get a good idea of the various pieces required to make your kernel function. If that doesn't give you any ideas, a glance through the documentation available should satisfy your curiosity. As discussed in Chapter 13 for Exam 102, the Linux kernel manages all aspects of your computer, virtual memory, the device drivers, networking code, and so on. The kernel also runs applications, but in a separate space outside the kernel. Applications and services are executed in user space.

There are very large books out there covering the nitty-gritty details of the development of the Linux kernel, but these topics are outside of the scope of a sysadmin, thus are not covered in the LPI Level 2 Exams. Essentially what LPI is looking for is for you to understand the applications for various types of kernel images, demonstrate proficient use of the various branches of kernel development, and efficiently implement kernel patches.

25.1.1. Kernel Image Formats

Let's review a couple of fundamentals. Two types of kernel image formats can be used on Intel platforms: zImage and bzImage. The difference between them is the way they bootstrap and how large the kernel can be, not the compression algorithm as one might think. Both use gzip for compression.

zImage

This is the old boot image format for Intel, which works on all known PC hardware. The bootstrap and the unpacked kernel are loaded into the good old, 8086-era 640 KB of low memory. The allowed kernel size is 520 KB. If your kernel excedes this size, you either have to switch to bzImage or put more of the kernel into modules. The boot image builder will tell you when this is the case.

bzImage

The b in this format stands for big. The bzImage kernel image is not restricted to 520 KB or even 640 KB. bzImage is now the preferred boot image. Though there are some reports of boot failures using this boot image type, these problems are being pursued because the kernel developers want the format to work on all Intel hardware.

25.1.2. Different Kernel Trees

Your dad used to tell you that money didn't grow on trees, but kernels do. Kernel development trees aren't too dissimilar from your family tree. It all began in Finland when two offspring were born: stable and development. Traditionally, each branch of the family tree maintains its family naming schemes, but don't forget that this practice is simply for superficial version tracking and has no effect on the kernel itself. John Doe will still be the same person, even if he changed his name to John Buck.

To refresh your memory from your 102 exams, official kernels are numbered with a decimal-delimited number in the format major.minor.patchlevel, such as 2.6.15. The minor value has traditionally distinguished a stable kernel from a developoment one: an even number indicates a stable kernel, whereas an odd number indicates a development kernel. But 2.6 is on a path of constant development, however, and there is no 2.7, so the stable/development distinction is no longer as meaningful.

25.1.2.1. Choosing an appropriate kernel

For some kinds of support situations, such as with a Red Hat Enterprise Linux on which you want to run applications such as Oracle, you may not be able to choose your kernelyou have to use a Red Hat-issued kernel. Oracle, for one, is very picky about this.

Other than that, there is really no rule to follow when choosing a kernel tree to use. Common sense should tell you if you're running a production server, stable kernel code will be the best choice. However, support for new hardware and other features may not be in your stable versions, forcing you to choose the development kernel. For instance, in the 2.2 stable kernels, USB was supported by only the 2.3 development kernel. If you wanted to use a USB device on your Linux machine, you had to either run the development kernel or apply a patch (if available)--a package of source code that alters the kernel.

25.1.2.2. Hardware support

In your career as a Linux administrator, you may easily get in a situation in which some new machine has hardware components that are not supported by your custom kernels, or even by your distributions' kernels. Red Hat kernels usually include support for anything you can think of, but some other distributions have separate kernels that support specific hardware. If you buy some very racy new hardware, you may find that there is no support in any kernels and that you either have to develop it yourself or wait a month while someone else does it. And then you may have to get a special patch and apply it yourself, as described later in this chapter.

In most other situations, a distribution's kernel will either just work or will work if you construct a suitable initrd image for the kernel to load the needed drivers.

If you're compiling custom kernels, it is important to know all your hardware: which IDE chipsets, SCSI controllers, Ethernet cards, and so on you have. Your kernel must have support for your boot disk system, either inside the kernel or in the initrd image. Otherwise, the kernel will not be able even to boot and mount the root filesystem. To get on the network, it must either have support for your Ethernet cards, either in the kernel or as a module that is loaded during the init process (described in the section "Objective 1: Customizing System Startup and Boot Processes" in Chapter 26).

For you to identify these components, it is a good idea to boot a distribution kernel and scrutinize its boot log. On Red Hat and Debian systems, this is saved in /var/log/dmesg. In the /proc/pci pseudofile, or with the lspci command, you can find the complete list of PCI hardware in the machine. It is also a good idea to have the vendor's documentation of the hardware, because it may contain the names of chipsets and components.

One of the challenges in all this is that most hardware has two or three different names. It may have a "trade name" such as Intel Ethernet Express Pro 100, behind which there is a chipset name or part name, and even a code name or pet name given by the engineers that constructed it. Any of these three names may be found in the vendor documentation, and any of them may also be used in the Linux kernel . It will be your job to match all these names and produce a viable kernel for your hardware. Luckily, it's not as hard as we just made it sound. But there are a lot of different chips and hardware in a modern PC.

25.1.2.3. Patches

Kernel patches are found in both the stable and the development kernel trees. But there are also third-party patch repositories that implement some specific features that the kernel maintainers do not want or that are not mature enough to be in the stable or even development trees. Patches are minor updates or fixes that can be applied to your specific kernel, but without the need to get a whole new kernel. Depending on the nature of the patch, you may or may not need to fully recompile your existing kernel. If the patch just contains new modules or fixes existing modules, you don't generally need to. If it modifies something in the kernel proper, the whole kernel should be recompiled from scratch.

While there's nothing magical about the filenames, kernel patches are typically named with patch- prepended to the kernel version, such as patch-2.4.20.bz2. We'll discuss kernel patching more in the third section of this chapter.

25.1.2.4. Kernel modules

The Linux kernel supports loading (and unloading) modules. These modules may support different hardware, filesystems, network stacks, and anything else the kernel needs in different situations. The mass of supported things in the Linux kernel is quite astounding. Modules are a way to mitigate the overabundance of features and bring down the kernel image's size.

When you build kernels, you may choose to build some features as a module. When a feature is needed, it must be loaded either manually by a script or automatically. When a module is loaded, it may depend on other modules, so it cannot be loaded until those other modules are loaded. Luckily, the module-loading mechanism can search recursively for dependencies and load whatever is needed.

After a kernel is built and the modules installed in their directory hierarchy at /lib/modules, their interdependencies are found with the depmod command, an example of which is:

 depmod -ae -F /boot/System.map-2.4.18 2.4.18 

If any modules lack functions they need, you may see a message such as this:

 depmod: *** Unresolved symbols in /lib/modules/2.4.18/kernel/drivers/scsi /pcmcia/fdomain_cs.o depmod:         isa_readb depmod:         isa_memcpy_fromio 

Such a message^[*] is probably due to a programming error. If you have any programming and C skills, it may be possible for you to resolve the problem. Otherwise this kernel is not usable for you. The message may also appear if you have built the same kernel version several times with different options and modules. In that case, the module that the kernel is trying to load may be from an old compilation and installation and is not supposed to be present any more. If you recognize that this is, indeed, the case, you can just remove the module, and thus the problem.

^[*] This is not a real problem in 2.4.18; it had to be provoked artificially for the sake of an example.

You can put anything you like into a module, even parts of the kernel that are needed to boot the machine. A mechanism known as initrd can be used to load modules very early in the boot process. An initrd RAM disk image can be loaded with the help of the system's BIOS. A bit later, before the kernel needs to access disks or networks, the modules needed to boot are loaded into the kernel. Therefore, support for SCSI drivers, LVM, filesystems, and anything else can be included in this initrd image to get the machine booting. initrd is discussed more later in this chapter.

Other issues you need to know about relating to kernel module loading and unloading are covered in Chapter 13.