Preparing to build your first Linux kernel

Today we have a brief article covering the basics of preparing to compile a Linux kernel. This is by no means a definitive guide for building a kernel. For that there is the recently updated (Jan., 2002) Linux Kernel How-to, by Brian Ward, which can be found here:

As it turns out, much of what I have learned about building a Linux kernel I learned through trial and error. I bet that I built over 10 kernels on my old 486SX-25 before I ever got one to boot. If I remember correctly, it took something like 3 or 4 hours to compile a kernel on that machine…. imagine my disappointment when it wouldn’t boot!

Now, I can compile a kernel in about three minutes (not including the time it takes to configure, of course!) on my current machine (dual PIII 1Ghz w/ 1.5Gb RAM ;), so I am much more willing to try new things with the kernel. It still takes over an hour on my laptop (266Mhz w/96M RAM), so I am a little more selective about what I will try.

Before we get too far, let’s take a look at what exactly the kernel is. The Linux kernel is the core of the Linux operating system. The file systems are defined here, most of your hardware drivers are found here, and the lowest level services, such as TCP/IP, PPP, routing, and so on, are defined here. In other words, it is the software that interprets instructions from higher level software into instructions that your specific hardware can understand.

If you are running fairly new hardware (600Mhz+ with 128Mb+RAM) and it is not busy running other applications, you should be able to compile a kernel in a reasonably short amount of time (under a half an hour).

Before we get started with the nuts and bolts of building a kernel, let’s take a look at why you may want/need to build a new kernel. The most obvious reason to build a new kernel is to add new hardware to your system. You may also need services such as SCSI emulation for CD burning or IP tables and IP filters for firewalls configured into the kernel. I learned early on that immediately following an installation there were features configured into the OEM kernel which I did not need and options that were not configured that I did need.

Once you have decided that you do need to build a new kernel, document all of your hardware. You will have to have intimate knowledge of your hardware when you configure your new kernel. Rather than waste time building kernel after kernel because you cannot get yours to boot, try to know exactly what you are building your kernel for, and what you hope to accomplish.

If you happen to be running Windows (in a dual boot configuration or through removable drives), there is an excellent program by SiSoft called Sandra that will tell you more than you probably need to know about your hardware. SiSoft’s Sandra Standard is a free download and can be found here: With Windows, you can also look at all of the entries in Device Manager, although they will not provide as much information as Sandra.

On the other hand, if you are already running Linux with KDE, you can look in the Control Center in the information section for your hardware. You can also run ‘lsmod’ from the command line. This will list all of the modules currently installed in your kernel.

This brings me to an interesting point. For each kernel configuration option, you will be presented with one of three choices (we will discuss the methods of configuration later :). You can either build the option into the kernel itself, not build it at all, or build it as a module. A module is a piece of code that can be inserted into the kernel after it is already running. On a side note, many device drivers can be compiled as module and inserted into a running kernel with ‘insmod’, rather than compiling an entire kernel.

The reason that you would want to use modules is to keep the size of the kernel small. If you go through and select ‘Y’ for all of your options, you are going to have a *huge*, hard to manage kernel. You will also make a kernel that is too big to fit on a floppy disk. In other words, you will not be able to make a boot floppy with that kernel. Keep in mind that the smaller the kernel, the faster it will run (under most circumstances).

In order to build a kernel, you will need the kernel source code. Normally this will come with your distribution. For your first kernel, I recommend building a kernel that is the same version as what your distribution includes. This is to avoid any compatibility problems between software you have already installed and the version of the kernel that it supports. After you have compiled a few kernels, you will know what your problem areas are and you will be able to work through these situations.

It is important to take a look at the versioning system that is used for the Linux kernel. All Linux kernels are given a version number that comprises three integers, X.Y.Z. The first number (X) is the major version number, the second number (Y) is the minor version number and the last number (Z) is the patch level.

The minor version number is an important one to take a look at. If it is an odd number, then the kernel is an experimental (or “beta”) kernel. For instance, before the 2.4.Z kernels were officially released, the development kernels that were implementing the features of the 2.4 kernel were 2.3.Z kernels. For your first kernel, steer clear of any unstable (beta) kernel versions.

Linux distributions commonly patch (change and/or add code to some of the source code) the kernel for their respective distributions. For this reason, I recommend that you use a kernel version available from your distribution, rather than one from .

A good example of this is the kernel that is included with RedHat 7.2. When I installed RedHat 7.2, I installed with the ext3 file system. As it turns out, the version of the kernel that I wanted to upgrade to (I believe it was 2.4.12…) had to be patched to offer support for the ext3 file system. However, there was a version of the kernel available from RedHat’s FTP site that was newer than the kernel that I had and was already patched by RedHat to support the ext3 file system.

Let me also note that not all distributions patch their kernels. In those cases (Debian, Slackware, etc…) it is perfectly fine to use a standard Linux kernel from Simply put, be aware that a standard Linux kernel may not offer features that your distribution has incorporated into their version(s) of the kernel. Check your distribution’s documentation to verify. Those that I know of that do patch their kernels (and this is *not* an exhaustive list) are RedHat, Mandrake, and SuSE. I am sure that there are many others.

In our next issue, we will take a look at configuring and building the kernel, and setting up your machine to boot from it.