Kernel Tech

A technical expert will tell you that the kernel is the Linux – the Hardware Abstraction Layer and everything else you see on your screen is mostly application software from the GNU collection. Linux is the operating system core that makes a computer usable in a Unix-like way. On the technical level, a kernel consists of the following basic components:

• support for hardware and corresponding drivers;
• a so-called scheduler, which distributes available computing power (CPU cycles) and hardware resources among application programs, thus allowing the programs to run independently of each other without causing deadlocks or conflicts;
• a virtual memory and filesystem manager that makes memory and disk space available to programs.

Most users just accept the kernel that comes with their Linux distro without seriously tinkering with it. However, if you happen to need a driver or system component that isn't built into your Linux system, or even if you just like tinkering, you might one day face the task of replacing, rebuilding, or extending the kernel running on your system. In this article, I describe some techniques for working with the Linux kernel.

Why Upgrade?

Kernel 2.6.28 is released, and when you read through the changelogs, you notice a vast number of bug fixes and feature enhancements that create an impression of huge performance and stability benefits with a simple package update. Unfortunately, the reality is not quite so simple. Because of the rapid kernel development process, new releases appear almost every month. Most new releases do not provide a major change unless you are looking for something very specific. And, even if a new component or subsystem is announced in the news, it is unlikely that you will find the latest kernel version ready to install in your distro's repository. Most distributions provide stable and well-tested snapshots that might contain some selected new features and improvements of newer releases but keep the old version number for compatibility with third-party modules. If you are looking for the newest (and probably not well-tested) version, you will have to compile the kernel yourself.

Why would anyone even bother to upgrade the Linux kernel? If you spend a lot of time hacking your Linux system, you might find yourself needing to repair a system that broke because you forgot to activate an important option. Or, in some cases, a new kernel might contain a driver or support a module that offers improved hardware support. In other situations, the update might address an urgent security problem.

Checking Kernel Version

To find out which kernel is currently running on your system, open a shell and type

uname -a

which should output something such as:

Linux eeepc 2.6.26.5-eeepc #13 PREEMPT Thu Oct 9 04:04:42 CEST 2008 i686 GNU/Linux

Another command

cat /proc/version

provides additional information on the compiler used to build the kernel.

As you will learn, this information comes in handy when you are working with kernel modules:

Linux version 2.6.26.5-eeepc (knopper@Koffer) (gcc version 4.3.2 (Debian 4.3.2-1) ) #13
PREEMPT Thu Oct 9 04:04:42 CEST 2008

The preceding output reveals several facts about the system:

• The kernel is in the 2.6 kernel series.
• The minor release version is 26.
• The patch level (mostly for bug fixes) is 5.
• It was presumably compiled for an Eee PC system, although this setting can be any text string specified as EXTRAVERSION in the kernel Makefile.
• The system architecture is based on i686, which supports the machine instruction sets of Pentium 2 and higher, but not older 386- or 486-based computers.
• The GCC compiler version used when compiling the kernel from its source was version 4.3.2 on a Debian system. The resulting binary was the 13th time the compiler was run for this source, and the compile was performed on Thursday October 9, 2008.
• This kernel is preemptible. That is, the system is optimized as a desktop system with a quick interactive response rather than as a compute server.

This detailed information on the state of the current system provides a starting point for understanding how to proceed with a kernel upgrade.

Package Upgrade

Most Linux distributions provide an easy means for upgrading the kernel through a package management system. If you don't need a customized or optimized kernel, updating the kernel through your distro's package system is often much easier than compiling and manually installing the kernel on your own.

Here, I describe how to upgrade your kernel through the Debian-based Aptitude package management system. The concepts are similar for other systems. If your distro uses an alternative package tool, consult the vendor documentation.

The Debian kernel packages used to have the name kernel-image. This name has recently changed to linux-image. Command-line gourmets will prefer to install the new kernel image with a text-based command

aptitude install linux-image-686

instead of with a GUI-based package manager; in either case, the steps executed are basically the same:

1. The package is decompressed and unpacked into a new location. The static part of the kernel goes to /boot/vlinuz-versionnumber-architecture; kernel modules go to /lib/modules/versionnumber.
2. Scripts check to see whether an initial ramdisk is necessary for your system; if it is, the necessary modules are set up in a file called /boot/initrd.img-versionnumber-architecture. The system tool mkinitramfs is responsible for this step. Its configuration files are at /etc/initramfs-tools/*, which is where you will go to make certain configuration changes, such as changing the ramdisk configuration. Unless the module names have changed, or unless you plan to activate software RAID or LVM, you should not have to do much there on your own.
3. The bootloader is made aware of the new kernel as a choice for booting. Unless the old kernel is removed (which should not happen automatically), it will still be in the bootloader configuration file, which allows you to switch back to the old kernel interactively as the system starts.

Before you reboot the system, check the following:

• Did you previously have to install or recompile additional kernel modules for the system to start? In the rare case that your primary boot medium controller needs a driver that is not part of the kernel or ramdisk, you will have to compile and install the necessary module before you reboot; otherwise, it might be difficult to get the system up and running with the new kernel.
• Is the bootloader correctly prepared for the new kernel? For instance, LILO (the Linux Loader – one of the first filesystem-independent bootloaders for Linux) should have entries similar to Listing 1 in the /etc/lilo.conf file.

If you are using the GRUB bootloader, the /boot/grub/menu.lst file will need entries similar to those in Listing 2.

In Listing 1, note that /vmlinuz.old and /initrd.img.old are symbolic links to the old but still-existing kernel and initrd files in /boot. This approach makes it possible to boot the old kernel if the new one isn't working as expected. If you change /etc/lilo.conf manually, run the lilo command as root before rebooting, because the LILO bootloader needs to update its record of the kernel file location. The GRUB bootloader, on the other hand, can find the files on its own using its own filesystem driver.

If it seems that your system is ready for the new kernel, reboot to see that everything works. If the new kernel doesn't start for some reason, select the old kernel in the boot menu to restore the previous configuration.