Smell of Fresh-Baked Kernels

With some tips from our French chef, and a glass of wine or two, compiling is a manageable task.

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

This assumes, of course, that you are
currently connected to the Internet. I see
that one of our diners is putting up their hands and mouthing the
word always. Bravo, mon
ami.

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:

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:

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.

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.

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

Here is a quick tip from the kitchen, mes
amis. From time to time, I have been known to say that
too much garlic in a Caesar salad is impossible. I joke, but you
understand, non? I tell you this so that you
will better understand the following statement.

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:

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.

Marcel
Gagé lives in Mississauga, Ontario. In real life,
he is president of Salmar Consulting Inc., a systems integration
and network consulting firm. He is also a pilot, writes science
fiction and fantasy, and edits TransVersions, a science fiction,
fantasy and horror magazine (now an anthology). He loves Linux and
all flavors of UNIX and will even admit it in public. In fact, he
has just finished writing Linux System Administration: A
User's Guide, coming soon from Addison-Wesley Longman.
He can be reached via e-mail at mggagne@salmar.com. You can
discover a lot of other things from his web site at
http://www.salmar.com/marcel/.

Trending Topics

Upcoming Webinar

Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report

August 27, 2015
12:00 PM CDT

DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.