Introduction to Linux Kernel Management

At the heart of the SLES operating system is the Linux kernel. As mentioned in the "SLES Startup Procedures" section of this chapter, the Linux kernel is found in the /boot directory and is typically named vmlinuz-<kernel version>. The default kernel with an OES Linux installation is version 2.6.5-7.112-default. The kernel version number can actually be divided into the following three important numbers:

• Major Number This number represents the current major version number of the Linux kernel. The Linux kernel is currently at a major number of 2.

• Minor Number This number represents the minor version number of the Linux kernel. Modern distributions are based on either minor number 4 or 6 of the Linux kernel. SLES9 uses a kernel with a minor number of 6. This kernel is commonly referred to as the 2.6 kernel.

  The minor number can also be used to represent the status of the kernel version. If the minor number is an odd number (such as in kernel version 2.5), that version of the kernel is a non-stable or developmental release of the kernel. Minor numbers using an even number (such as 2.6) are known as production or stable versions of the kernel.

• Revision Number The final number of the Linux kernel version is the revision number of the kernel. SUSE also adds some information to this field to indicate the build of the kernel, as well as the specific environment the kernel was intended for. In the OES kernel version number 2.6.5-7.112-default, the revision number is 5-7 and the SUSE build number and environment designations are 112-default.

NOTE

The uname -r command can be used to display the version of the currently running kernel.

The most common administrative task relating to the kernel is most likely applying kernel updates to resolve security issues. Applying kernel updates through the YaST Online Update or Red-Carpet tools is a very straightforward process, but if problems are encountered, you may need to know more details regarding the layout of the kernel-related files.

Table 6.5 outlines the important kernel-related files found within the /boot directory.

Table 6.5. Important Kernel-Related Files in /boot

FILE	DESCRIPTION
vmlinuz-2.6.5-7.112-default	The 2.6.5-7.112-default version of the Linux kernel.
vmlinuz	A symbolic link that points to the current version of the Linux kernel. The /boot/grub/menu.lst file typically configures GRUB to reference this vmlinuz file rather than the actual vmlinuz-<version number> file.
initrd-2.6.5-7.112-default	Initialization RAM Disk used by the startup routine to provide required hardware drivers to the initialized kernel. This is used prior to the root filesystem being mounted.
initrd	Symbolic link that points to the current version of the initrd file. The /boot/grub/menu.lst file typically configures GRUB to reference this initrd file rather than the actual initrd-<version number> file.
config-2.6.5-7.112-default	Configuration file used for the compiling of the current kernel.
kerntypes-2.6.5-7.112-default	File containing information about data structures within the Linux kernelused by the Linux Kernel Crash Dump facility for debugging purposes.
system.map-2.6.5-7.112-default	Map file containing address of symbols for the current kernel.

NOTE

As mentioned in Table 6.5, the GRUB bootloader is typically configured to load both the kernel and the initrd image using the symbolic links rather than the actual filenames. This is normally a good thing, but if a kernel patch fails to properly configure these links, the bootloader process will be unable to locate these important files and the boot process will fail.

Kernel Sources

Compiling your own Linux kernel is not necessarily a difficult process, but because of the potential for misuse and catastrophic side effects, Novell does not support compiling your own kernel. As a matter of fact, if you do require support by Novell and you're running a custom kernel, the first question you will likely hear is "Does this problem occur when using the default kernel?"

Even though compiling a custom kernel is not a good idea for a production server, there are a number of reasons why you might want to install the kernel source code. One example might be that a custom program you need to compile requires the kernel source to be installed. An even better example is the potential ability to look through the kernel source code to help track down error messages and their causes.

Using the grep command to search for a specific error message within the kernel source code tree can often lead to the exact error message. When you find the code surrounding the error message, you can analyze it and the root cause of your problem may be apparent.

In order to use kernel sources in this manner, the kernel-source package must be installed. This package is not typically selected for installation using the default configurations, but can be easily installed after the initial installation. When installed, the Linux kernel source code is located in the /usr/src/linux directory structure.

Working with Kernel Modules

When the Linux kernel is built, it must be built in such a way as to support as much third-party hardware as possible. There are essentially two ways to accomplish this. The first is to compile the kernel with specific drivers for all third-party hardware as part of the kernel itself. Although this type of kernel does work, it is generally not considered an efficient method of building the kernel as any one server really only needs a somewhat limited number of third-party drivers loaded.

The second and more common method of building the kernel is compiling a kernel with internal support for common hardware components (such as PCI support) and providing third-party hardware support through the use of external modules. This type of modular kernel is what is available with SLES.

When using external modules, the system must be configured to load the appropriate hardware modules upon system startup. During the installation of SLES, the installation routine will scan and detect hardware devices and build the initrd image with the required modules. However, when adding hardware after the installation or when installing proprietary drivers for unsupported hardware, it may be necessary to configure the server manually.

Table 6.6 lists commands used to manage kernel modules.

Table 6.6. Commands and Files Used with Kernel Modules

COMMAND OR FILE	DESCRIPTION
lsmod	Lists all currently loaded kernel modules.
rmmod	Removes the specified kernel module from memory.
insmod	Inserts a specific kernel module into the running kernel.
modprobe	Inserts a specific kernel module into the running kernel. If the specified module is dependent on other kernel modules, additional required modules will be dynamically loaded.
/etc/modprobe.conf	Configuration file used to load and alias kernel modules at system initialization. Additions to this file should be placed in /etc/modprobe.conf.local.
/etc/sysconfig/kernel	Configuration file used by the kernel during system initialization. The MODULES_LOADED_ON_BOOT directive can be edited to load specific modules at system startup.

After you have used the utilities listed in Table 6.6 to load and test a required hardware module, you must configure your server to automatically load the module upon server restart. This can be accomplished by adding the module to the MODULES_LOADED_ON_BOOT directive of the /etc/sysconfig/kernel file, or the module can be added to the /etc/modprobe.conf.local file.

NOTE

If you have a complex loading requirement, such as the specific ordering of more than one module, the /etc/modprobe.conf.local file is much more flexible than /etc/sysconfig. For more information on the syntax of this file, please see the man page for modprobe.conf(5).