Great Kernel Guide

The act of compiling a new kernel isn’t as difficult as many people expect. For the most part, you select your kernel options, compile it, copy a few files to appropriate locations, and you’re good to go. The hard part lies in knowing what you need.

I’ve successfully compiled a few kernels for Slackware-based servers in the past. However, building the config file takes time. I’ve always thought it would be a heck of a lot easier to just use the same configure file I used when I first installed the OS rather than having to start from scratch. Given I’m building a new kernel for my new firewall box, I dug for an answer.

That’s when I found JustLinux’s Kernel Compilation guide and the following paragraph:

[make oldconfig] looks in your /usr/src/linux directory for a file named .config This file contains all the compilation options you chose the last time you compiled your kernel. So if you are simply upgrading your kernel, and have the same requirements from your kernel, you can simply use this option to load your default values. Just make sure that your .config file from your old kernel source tree is copied into your new kernel source tree, and you will be able to apply the same values you compiled into your last kernel.

That certainly made my life a lot easier! I found the .config file in the old kernel’s directory with a simple ls -a. Why I hadn’t spotted it before I’ll never know. Gotta love it when a computer makes you feel stupid. I learned kernel compilation from a book, and unfortunately it didn’t mention this option.

I use make menuconfig on the command line to build my server kernels (I don’t put GUIs on ‘em), so rather than using make oldconfig above, I ran make menuconfig and selected the option to load another configuration file. I simply pointed to the .config file in the old tree. This way I could verify the info and make any desired changes without having to exit the menu screen.

The full kernel compilation procedure is outlined in the guide and is very easy to follow. While it was written when 2.2.x kernels were current, it’s still valid for 2.4.x. Things may have changed for 2.6.x, I’m not sure.

The last question is “why build your own kernel?” There are a number reasons: performance, to add support for specialized hardware or network configurations, to strip support for hardware you’ll never use (ie, PCMCIA on a desktop, vid4lin on a GUI-less server), the list goes on.

Remember, this is Linux. It’s YOUR box. Feel free to experiment!