Smell of Fresh-Baked Kernels

Mon Dieu! François! Come out from under that table immédiatement! You are very lucky that our customers have not yet arrived. To see you hiding from the prospect of a kernel recompile. Qu'est-ce que je vai faire avec toi? Sit down and let me pour you a glass of wine to steady your nerves. There. Feeling better? Bien.

Log in and let me show you how easy it is. You know, François, that I have been collecting from other open-source chefs some wonderful recipes designed to make this whole kernel process that much more attractive to the palate, non? Quoi? Ah, mes amis. Welcome! François, what are you doing sitting there drinking? Show our guests to their seats. When you are done, bring up the 1996 Meursault Genevrieres from the cellar.

Pardon, mes amis. François and I were discussing the intricacies of Linux kernel builds. My faithful waiter was about to build his first kernel and, I must tell you, he is a little shy about the idea. It is for François and others like him that I have sought out some of the items on tonight's menu.

Building a kernel is not as much of an ordeal as it once was. Part of the reason, I must admit, is that the need to recompile your kernel is becoming less and less of a requirement for the average user. Out of the box, most modern distributions include support for more popular devices either in the kernel or through a collection of compile loadable modules. Still, there are times when the distributed kernel will not support your hardware. You may also need specific features that, while uncommon, are required in your environment.

This generally implies a requirement for the latest and greatest Linux has to offer. If you want to know what the latest version of the Linux kernel is, whether it is a stable release or a development version, try out the following finger command:

finger @finger.kernel.org

A few seconds later, the system responds with something like this:

[zeus.kernel.org]
The latest stable version of the Linux kernel is:
        2.2.17
The latest beta version of the Linux kernel is:
        2.4.0-test10
The latest prepatch (alpha) version *appears* to be:
        2.4.0-test11/pre5

Armed with the latest kernel information, you can now visit your favorite kernel source mirrors and download what you need. Notice that I said mirrors. Getting to your local mirror is pretty simple. All you have to do is squeeze your country code in between the “ftp” or “www” of kernel.org. For instance, assume for a moment that I am in Canada (country code “ca”). The addresses for the ftp and www sites would be as follows:

ftp.ca.kernel.org
www.ca.kernel.org

Similarly, if I were in France, I would use these mirrors:

ftp.fr.kernel.org
www.fr.kernel.org

Staying on top of all this can be a chore as well. You may have to follow kernel development quite closely (perhaps daily). Pretend for a moment that you have a new card that lets you input commands directly into your system via thought transmissions (Incroyable!) and kernel support is currently in development. Whatever your reasons, Darxus provides you with a nice little Perl script to help you out. It is called dlkern and is available from his web site (see Resources). With dlkern, you simply tell the script whether you want the stable version of the kernel (-s option), the development or beta version (-b option), or the pre-patch alpha version (-p option). That is all. Allow me to demonstrate. In the next example, I retrieve the latest stable kernel:

./dlkern -s -w

You'll notice that I used a -w option as well. This tells dlkern to use wget as the means of downloading my new kernel. The default is ncftpget. One or both of these programs is likely already on your system or included in your distribution. One quick note here; make sure you change the permissions on the script to executable (chmod 755 dlkern[). If you are indeed following the development of a specific driver, one option is to put dlkern into a crontab entry where the download can happen automatically (during the night or whenever makes sense).

So, now we have chosen and downloaded our kernel source distribution. The next step, of course, is to build the kernel. I realize that there are many documents explaining the steps to kernel compilations (other writers in this fine publication have and will, no doubt, cover it in the future). Nevertheless, to truly appreciate the work of our next chef, we should review the process briefly.

With source in hand, it is time to uncompress and extract that source. The usual and preferred location tends to be /usr/src. Kernels direct from any of the kernel.org mirrors tend to extract into a hierarchy called “Linux”. This would mean that your kernel sources lived in /usr/src/linux. However, you may find that /usr/src/linux is actually a symbolic link to where the actual kernel source lives. For instance, if I do an ls -l on one of my servers, I get something that looks like this:

# cd /usr/src
# ls -l linux
lrwxrwxrwx  1  1  root  11 Nov 14 1999 linux -> linux-2.2.5

Notice that it points to a directory called “linux-2.2.5”. If you want to extract directly from the source, start by renaming the link to something else, then extract the kernel. The tree will be called “Linux”. Now, change directory to the linux directory and type make config. Even before you type that command, I should tell you that this is the old, one might even say, classic, way of doing things. You will get a line-by-line question and answer session designed to help you through the configuration process for your new kernel. If you type make menuconfig, you will get a ncurses-based screen that is a bit friendlier, what you might call a GUI for the console set, non? The last option is make xconfig, which uses an X environment for building.

As I mentioned, this is the question and answer session. You decide what you want in your kernel by answering “Y” for yes, “N” for no and “M” for module. At any point in the process, you can ask for help if you don't know what a specific thing does. The kernel make process is pretty good at leading and helping out through this. If it tells you that you should include it, then do so.

Once this is done, you can actually go back and make some modifications if you want to double-check. In the /usr/src/linux directory, you will find a file called .config. Using pico, vi or whatever editor makes you happy, you can still make changes. Listing 1 is a sample of the .config file from a recent build.

Listing 1. Sample config File

The next step is to do a make depend (which handles all the dependencies and creates your Makefiles), followed by a make clean. If this is your first build, you will see messages claiming to be cleaning up and deleting files that aren't really there. Now, it's time to actually compile your kernel. You do this by executing make bzImage. This next step may take a while, depending on how fast your computer is, so consider sitting down with a nice Beaujolais while you wait. When all is done, you'll find your new kernel in the directory /usr/src/linux/arch/i386/boot. It is, as you might expect, called bzImage since that is what we told the system to make, non? Now, you want to include your new kernel image in LILO's list of bootable kernels. For this example, I built the 2.2.17 kernel directly from source. Once that was done, I used my vi editor to modify my /etc/lilo.conf file. Listing 2 shows what it looked like before I started.

Listing 2. /ect/lilo.conf File

You'll notice that I did not change anything else in this example. My default boot is still vmlinuz-2.2.14-5.0, which is the stock kernel that came with my system. The lines that start with image=/boot/vmlinuz-2.2.17 are the ones I added after the fact. I am now going to have my Linux system reread the configuration file by running this command:

/sbin/lilo

After LILO has worked its way through your /etc/lilo.conf file, it should come back with something like this:

Added linux *
Added linux-2.2.17

You can never run /sbin/lilo too many times, but you can run it too few. If you have made changes to your kernel or your /etc/lilo.conf file and you forget to run /sbin/lilo, your system will not boot. This is extremely important. If you are not sure whether you have run LILO, then run it again. Sometimes, I run it two or three times just to make sure. I joke, but only a bit, non?

We have only a couple of things left to do. Since you have, no doubt, defined several modules to include with your new kernel, you need to make them as well. You do this with the make modules command which you then follow up with make modules_install.

There you have it. All in all, it's not that the whole process is so complicated. It's just that there are quite a few things to remember, and forgetting that all-important LILO step can cost you a great deal of aggravation (not to mention that it could put a real dent in your wine cellar).

No matter what, building a kernel, for many (including François), is a daunting experience. This is where buildkernel comes into play. Written by William Stearns, this is a wonderful little (big) bourne shell script that pretty much automates the entire process. If you have local kernel source, it will use that, otherwise, buildkernel will download the latest stable kernel for you. You can, if you wish, ask the software to get the latest development version instead. It then extracts it, creates the appropriate links and starts the configuration process by launching make xconfig. Once you have decided what you want, your job is pretty much done.

Sometime after building the kernel modules, buildkernel will interrupt you and ask you to verify its changes to /etc/lilo.conf. It does this by putting you into your default editor and allowing you to make changes. Here's what it looks like at this point. This is not the whole file, but simply the changes added by buildkernel:

#The following boot section was added by
#buildkernel on Wed Nov 8 13:06:21 EST 2000
#Please feel free to move this section, edit it
#and remove these comments.
image=/boot/bzImage-2.2.17-1
        label=2.2.17-1
        root=/dev/hda1
        read-only
#End of autoinstall

Once you are happy with this, exit the editor and let the program continue. It will complete the installation of your new kernel, run LILO and that will be that. No need to worry about whether you forgot some steps. Oui, it is true. Despite my assurances that I personally watched as buildkernel ran LILO, I still ran it again.

When you look at the resultant /etc/lilo.conf file, notice that the default boot configuration is your old kernel—buildkernel has left that intact. Merci. Now, to book your new kernel, simply shut down your system and type (in the case of my example above) 2.2.17-1 at the LILO prompt.

There are some parameters that you may be wise to pre-set. These are in a control (or config) file called /etc/bkrc, and they allow you to select defaults such as your local mirror download site (BKFTPSITE), the type of image (BKBUILDTYPE), or whether you want to use the stable or development kernels (BKKERNELTOBUILD).

It seems that closing time has arrived very quickly. Mon Dieu! Once again, I want to thank you all for visiting my restaurant. François, please, another glass of wine for our friends. As you can see, working with the Linux kernel need not be a frightening experience. With a little help from dedicated open-source chefs around the world, anybody can sample the Linux kernel up close and personal. Even François.

Until next time, your table will always be waiting here at Chez Marcel.

 vôtre santé! Bon appétit!

Resources