Obtaining a Kernel

All Linux distributions ship with a binary Linux kernel (or several kernels with different optimizations), and in most cases the kernel source code is also available. You can use your distribution-provided kernel source code if you like, and doing so has certain advantages. Distribution providers sometimes apply kernel patches—code that's not part of the original program but that improves or extends it in some way. It's possible your system relies on such patches to operate or to provide some function, such as drivers for an exotic piece of hardware. On the other hand, distribution-provided source code can be a problem for the same reason. Patches might contain bugs that aren't present in the official kernel source code, and they can create confusion if you go to others to get help, should a problem be related to a patch.

On the whole, I favor using the original unmodified Linux kernel source code. You can obtain this code from http://www.kernel.org or its mirrors; click the links to enter the archive areas and download the package. You should download a file whose name takes the form Iinux-a.£>.c.tar.bz2 or linux-a.£>.c.tar.gz. This file holds the source code for kernel version a.b.c compressed with bzip2 or gzip, as indicated by the extension. (The sidebar, "Kernel Version Numbering," describes how Linux kernels are numbered.)

Given the importance of the kernel, you may want to verify its integrity using the gpg utility. To do so, you must download a signature file along with the kernel. This file has the same name as your kernel file but adds an extension of .sign. Once you've downloaded the kernel and its signature file, type the following commands:

$ gpg -keyserverwwwkeys.pgp.net -recv-keys 0x517D0F0E

gpg: keyring 7home/rodsmith/.gnupg/secring.gpg' created gpg: /home/rodsmith/.gnupg/trustdb.gpg: trustdb created gpg: key 517D0F0E: public key "Linux Kernel Archives Verification Key <[email protected]> " imported gpg: Total number processed: 1 gpg: imported: 1

$ gpg -verify Iinux-a.£.c.tar.bz2.sign Iinux-a.fc>.c.tar.bz2

gpg: Signature made Mon 07 Apr 2003 01:59:12 PM EDT using DSA key ID 517D0F0E gpg: Good signature from "Linux Kernel Archives Verification Key <[email protected]>"

gpg: checking the trustdb gpg: no ultimately trusted keys found gpg: WARNING: This key is not certified with a trusted signature!

gpg: There is no indication that the signature belongs to the owner.

Primary key fingerprint: C75D C40A 11D7 AF88 9981 ED5B C86B A06A 517D OFOE

The first command loads a key from wwwkeys.pgp.net as a baseline for comparison with the kernel's key. Be sure to type the key number (0x517D0F0E) correctly; if you mistype it, the next command won't work. You only need to type this command once; if you want to check multiple kernels, you don't need to type the command again. The second command (modified for your kernel, of course) checks the kernel's cryptographic signature. In this example, the Good signature message verifies that the signature and the actual file you downloaded match the information from wwwkeys.pgp.net. The warning message concerning the lack of a trusted signature certification relates to very high criterion of trust and shouldn't concern you unless you're building a very high-security system. Unless a miscreant manages to compromise the kernel you download, its accompanying signature key, and the signature file from wwwkeys.pgp.net, the Good signature message is sufficient indication of authenticity. Once you've downloaded the kernel tarball, extract it with a command like this:

Replace the j in xvjf with z if you downloaded a file that was compressed with gzip. This action creates a directory called linux-a.b.c. Typically, you type this command from the /usr/src directory, which is why I specified the root command prompt (#); normally, only root can write to this directory. If you make/usr/src writeable to all users, or at least to your own ordinary account, you can issue this command as an ordinary user. Another option is to extract the file in your home directory. In any case, you may want to simplify access by creating a symbolic link to the directory using the name linux: In -s linux-a.Jb.c linux. (If you store the source code in your home directory, you must still type this command as root and adjust the source path appropriately.) Red Hat 8.0 and 9.0 use a link called linux-2.4 rather than linux, so you may need to use linux-2.4 instead of or in addition to linux if you're using Red Hat. If this link already exists (most likely pointing to an older kernel source directory), you should delete it first.

If necessary, you can download and install kernel patches. You might do this to use a very new hardware device or a development filesystem driver. Such projects include instructions on how to proceed. These instructions can vary somewhat from one project to another, so you should follow the directions for your particular patch.

Note Although in most cases the latest stable kernel is the most appropriate one, on rare occasions you may want to use another kernel. For instance, an earlier kernel may be most compatible with a patch or be more stable for a specific purpose. Check resources such as http://kt.zork.net/kernel-traffic/ or http://www.ussg.iu.edu/hypermail/linux/kernel/ for summaries and archives of Linux kernel mailing lists that may be relevant to discovering and working around such problems.

Kernel Version Numbering

Linux kernel numbering follows a precisely defined pattern. The kernel version number has three components—a.b.c, as in 2.5.67, which have the following meanings:

• The a component is the major version number. Changes to this number are quite rare. In mid-2003, this number is 2, and it's been at that level since 1996.

• The b component denotes major changes to the kernel's features or architecture. Even b numbers denote stable or release software. Such kernels are considered safe for use in production environments, at least when they're released. (Of course, bugs are sometimes found and corrected even in release kernels.) Odd b numbers signify development kernels. Kernel developers add new features to these kernels, make changes to internal kernel data structures, and so on. Development kernels, therefore, tend to be unsafe for use on production systems.

• The c component denotes changes made within a stable or development kernel series. For stable software, these numbers increase with bug fixes and occasionally with the addition of important new (but stable) drivers. For the development branch, the c number increases with bug fixes, new features, or other important changes. As the development kernel matures, it's eventually declared stable, its b value is incremented, and it becomes the basis for the next stable kernel.

As a general rule, you should use the kernel with the highest available evalué in the highest-numbered stable kernel line. There are exceptions to this rule, though. For instance, if you need a new feature that's available only in a development kernel, you may have no choice but to use it. If you want to contribute to kernel development, you must obviously use the development kernel. Near the end of a development kernel series, the kernel tends to become useable, and in fact the general consensus is that development kernels as I write (the latest is 2.5.67) are very stable.

Prior to the official release of a new kernel, a number of development "snapshots" are distributed among kernel developers. You may occasionally run across such kernels. For instance, distributions occasionally use these kernels, and so may appear to have more recent kernels than the latest made available from http://www.kernel.org.

Team LiB

0 0

Post a comment