Red Hat Linux 7 Unleashed

Red Hat Linux 7 Unleashed

By William Ball

Building and Installing the Kernel

Configuration creates one precious file, /usr/src/linux/.config. This file contains the list of #defines for selected options; once you have a working configuration, you will want to keep a backup copy in a safe place.

You can now apply your updated configuration to build the new kernel, create the modules, and install the works. It's also now time to give your wrists a break and return to the command line to put it all together.

Scheduling a Kernel Rebuild Using at

If you are reasonably certain a kernel build will not fail, schedule your build using the at command. This lets you shift the system load to off-peak hours and sends the build output to you as email.

Before building the new kernel, you must regenerate all dependency files to account for any changes in include or module options. Until CML2 becomes the standard, this step is needed whenever the kernel configuration is changed. The make dep clean command will rebuild these dependency files and remove any stray generated files.

Building the Kernel

As with everything else about Linux, building the kernel offers many choices. All the build options are outlined in linux/Documentation/kbuild/commands.txt; the most common cases are building just the kernel file, building only the modules, building both, and doing an install of the kernel and/or the modules after the build.

For example, you may need to build a kernel file for some other computer (such as a laptop) or to be installed by hand under some very logical new name. Building this image could be done with

make bzImage &&     cp /usr/src/linux/arch/i386/boot/bzImage        /boot/vmlinuz-scsi

The first command compiles and compresses the kernel (for a "large kernel" image, leaving the result in arch/$(ARCH)/boot; the image is then copied manually to the /boot directory. This new image will not be installed until it is registered with a boot loader such as lilo (see Manually Installing a New Kernel). To automatically install a kernel image, use the command

make bzlilo

This will create the same compressed image and copy the file to $INSTALL_PATH/vmlinuz, then run the lilo command; make bzlilo assumes your /etc/lilo.conf expects this filename in this location.

Big Kernels on Intel Machines

Each of the kernel build commands has a "big-kernel" counterpart that is needed if the kernel grows to be over 1MB in size when uncompressed. Installing these large kernel images with older versions of lilo will overwrite part of the boot loader and the system will not boot. Since most configurations result in a big kernel and building small kernels with the big-kernel commands seems benign, unless you are building a very simple kernel for an old machine or an embedded device, router, and so on, use bzlilo and bzImage make targets just to be sure.

All z* targets are specific to the ix386 platform, and these will be removed during the 2.5 development and replaced by the bz* equivalents. For this reason, this chapter will use the normal z* commands.

The most common and convenient command for creating a new kernel is

make dep clean zlilo modules modules_install

This one command line will do the following:

Putting all these commands on one line will ensure that if any stage of this build fails, subsequent stages will not be started. The whole process can also be scheduled to run in an xterm window or alt-console, can be run during off-peak hours as an at job, or can be used as an excuse to play some serious Nethack or XPilot.

Manually Installing a New Kernel

The new kernel file is always found in /usr/src/linux/arch/$(ARCH)/boot/zImage and must be installed using the lilo boot loader or some other Linux loader before it can be used.

For example, to emulate the Red Hat /boot path scheme, you would need to copy the new zImage to /boot/vmlinuz (save the old one first!) and modify /etc/lilo.conf to include the backup version. Alternatively, to accommodate stubborn plug-and-play devices, you may need to copy this new kernel to your Windows 95 partition for use by the Linux loadlin.exe boot loader.

One frequent requirement is to create boot floppies. A boot floppy is nothing more than a kernel copied directly to a floppy disk and set to mount the root filesystem from the hard drive.

While it is far more mnemonic to create a boot floppy using the command

make zdisk

this is equivalent to using dd to copy the file directly to the raw sectors of the floppy disk device:

dd if=arch/i386/zImage of=/dev/fd0

Compiling for a Remote Machine

When you're creating a kernel for some other machine (such as a laptop), you can put the compressed kernel file and all modules into an alternate directory tree by giving alternate values for the INSTALL_* path variables on the make command line, for example:

INSTALL_PATH=/psitta     INSTALL_MOD_PATH=/psitta ROOT_DEV=/dev/hda1         make bzlilo modules_install

This will move the generated kernel, map, and module files to /psitta/vmlinuz, /psitta/System.map, and /psitta/lib/modules, where you can conveniently tar the whole directory for shipment to the remote machine with the following:

cd /psitta &&   tar cf - vmlinuz System.map lib |      rsh psitta tar xCf / -

There is one side effect: The command will also run lilo, but since the /etc/lilo.conf file does not reference these new /psitta files, there is no adverse effect.

The only potential hazard of this trick is a possible change to files in /usr/include/linux, which may affect programs subsequently compiled on the build host. Some care must be taken to ensure that the alternate kernel build does not leave unwanted changes in this directory on the build machine. Also, if the remote machine will be used to build software, after compiling the new kernel, you should copy the /usr/include/linux directory onto the remote machine after compiling the new kernel.

Troubleshooting the New Kernel

/proc is your friend. The pseudo-files in the /proc directory hold a wealth of diagnostic information and a simple means to set runtime parameters.

System Information Files

The most frequently useful /proc diagnostic files are as follows:

Setting Kernel Parameters and Options

Kernel and other low-level runtime parameters can be set through the /proc/sys pseudo-files. For example, to set the maximum number of file handles to a higher value, you can include a line in the boot scripts that echoes the new number directly into /proc/fs/file-max.

/proc Interfaces Changes

There are a number of differences between the 2.0, 2.2, and 2.4 kernels regarding the organization and format of /proc files. For example, the file-max pseudo-file was located in the kernel subdirectory for 2.0, but has now moved to the fs subdirectory. Changes in formats can also cause utility programs such as top and xosview to fail. When in doubt, check the linux/Documentation/Changes file for compatibility reports.

Share ThisShare This

Informit Network