Red Hat Linux 7 Unleashed

Red Hat Linux 7 Unleashed

By William Ball

Obtaining the Kernel Sources

Every Linux distribution contains kernel sources. Red Hat offers install options to include the kernel headers, and a separate RPM to include the kernel sources. You must install the kernel headers if you plan to compile any software; to build the kernel, you must also install the kernel-sources RPM, or obtain kernel sources from some other source.

When fetching kernel sources, it is good netiquette to seek a mirror site as close to you as possible. Although famous sites such as Red Hat (ftp://ftp.redhat.com) and kernel.org (ftp://ftp.kernel.org/pub/linux) will have the files you need, you should check http://www.kernel.org for an appropriate mirror site.

Distribution Kernels

Before you replace your kernel sources, be aware that most distributions apply their own patches to the standard Linux sources; Red Hat is no exception to this rule. If you recompile from your official Red Hat source RPM, there may be features missing, modified or added from what is covered in this chapter, and if you obtain canonical sources from the kernel FTP site (ftp://ftp.kernel.org), the resulting kernel may break special features in your distribution.

It is a double edged sword: Using your Red Hat sources means you must rely on Red Hat for all kernel updates whereas the canonical sources are regularly updated by incremental patches that will not apply smoothly to the Red Hat edition. Other authors may also supply patches for special features such as motherboard sensor reading or multiline ppp, and these patches may also fail to apply against the Red Hat edition.

In general, if you need to remain consistent with your Red Hat kit, you should stay with their edition of the kernel source files, but if you need advanced features and timely updates, you should consider migrating to the canonical http://kernel.org sources.

FTP mirrors partition kernel packages by major and minor version numbers such as /pub/linux/kernel/v2.4. Each directory contains whole-enchilada source tarballs and compressed patch files—if you are jumping up from 2.2 or 2.3, or if you want to start fresh, you need the file named linux-VERSION.tar.gz (or .bz2). Although a lot to download over a modem connection, once you have a standard source tree, you can update incrementally by downloading much smaller patch files.

Before you open any .tar file, you should always list the contents to see if the file is complete and to get an overview of the directory structure it will install:

$ tar -tzf linux-2.4.5.tar.gz

This will print a long list of files, including directories for device drivers, modules, and architecture-dependent code for all the current Linux ports as illustrated in Figure 27.1. The important detail is that the tarball unpacks into a directory called simply linux/.

Symbolic Links to the Kernel Sources

Before you unpack a kernel tarball, create a version-tagged directory and symlink (ln -s) it to the generic /usr/src/linux location. For example, if you obtained linux-2.4.7.tar.gz, create /usr/src/linux-2.4.7 and a symlink /usr/src/linux before you unpack your kernel sources:

cd /usr/src
mkdir linux-2.4.7
ln -s linux-2.4.7 linux
tar xzf linux-2.4.7.tar.gz

If /usr/include/linux is also symlinked to /usr/src/linux/include, your include files will always belong to your current kernel. You can now keep several versions of the kernel, each in its own /usr/src/linux-X.Y.Z directory. When you patch your sources, the patch will apply to the appropriate kernel sources through the linux/ symlink, and you can experiment with multiple versions, quickly switching between them by simply replacing the symlink.

Checklist for Coping with New Kernels

When dealing with new kernels, keep the following items in mind:

A Script to Check Version Numbers

Checking version numbers against the Documentation/Changes file can be tedious, especially if you're like me and can't remember the command syntax for all these commands. The shell script in Listing 27.1 generates a simple list of packages typically included in the Changes list. I originally wrote this as a poor man's version of the versions command available on SiliconGraphics IRIX machines.

Example 27.1. Shell Script for Extracting Versions

#!/bin/sh
echo Versions 0.1 c.1999 by Gary Lawrence Murphy
echo ========================================================
/sbin/insmod -V 2>&1 | grep version | grep insmod
echo -n GCC:
gcc --version
ld -v
ls -l /lib/libc.so.* | gawk '{ print $9 $10 $11;} '
ldd --version 2>&1 | grep ldd
ls -l /usr/lib/libg++.so.* | gawk '{ print $9 $10 $11;} '
ps --version
procinfo -v
mount --version
hostname -V
basename --v
/sbin/automount --version
/sbin/showmount --version
bash -version
ncpmount -v
pppd -v
chsh -v
echo ========================================================

Source Tree Patches

Updates are distributed as patch files named for the version that results from the patch. For example, an upgrade from 2.4.4 to 2.4.5 will be called patch-2.4.5.gz. Patch files are simply context diffs, the output of the CVS or UNIX diff -c command (see man diff) which list the differences from the prior version. The patch is applied by piping the file through the GNU patch utility; the patch will be given lines of context around the change and told to delete, add, or replace lines in the source files.

Patching Incremental Versions

Patch files can only upgrade by one revision number. Upgrading from 2.4.1 to 2.4.6 will require patches for all intermediate releases. An exception to this rule is the -ac series pre-release patches, which are assembled by Alan Cox. These patch files are always accumulative based on the most recent official release. For example, patch-2.4.1-ac12 might be Alan's twelfth patch on the 2.4.1 release, but it must be applied to a clean 2.4.1 kernel; the patch will fail to upgrade from patch-2.4.1-ac11.

Unless you have good reason to suspect otherwise, you should compile and test each incremental revision before applying the next patch. Once a patch is applied, there is no way to undo the changes.

Patch files are also created by comparing the sources of totally clean Linux distributions. Before you run the patch, it is important to back up your linux/.config file and then to clean your kernel source tree to the most pristine state using make mrproper:

cd /usr/src/linux
cp .config /usr/src/config-old
make mrproper

This removes any residual generated files from previous compilations as these might interfere with the patch or the subsequent kernel build. Saving any previous .config file (which would be otherwise removed by mrproper) allows you to bootstrap your next kernel with make oldconfig.

There are two things you should know about patch files: They are much smaller than the source tarball (typically a few hundred kilobytes), and they do not always work.

Verifying a Patch Update

After patching your sources, search the kernel tree for reject files (find . -name "*.rej") containing the failed diffs; these are most often the result of some innocuous difference in whitespace or tab stops between the sources owned by the creator of the diff and your own sources. If you find any *.rej files, you must manually correct the associated source files before you compile.

The linux/scripts/patch-kernel is a Perl program that attempts to automate this process. patch-kernel will deduce the current source version number and compare this to the patch files found in the current directory. If higher-version patch files are found, the script will step through these sequentially upgrading the sources. Frankly, I have never had much luck with this script, but your mileage may vary.

Once you have patched the sources, you can bootstrap your new kernel configuration by copying your backup .config file to linux/.config and using make oldconfig to migrate the options present in your previous installation, preserving all those fiddly settings that are so often forgotten (such as the IRQ of your sound card!). You will need to monitor this process: make oldconfig will stop and prompt for any new options added by the new sources. Once this command has run, use make xconfig to recheck the settings, and then compile with any of the make build targets.

Upgrades and Modules

Modules are generally loaded automatically via kmod or scripted using /sbin/insmod program, with the obvious /sbin/rmmod to remove them. Other utilities in this suite include /sbin/depmod to compute module dependencies and /sbin/modprobe to load the module and those upon which it depends.

One of two module things can go wrong with a module when upgrading to a newer kernel:

NOTE

There is a third possibility with pre-2.2 kernels: Module version numbers are mismatched. This happens when the kernel has been compiled with the option to check module version numbers, and those numbers do not exactly match (including the build number). These modules are rejected, and your system may not boot if it depends on some critical module to function. This is no longer an issue because this test is no longer part of the Linux configuration.

The first situation is most likely. The ix386 module utilities have been updated to use PIII instructions and new editions may not have been included in your distribution files. If your module utilities meet the requirements spelled out in linux/Documentation/ Changes, you will have no problem, but if you do happen to boot a kernel with old module utilities, you can hang your system.

The second problem can hit anyone. This is one of those things that, once you know what has happened, you realize the solution is just common sense. For example, suppose you compile Windows VFAT filesystem support as a module, but then your boot scripts try to use some file from your windows partition prior to the module loading. Or, and more likely, you may accidentally attempt to load modules out of sequence. For instance, you might configure your network support as a module, forgetting that the httpd will hang the boot scripts while trying to resolve the hostname, and then inadvertently assign httpd an earlier slot in the /etc/rc.d/rc5.d boot sequence.

There is only a small overhead in loading and unloading and in the coding of a driver as a module. Unless memory or performance is critical, the code is needed continuously, or the module is required early in the boot process, it can and probably should be compiled as a module.

New Features in 2.4

If you are coming to this chapter from the 2.2 Kernel reference material, you're in for a ride. Systems have changed all over the place. The following is just a partial list of systems that have been added, rewritten, or rethought in the 2.4 kernel:

Planned Features for Linux 2.5

Kernels take time to polish for production, and books take time to prepare and print; as a result, there are many features that were either not ready in time to be considered for the 2.4 kernel, or that were not well understood enough to be included in this book prior to press. The following sections are a guess at some of the directions to be taken with 2.5, but do not be surprised if more than one finds its way into an early revision of 2.4.

CML2

If you have ever tried to add a new kernel feature, you have already seen why Eric Raymond is spending his flight and hotel time redesigning the kernel configuration tools.

CML2 is the Configuration Modeling Language to succeed the current make xconfig method with a simpler system, is easier to maintain and to program, and will allow module and service developers to specify all dependencies of their code. It may even be possible to specify your hardware to the CML2 interpreter and have it deduce the kernel options without intervention.

Frame Buffers (fbdev)

James Simmons has plans for cleaning up the fbdev layer with a new API, adding support for cards with multiple frame buffers, and adding real multihead support to the console system.

Sound System

Although partially present in 2.4, the next kernel will expand the support for the ALSA sound drivers.

V4L2

The 2.4 kernel contains little in the way of new support for the video and FM radio interface primarily because the developers are reworking the entire system for V4L2; unfortunately, V4L2 was not considered stable enough to be included into the 2.3 development tree and has been pushed back to Linux 2.5.

Memory Management and Memory Devices

Rik van Riel has plans to support allocating very large continuous memory blocks on system initialization, and improved dcache and other improvements to the VM. David Woodhouse is also calling for adding support for flash and other memory device drivers.

Journaling Filesystem

The 2.5 TODO list includes merging in the changes for the ReiserFS and ext3, merging in XFS, HFS+, JFS, and NWFS; whether all of these will happen or if some hybrid occurs remains to be seen.

Share ThisShare This

Informit Network