7.1. The Kernel Needs an Upgrade
You don't need to change the kernel on your system often, but any Linux geek should be comfortable installing a new kernel without having to upgrade the entire distribution. The difficulty of the job depends on the reason you're upgrading. If a security flaw or other bug is found that merits an upgrade (which doesn't happen often), you may be able to simply download a package from your distributor with the new kernel. Support for new hardware may require the compilation of a new module, but usually not the entire kernel. The one major job you may run intorecompiling the whole kernelis usually necessary only when you want to add some major feature, such as a new networking protocol, and even that isn't so hard.
A new kernel may have unexpected effects on your system, and you may accidentally leave out a feature that was in the previous kernel, so make sure an upgrade is absolutely necessary before you go whole hog. Any time you upgrade a kernel, you're taking a risk. Kernel upgrades can change the way your operating system works with your hardware, services, and more. Be prepared to back off and return to the previous kernel until you have run the new one for quite some time and are sure it's robust.
When you upgrade the Linux kernel, you have several other decisions to make: how to add the new kernel to your system, selecting a source, and whether to patch the existing kernel. These options require you to consider a number of factors:
I explain each of these factors in detail in the following sections.
7.1.1. Upgrading from a Package
Red Hat, SUSE, and Debian all create binary kernel packages to incorporate security updates, add new features, address problems documented in bug reports, and more. When you install an updated binary kernel package, it automatically updates your active bootloader. You'll then have two kernels available, side by side, in your /boot directory.
Installing a new kernel is simple. For Red Hat and SUSE, use the -i or --install option associated with the rpm command:
rpm -i kernel-newversion
Alternatively, you can use the update tool associated with each distribution (up2date, yum, YaST); when you select an updated kernel with those tools, by default they apply the install (and not the upgrade) option.
For Debian, connect to the network and use apt-get install to retrieve and install the new kernel:
apt-get install kernel-image-newversion
Red Hat, SUSE, and Debian design their current binary kernel packages to add appropriate stanzas to GRUB or LILO bootloaders.
7.1.2. Selecting a Source
There are a couple of situations when you can't depend on a binary package but have to download and compile source code.
The first situation is when the feature you need, such as the right modules for your hardware, is not available in your current kernel. You may need to download the modules as a part of another package. Especially if the package is available as a tarball, you may need to apply the instructions in any embedded script. Typical script names include Makefile and INSTALL, and may be detailed in a README file. One example of how this works is the "My Wireless Card Works on Another Operating System, but Not Linux" annoyance in Chapter 5.
The other situation is where the driver is already available as part of the kernel, either embedded in the kernel itself, or available as a module in the appropriate /lib/modules/`uname -r` directory. In that case, you'll need to download the source code for your kernel, use a menu to activate the appropriate features, and then recompile that kernel.
If at all possible, use the kernel source code developed specifically for your Linux distribution. While you may want to use the latest features available in the latest "stock" Linux kernel http://www.kernel.org, be careful. Each distribution compiles kernels with specific features that can interact and impact one other in subtle ways.
Several distributions work with special kernel sources. Some even include "backports" from more advanced kernels. So if you download a new version from http://www.kernel.org, you could lose the backports with other features that you need. It's therefore best to work with kernel sources provided for your distribution. For example, Red Hat Enterprise Linux 3 uses a specially configured Linux kernel that's nominally built from version 2.4.20, but includes backports from version 2.6. So if you install version 2.4.21 from http://www.kernel.org, you may actually lose features that you need.
Most distributions make the source code available in easily downloadable packages with names such as kernel-source. As we'll see shortly, though, Red Hat changed this convention starting with Fedora Core 3 and RHEL 4.
7.1.3. Patching the Kernel
If you download the original source code for a kernel from http://www.kernel.org, you can also use patches from that site. For example, if you've compiled and installed kernel version 2.6.15, you can upgrade to version 2.6.16 by downloading and installing patch-2.6.16 and compiling the combined source code.
If you choose to patch a kernel, the process may be more complex than you expect. Patches are applied to the kernel source code. Installing the patch is not enough. You still have to compile the combined source code into a new kernel.
Patches incorporate improvements between minor kernel revisions. In this section, I'll offer directions that work with most generic patches from http://www.kernel.org as well as patches provided by most distributions. However, the directories are different for Fedora Core 3 or later (we'll discuss this in the next annoyance). In general, here's what you do:
Now you're almost ready to configure and recompile your new kernel. However, you need to make sure your tools are suitable for the software you're compiling.
7.1.4. Sharpen Your Tools
If you need to recompile your kernel, the source code is not enough. You also need the right tools. First, there are the tools that do the actual work, such as the GNU C Compiler. They vary by distribution and by major kernel version (2.4 and 2.6). More information is available in the Changes file, in the Documentation subdirectory of your kernel source directory.
Then there are the packages that allow you to customize the kernel using graphical menus. Generally, these include the ncurses-devel library in the libncurses5-dev package for the lower-end menuconfig, and the TCL and TK libraries for the higher-end xconfig and kconfig menus. We'll look at these menus briefly in the next annoyance.
The ncurses-devel library is a good choice for a system that isn't running the X Window System, which is the case with many servers. Alternatively, there are three different menu configuration systems that take advantage of the X Window System GUI. If you use the GNOME desktop, find and install the GTK+ 2.0, Glib 2.0, or libglade 2.0 development libraries. The actual packages and their names vary by distribution. Alternatively, if you use the KDE desktop, download the QuickTime development libraries.