Certification Objective 8.01-The Basics of the Kernel

The kernel is the heart of the operating system. It manages communication with hardware, decides which processes to run, and provides each process with an isolated, virtual address space in which to run. The kernel is what the GRUB boot loader loads into memory. The kernel loads device driver modules. It also allocates hardware resources such as IRQ ports, I/O addresses, and DMA channels. A recompiled kernel can lead to:

• Greatly improved speed at which kernel services operate.

• Direct support for commonly used drivers.

• Dynamic loading of appropriate drivers as modules.

• Lower memory consumption by removing unneeded components.

• Support for high-end hardware, such as memory above 4GB, hardware array controllers, symmetric multiprocessing (multiple CPU) support, and more.

In essence, you can customize the Linux kernel any way you want. The best way to do it is to make it fit every detail of installed hardware. However, you may not need to be so picky. In many cases, all you need to do is install the updated kernel RPM. In other cases, such as compiling third-party drivers, all you need to install is the corresponding kernel-devel RPM.

Exam Watch

Xen is based on a specially customized Linux kernel for virtual machines. The files associated with the Xen-based kernel are different from regular kernels. While Xen is important to RHEL 5, I don't believe you'll have to install or use it for your systems on the RHCE exams, at least until RHEL 6 is released. Of course, I could be wrong. Monitor the Red Hat Exam Prep guide for the latest information.

Best Practices

You should compile your kernel with only the elements you need. The more that is left out, the faster the whole system will run. For example, if there is no sound card, sound card support can be removed from the kernel. By removing unneeded devices, you will:

• Decrease the size of the kernel.

• Provide a modest increase in speed for the devices that are present.

• Make more hardware resources available for other hardware such as network cards, disk controllers, and so on.

• Reduce the risk of hardware limits, such as those that may be based on the size of the compressed kernel.

But don't remove things you don't understand, as those components may be essential to the smooth functioning of the kernel.

Generally, it is a good idea to have device drivers compiled as modules for any equipment that you may add in the near future. For example, if you may use your Linux computer as a router, you'll need a second network card, and you can add support for that card to your kernel. For example, if you have a 3Com 3c595 network card installed but you also have some 3Com 3c905 cards in storage, it may be a good idea to include the 3c905 module. That way, you can simply swap in the new card and let the module load, causing minimum downtime.

Modules are kernel extensions. They are not compiled directly into the kernel but can be plugged in and removed as needed. When configured as a module, a hardware failure such as that of a network card will not cause the whole system to fail.

Kernel Concepts

You will need to understand some basic kernel concepts before you can compile your own kernel. Kernels can be organized as one big unit or as a lot of interconnected pieces. Kernels are called up by boot loaders when you start your system.

Monolithic Versus Modular

A monolithic kernel is a kernel in which all the device modules are built directly into the kernel. Modular kernels have many of their devices built as separate loadable modules. Monolithic kernels can communicate with devices faster, since the kernels can talk to the hardware only indirectly through a module table. Unfortunately, the typical monolithic kernel is huge, which reduces available RAM. In addition, some systems just can't boot a kernel that's too large.

Linux once had problems loading modular kernels for some hardware. With a monolithic kernel, the drivers are already there and are often more appropriate for certain components such as embedded hardware.

A modular kernel has greater flexibility. You can compile almost all drivers as modules, and then each module can be inserted into the kernel whenever you need it. Modules keep the initial kernel size low, which decreases the boot time and improves overall performance. If Linux has trouble loading a kernel module, you can use the modprobe or insmod command to load modules as needed, and add those options to the /etc/modprobe.conf file.

Updating the Kernel

Updating the kernel is not as difficult as it looks. You should never overwrite or upgrade an existing kernel, as mistakes happen. New kernels are handled by installing the newly built kernel in /boot and then adding another boot option to your boot loader configuration file (/boot/grub/grub.conf) for the new kernel. GRUB treats the new kernel as if it were an entirely new operating system.

If you install the new kernel directly from a Red Hat configured RPM, it updates the boot loader automatically. Chapter 5 explored this process briefly.

If you do make a drastic mistake and the kernel doesn't boot, you can simply reboot the system and select the old kernel from the GRUB menu. You should also save existing kernel configuration files so that you have a template for newer kernels. This is discussed in more detail later in this chapter.

Other RHEL Kernels

There are a number of different kernels included with the RHEL installation files. You can and should install the kernel best suited to your system. Available RHEL 5 kernels are briefly discussed in Table 8-1. For the real versionnum, run the uname -r command. To verify your arch, or architecture (such as i686), run the uname -m command. As described in the table, there are different versions of kernel-devel, kernel-PAE, kernel-xen, and kernel-headers packages for each supported architecture.

Table 8-1: Available Red Hat Enterprise Linux Kernels (and Related Packages)

Kernel RPM	Description / Architecture
kernel-versionnum.i686	Designed for PCs with a single Intel/AMD CPU; also works with dual-core systems
kernel-versionnum.ia64	Designed for Itanium2 systems
kernel-devel-versionnum	Installs drivers and other information to help compile third-party drivers
kernel-PAE-versionnum	If you have more than 4GB of RAM, install the PAE kernel associated with your CPU architecture
kernel-PAE-devel-versionnum	If you have more than 4GB of RAM, install the PAE kernel associated with your CPU architecture
kernel-headers-versionnum	Includes kernel headers; often sufficient for drivers
kernel-versionnum.src.rpm	Includes the source code for the RHEL kernel

I don't list all available RHEL architectures in Table 8-1, and list them just for the basic kernel packages. Remember, the focus of the Red Hat exams is still based on the basic 32-bit Intel/AMD/clone CPU. PPC and s/390 systems are not (yet) supported in RHEL 5.

The table provides just a short list of kernel packages available for RHEL 5. It does not include Xen-related kernels. For more information on RHEL kernels available for multi-CPU or higher-end CPUs, refer to the RHEL documentation available online from www.redhat.com/docs/manuals/enterprise/.

The /boot Partition

The Linux kernel is stored in the partition with the /boot directory. New kernels must also be transferred to this directory. By default, RHEL configures a partition of about 100MB for this directory. This provides enough room for your current kernel plus several additional upgraded kernels.

The /proc Filesystem

The /proc directory is based on a virtual filesystem; in other words, it does not include any files that are stored on the hard drive. But it is a window into what the kernel sees of your computer. It's a good idea to study the files and directories in /proc, as it can help you diagnose a wide range of problems. Figure 8-1 shows the /proc directory from a typical RHEL computer.

Figure 8-1: A Red Hat Enterprise Linux/proc directory

The numbered items are based on process IDs. For example, the process ID of init is 1. The files in this directory include the memory segments that make up the active process. The contents of each of these files include the active memory for that process.

The other items in the listing are files and directories that correspond to configuration information for components such as DMA channels or whole subsystems such as memory information.

Take a look at some of these files. For example, the /proc/meminfo file provides excellent information as to the state of memory on the local computer, as shown in Figure 8-2. It can help you determine whether RHEL is having trouble detecting all of the memory on your computer.

Figure 8-2: Detected memory information

It can also help you measure the current memory state of your system. For example, if your system is overloaded, you'll probably find very little free swap space. The HugePages settings are associated with systems with over 4GB of RAM.

Now you can examine how Linux looks at your CPU in the /proc/cpuinfo file, as shown in Figure 8-3. In this particular case, the cpu family information is important; the cpu family value of 6 in this figure corresponds to a 686 CPU. If you have a dual-core CPU (and both cores are detected), you'll see two entries, even if you have only one physical CPU.

Figure 8-3: Detected CPU information

Many programs are available that simply look at the information stored in /proc and interpret it in a more readable format. The top utility is a perfect example. It reads the process table, queries RAM and swap usage and the level of CPU use, and presents it all on one screen.

IP Forwarding

More importantly, there are kernel variables that can be altered to change the way the kernel behaves while it's running. Sometimes it's appropriate to configure a Linux computer as a router between networks. By default, it does not forward TCP/ IP information. You can confirm this with the following command:

 # cat /proc/sys/net/ipv4/ip_forward 0 

If your computer has two or more network cards, you may want to activate IP forwarding with the following command:

 # echo 1 >> /proc/sys/net/ipv4/ip_forward # cat /proc/sys/net/ipv4/ip_forward 1 

Naturally, you'll want to make sure the setting is confirmed the next time you boot by activating the net.ipv4.ip_forward directive in the /etc/sysctl.conf file.

Preventing the "Ping of Death"

The following is another useful proc kernel variable (enabled by default), which enables the use of TCP SYN packet cookies. These cookies prevent SYN flood attacks on your system, including the so-called "ping of death." Verify that the tcp_syncookies setting is enabled with the following command:

 # cat /proc/sys/net/ipv4/tcp_syncookies 1 

Understanding Kernel Modules

When compiling a kernel, you could set up a monolithic kernel with every driver that you might ever need. Unfortunately, such kernels are large, unwieldy, and take a lot of time to load. Generally, most Linux administrators use kernel modules. As described earlier, a kernel module is not compiled directly into the kernel but instead operates as a pluggable driver that can be loaded and unloaded into the kernel as needed.

To have the kernel dynamically load and unload kernel modules as needed, the kernel module loader is used to control the loading and unloading of modules. For special parameters and options, edit the /etc/modules.conf file.

Most hardware modules are automatically detected. If you've just installed new undetected hardware, you could issue the following command:

 # depmod -a 

This will scan through your modules, find different dependencies for all installed modules, and map them out to a file (modules.dep). This command also creates a number of other files in the /lib/modules/`uname -r`/ directory (the version number of the kernel becomes the name of the subdirectory).

Once the depmod module scan is complete, you can load additional kernel modules. If that module has dependencies, then all the needed modules will automatically load first.

To load a module, you can use the modprobe command with the name of a specific driver, like so:

 # modprobe ipw2200 

This command loads the Ethernet module for an Intel Wireless 2200 card common on many laptop systems. This wireless card requires the ieee80211 module to work properly. If depmod were run first (and the physical card were detected), then the ieee80211 module would have loaded automatically before the ipw2200 driver. If a dependency in the list fails during loading, then all modules will be automatically unloaded.

Alternatively, you can set up these modules in /etc/modprobe.conf or files in the /etc/modprobe.d/ directory. It should already be configured during the RHEL installation process. Unfortunately, this work can be rather tedious. The following commands are accepted in this file:

• alias Allows you to bind a name to a module.

• options Allows you to specify options for a module.

• install module command Use command instead of insmod on this module.

• pre-install module command Run command before installing this module.

• post-install module command Run command after installing this module.

• remove module command Use command instead of rmmod on this module.

• pre-remove module command Run command before loading this module.

• post-remove module command Run command after loading this module.

Here are typical excerpts from modprobe.conf:

 alias eth0 natsemi alias eth1 ipw2200 alias snd-card-0 snd-ali5451 options snd-card-0 index=0 options snd-ali5451 index=0 remove snd-ali5451 { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; }; /sbin/modprobe -r --ignore-remove snd-ali5451 

Here the eth0 device is bound to the natsemi module. To load the network card (if it isn't already loaded), you can then simply type modprobe eth0 without knowing what card is in the computer. The next directive associates the ipw2200 module to eth1. The lines that follow show the configuration of a snd-card module. As suggested by their absence, Red Hat systems don't use most of the available commands for this configuration file.

The /etc/rc.sysinit script loads modules and creates aliases for them if found in this file. To have the sound modules automatically loaded during the Linux boot process, you can simply create an alias for the sound and/or midi modules in the modprobe.conf file.

To see what modules are loaded, you can type either

 # cat /proc/modules 

or

 # lsmod 

The lsmod command returns output that looks something like the following:

 Module             Size  Used by nls_utf8           6337  0 radeon           109281  2 drm               72149  3 radeon autofs4           25029  3 hidp              24001  2 l2cap             31169  5 hidp bluetooth         57765  2 hidp,l2cap sunrpc            156925 1 .... 

(Numerous entries omitted.)

 .... ide_cd            42337  0 cdrom             38497  1 ide_cd dm_snapshot       22245  0 dm_zero            6337  0 dm_mirror         31889  0 dm_mod            62425  12 dm_snapshot,dm_zero,dm_mirror ext3             134473  5 jbd               61801  1 ext3 ehci_hcd          35149  0 ohci_hcd          24669  0 uhci_hcd          27213  0 

The module name is listed on the left, and its size is in the second column. The Used by column shows more detail on how the module is being handled. If a module name, such as ext3, is listed in the right-hand column, then it's a dependency. In this example, jbd depends on the ext3 module.

The /lib/modules/kernel_version/ Directory Structure

All kernel modules are stored in the /lib/modules/kernel_version/ directory. As suggested earlier in the chapter, you can substitute 'uname -r' for kernel_version. If you have recently compiled a new stock kernel (not from Red Hat source code) and your modules are not loading properly, you've probably forgotten to compile and install the modules. In the source code directory (discussed later in this chapter), run the following commands:

 # make modules # make modules_install 

The first line compiles the modules, while the second places them under the proper directory tree. Be prepared, because these commands can take some time.

In this directory tree, different subdirectories represent different groupings. The following is a sample of a module directory:

 # ls -l /lib/modules/`uname -r`/kernel/drivers total 264 drwxr-xr-x  2 root root 4096 Mar 14 09:31 acpi drwxr-xr-x  2 root root 4096 Mar 14 09:31 atm drwxr-xr-x  4 root root 4096 Mar 14 09:31 block drwxr-xr-x  2 root root 4096 Mar 14 09:31 bluetooth drwxr-xr-x  2 root root 4096 Mar 14 09:31 cdrom drwxr-xr-x  7 root root 4096 Mar 14 09:31 char drwxr-xr-x  2 root root 4096 Mar 14 09:31 cpufreq drwxr-xr-x  2 root root 4096 Mar 14 09:31 crypto drwxr-xr-x  2 root root 4096 Mar 14 09:31 dma drwxr-xr-x  2 root root 4096 Mar 14 09:31 edac drwxr-xr-x  2 root root 4096 Mar 14 09:31 firmware drwxr-xr-x  2 root root 4096 Mar 14 09:31 hwmon drwxr-xr-x  5 root root 4096 Mar 14 09:31 i2c drwxr-xr-x  3 root root 4096 Mar 14 09:31 ide drwxr-xr-x  6 root root 4096 Mar 14 09:31 infiniband drwxr-xr-x  8 root root 4096 Mar 14 09:31 input drwxr-xr-x  8 root root 4096 Mar 14 09:31 isdn drwxr-xr-x  2 root root 4096 Mar 14 09:31 leds drwxr-xr-x  2 root root 4096 Mar 14 09:31 md drwxr-xr-x  5 root root 4096 Mar 14 09:31 media drwxr-xr-x  4 root root 4096 Mar 14 09:31 message drwxr-xr-x  3 root root 4096 Mar 14 09:31 misc drwxr-xr-x  2 root root 4096 Mar 14 09:31 mmc drwxr-xr-x  6 root root 4096 Mar 14 09:31 mtd drwxr-xr-x 12 root root 4096 Mar 14 09:31 net drwxr-xr-x  2 root root 4096 Mar 14 09:31 parport drwxr-xr-x  3 root root 4096 Mar 14 09:31 pci drwxr-xr-x  2 root root 4096 Mar 14 09:31 pcmcia drwxr-xr-x  2 root root 4096 Mar 14 09:31 rtc drwxr-xr-x 12 root root 4096 Mar 14 09:31 scsi drwxr-xr-x  3 root root 4096 Mar 14 09:31 serial drwxr-xr-x 11 root root 4096 Mar 14 09:31 usb drwxr-xr-x  9 root root 4096 Mar 14 09:31 video 

Remember that the /lib/modules/`uname -r` directory contains a modules.dep file that lists all the dependencies for all the modules within the directories. Each of these module directories includes a group of kernel modules for a common type of hardware.

You might want to become familiar with where to find certain modules when they're needed. Here are some module types you can find under each subdirectory:

• block Block devices: parallel port IDE drives, network block devices, XT disks, hardware RAID devices

• cdrom Non-ATAPI CD-ROM drivers: Mitsumi, Sony

• char Miscellaneous input and serial devices

• ide Hard disk drivers

• input Input devices (keyboards, mice)

• md RAID devices

• message Specialized I/O adapters

• net Network modules: basic network cards, generic PPP, SLIP

• parport Parallel port devices (not printers)

• pcmcia Drivers used by the PCMCIA cardmgr daemon (the actual cards use separate drivers)

• scsi SCSI tape, RAID, hard drive, and video (special video modules for Linux) modules

• sound Sound adapters

• usb Universal Serial Bus hubs and devices

• video Graphics adapters

All module names have the .ko extension (such as prism54.ko). You do not need to specify the full file name, just the first part of the module name (prism54). Once you know the directory structure, you can have the modprobe command load all modules for a certain category. For instance, if you are on a PC and you don't know what kind of network card is installed, you can type this:

 modprobe -lt net 

This will attempt to load all modules in /lib/modules/kernel_version/kernel/drivers/ net, stopping if and when a match is found.

To remove a module such as ipw2200 and all its dependencies, use this command:

 modprobe -r ipw2200 

This command removes the modules and all their dependencies, provided they are not in use by another module or not currently active. For example, if your network is active, you can't remove the network ipw2200 driver module. If you want to remove only the module and leave the other dependent drivers, remove the hardware, and then run the modprobe command without the -r switch.