I regularly speak to Linux users wanting to roll their own kernels. There are various reasons to do this, including getting accurate support for your hardware. In 2004 I wrote a guide to kernel compiling on the now deserted International Linux Community user’s board. I’m bringing it over to my blog in the hopes of helping more Linux users get into the habit of rolling their own. Herewith the guide:
Rolling your own Linux kernel
This guide refers to 2.6 kernels, compilation of 2.4 or earlier kernels are different.
No matter what Linux distribution you use compiling your own kernel will always be of benefit, unless you have no idea what you’re doing and b0rk it up completely. I recommend compiling your first kernel using the vanilla kernel sources that will work with any true Linux distribution. Kernel compiling is fool proof and WILL NOT BREAK YOUR SYSTEM if you follow this guide properly and keep your older, working kernels available as a backup. Patience is required, however, and nobody does this right the first time. But it is worth being patient and compiling your own, working kernel is not only very satisfying, but also makes for a better computing experience.
Step 1 – Learn Stuff!
The first thing you want to do is find out as much as you can about your system and what it requires from the Linux kernel. This means gathering all your computer manuals together and using Google. What you’re looking for, primarily, is what chipsets are utilised by your various pieces of hardware. For example, your motherboard may be manufactured by ASUS, but the on-board audio could use a VIA chip-set. Your specific chip-sets may not be supported by the Linux kernel but they may be compatible with other sets that are. So you need to track all of these down.
A useful tool for detecting the chipsets installed in your computer is lspci:
Running the above command will provide you with a list of detected chipsets and controllers in your box. This information is useful for finding out what kernel modules to compile or when asking gurus for help, so keep it handy.
There are volumes of writing about the kernel and its modules – how it all works and how to integrate your hardware into it, so read as much as you can, or jump straight into your first compile and spend time reading the information provided in the kernel configuration menu (we’re getting to that). For loads of info checkout The Linux Documentation Project.
Reading up on the kernel might seem like a tedious process but will help to make compiling your own kernel a breeze. This is beneficial knowledge to you anyway and will not go to waste.
Step 2 – Procure the Source!
The first thing you need to compile a kernel is a set of source files. The best place to grab this from is http://www.kernel.org/ – this is where the ‘vanilla’ (or pure) kernel source originates from and what all other Linux kernels are based on. Download the latest stable version of the source (126.96.36.199 at time of writing) and download the tarball.
You can also acquire source in different distributions of Linux using your package manager (like urpmi in Mandrake, apt in Ubuntu or Portage in Gentoo).
Once you have downloaded your kernel source you need to untar it to the directory /usr/src/ – a sub-directory will be created that looks something like this: /usr/src/kernel-188.8.131.52 (this directory will show up after you emerge source or use urpmi to acquire it).
Now the source is with you and you’re ready to roll!
A quick note concerning patience: You will most likely not produce a working kernel on your first attempt. Chill out – no one does. You will not break your system if you do this properly – your old working kernel will still be there for you to boot back into.
Step 3 – Lets Get Rolling…
Ok, time to get down to business. Execute the following from your terminal:
$ cd /usr/src/linux-2.6.8 (or whatever you have)
# make mrproper
This is the first step in preparing your kernel source. The command make mrproper will never have to be repeated again, you only need to do this on your first compile (unless you download new source).
Next, we continue to prepare our source and then start configuring the kernel:
# make clean
# make menuconfig
If you have X running you can use xconfig instead of menuconfig – either way is good, but I prefer menuconfig from the CLI.
In the config script you will be presented with a menu for the different sections of kernel configuration. You’ll notice that you can bring up help pages for each section and module that will explain what they are used for. It’s now time to tell the kernel all about your system. Go through the various sections and select the CPU you have and other chipsets that must be supported. This is where all that knowledge of your system’s hardware comes in to play.
Now, you’ll notice that you can specify the various modules as either being built into your kernel or as a separate module. If something is built into your kernel it will always start up with your system (or try to, at least). If it is a separate module it can be loaded only when necessary.
So if you know something works and will always be present in your system build it straight into the kernel. If it is something you are not sure of, or pertains to a piece of hardware that might not always be attached, build it as a separate module. You’ll notice that some things must be built into the kernel though and other things run better as separate modules. Pay attention to the help text for each module.
At this point it is important to note that some distributions require different things from the kernel, especially when it comes to initial ram disks. So visit your chosen distribution’s website or forums and ask around so you get these things right.
Once you are done configuring, exit the menu and save your configuration. This will be saved to a file called .config in the /usr/src/linux-184.108.40.206 (or whatever source you’re using) directory. The .config file can be used in the future to compile updated kernels or to make changes, so you won’t have to do the whole thing again. Warning: the ‘make mrproper’ command will wipe out your .config! I always back mine up somewhere, although remember that you will not have to run that command again if only making changes to a kernel of the given version.
Step 4 – Watch it go!
With the .config file ready, it’s time to do the actual compiling bit. All you have to do is:
And watch it go! This could take between 5 and 25 minutes – depending on your processor and how much you’ve put into the kernel.
Once the compile is finished, you need to do the following:
# make modules_install
This will install all the separate modules that aren’t being compiled directly into the kernel.
Tada! You now have a file called /usr/src/linux-2.6.8/arch/i386/boot/bzImage. The bzImage is your actual kernel.
Step 5 - Boot Into Your New Kernel
All the kernel images (bzImage) files are stored in the /boot directory. Look in that directory and your old kernel should be hiding. If, however, the directory appears empty, a mount might be required (/dev/hda1 might be where all your /boot images are hiding). So mount it, and then copy your new kernel into /boot.
You can rename bzImage to anything you want, so give it a different name from your old kernel, and keep them both in /boot in case something goes wrong and you need to boot back into your old kernel environment.
You now need to configure your boot loader, either Grub or Lilo. The two are very different and I will not handle configuring them here as there is ample information available online already, so use Google, forums, etc. to find out how to configure your bootloader. This is important and if you mess it up you might not be able to boot. So be pedantic about your bootloader and do it right. It’s not difficult.
When compiling your bootloader be sure to keep your old kernel on the boot menu, so that if the new kernel bombs out you can reboot and select the old, working kernel. Once you are back to the old kernel, you can repeat the configuration and compiling steps to fix the newer kernel.
And that’s about it! If all went well you should now have a new, working kernel. If not (usually the case first time round) then boot into your old kernel. Tweak, tweak, tweak. You kernel’s .config file is there to be worked on. With the help of Google, forums and other users you’ll get it right eventually and the end result will be an all-round better computing experience.