Linux 2.6: Go Configure

We wrap up our series on the Linux 2.6 Kernel with a dive into the gnarly act of configuration and take a peek at patching the new kernel.

When we last talked about Linux 2.6 Kernel we left off at giving our new 2.6 kernel a unique name, so we can tell it apart from our other kernels. In this third, and final, salute to the new kernel, we'll get into the gnarly part  configuration (and we'll also cover patching kernels, so you'll know how to keep your new kernels up-to-date).

Configuration is the most tedious, time-consuming part of the process. Howerver, it's extremely important, so don't gloss over it. If you leave things out, you'll have to go through all this again.

Now you may think of yourself an old Linux pro, but the steps for building a 2.6 kernel are different than 2.4, so pay attention.

Before we leap into the fun stuff, we need to review a couple of items from Part 1 of our trilogy. Remember the command for unpacking the compressed kernel archive:

$ bzcat linux-2.6.3.tar.bz2 | tar -xvf -

Yes, this is the olden way, as a kind reader pointed out. Use it if you have an elderly tar that does not support bzip2 archives. Modern editions of tar support bzip2 directly. The modern way:

$ tar xvjf linux-2.6.3.tar.bz2

Part 1 says to use gcc 2.95.3. I have received reports of using gcc versions up to 3.3 successfully. Your mileage may vary.

Edit ../linux-2.6.3/Makefile to give the new kernel a unique name, like EXTRAVERSION =new-name

module-init-tools replaces modutils in the 2.6 kernel. You can have both on your system. And, in addition to being well-armed with printouts of lscpi and dmesg, it is also wise to capture lsusb:

$ lsusb -v | lpr

lsusb is part of usbutils.

Configuration
This is the most tedious, time-consuming part. Howerver, it's extremely important, so don't gloss over it. If you leave things out, you'll have to go through all this again. It is tempting to recycle your 2.4 .config, and run make oldconfig, but don't. The 2.4 and 2.6 kernels are quite different; this is asking for trouble.

Configure From Scratch
There are two nice graphical configuration utilities: menuconfig, and xconfig. menuconfig is ncurses-based, so you don't need X. xconfig in 2.6 requires Qt and X. Let's use xconfig, because it is sleek and fast, and completely redesigned for 2.6:

$ make xconfig

This will putter and mutter for a bit, then spit out a menu. Have your printouts handy because now you have to select the right drivers for your hardware, decide what features your kernel will have, and whether to load drivers as modules, or build them into the kernel. menuconfig and xconfig generate loads of information  read all of it. Many things will be selected by default. The worst thing that can happen by saying "yes" too many times is you'll enable features that won't be used. This is not a bad thing. In contrast, if you leave something out that you need, you may need to rebuild the kernel. Here are few things which should be built into the kernel:

Copy Kernel Image to /boot
Now your nice new kernel image must be moved to /boot, naming it whatever you like, I'll call mine bzImage-2.6.3-testkernel. The kernel name doesn't matter, as long as you tell your bootloader what it is.

# cp ~/src/arch/i386/boot/bzImage /boot/bzImage-2.6.3-testkernel

It is OK to stick with tradition, and call it vmlinuz-something, if you like. Now copy the new System.map:

Now you can reboot, select the new kernel, and start testing it. If it doesn't work, simply reboot to your stock kernel.

Applying a Kernel Patch
When it's time to upgrade to 2.6.4, you don't need to download the whole works. All that's necessary is to apply a patch, or perhaps several patches, then rebuild the kernel using make oldconfig, instead of make xconfig. Be sure to save a copy of your current .config file as .config.bak, or make mrproper will overwrite it. Download the patch to ~/src, then unpack and apply the patch:

$ bzip2 -dc ../patch-2.6.4-test1.bz2 | patch -p1

If there is more than one patch, apply them in order. Clean up the source tree, then build the new kernel:

$ make mrproper
$ make oldconfig

Then install the new kernel, and you're in business.

Kernel Building as an Ordinary User
Many docs tell you to unpack sources into /usr/src/, and do the configuration and build process as root. Don't do that. All you're doing is building a usable kernel image, which does not require root privileges. Remember the cardinal Unix rule: Use the least possible privileges for any job, it's safer. All you need superuser powers for are running make modules_install, copying the new kernel image to the boot directory, and editing the bootloader.

Resources
This is the most comprehensive kernel-building how-to I've ever seen, with an extensive section on configuration. It was sent to me by an awesome reader  thanks! Note that there is a section on 2.6 at the end: Compiling a Custom Linux Kernel
See also the extensive documentation in your kernel sources, under ../Documentation

Advertiser Disclosure:
Some of the products that appear on this site are from companies from which QuinStreet receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. QuinStreet does not include all companies or all types of products available in the marketplace.