Hari's Corner

Humour, comics, tech, law, software, reviews, essays, articles and HOWTOs intermingled with random philosophy now and then

Kernel re-compiling in Linux - general tips

Filed under: Tutorials and HOWTOs by Hari
Posted on Tue, Mar 20, 2007 at 22:11 IST (last updated: Wed, Oct 29, 2008 @ 21:52 IST)

A lot of people new to Linux would have got the impression that every Linux user should learn how to recompile the Linux kernel to configure it to their needs. I've also noticed that a lot of Linux users tend to think that having the latest kernel is always a good thing.

Before you decide to get yourself a custom compiled kernel, you need to know why you need one in the first place. Here are some of the situations I can think of which might warrant a kernel reconfiguration and recompilation. Before you proceed with a kernel recompile, be absolutely sure of the process and then understand what exactly you're looking for in a new kernel.

This article is mainly targetted at fairly experienced Linux users who know the basics of building a new kernel, but don't know exactly what situations warrant a kernel recompile and how to approach the problem of building a kernel configuration that is fairly reliable.

The whens and the whys

Here are some of the situations I can think of for compiling a custom configured kernel.
  1. Your computer has a specific piece of hardware that's not supported by the default kernel which ships with your distribution. And you are sure that the Linux kernel does provide a driver module for it.
  2. Your kernel needs to support a strange hardware setup where the default kernel just doesn't work.
  3. You have special performance requirements or you need a specific flag set on your kernel for a particular purpose.
  4. You want to do it purely as a learning exercise. In which case, you'd best conduct the experiment in a non-critical box.
The trickiest part about compiling a custom kernel is knowing your hardware properly down to the chipset level. This is very critical because otherwise you'll be groping in the dark when choosing options in the make menuconfig (or the make xconfig) stage. You will definitely have to do some research on the web to find out the exact chipsets used by your hardware. Just knowing the model number or brand name is not enough. Lots of hardware models with different manufacturers tend to share the same chipsets.

What you should look out for

Even after this, there are some vital steps to building a working kernel. In most cases I'd advice building a kernel from an already existing kernel configuration provided by your distribution rather than using a vanilla kernel configuration provided by a kernel downloaded direct from kernel.org. That way you ensure that the customized kernel closely resembles the default kernel provided by your distribution along with the changes you need.

Before you begin, then, take stock of the following:
  1. A list of your hardware chipset models. This will greatly reduce guesswork on your part and you can avoid compiling unnecessary drivers.
  2. A list of your own requirements - for instance, video for Linux, MIDI support, OSS emulation for ALSA, support for special USB devices, support for large memory systems, support for RAID and so on.
  3. A list of must-have configuration settings. A typical example might be ACPI options. Or essential file system drivers. Or drivers for the hard disk controller chipset (which greatly improves DMA performance).
In case you decide to compile a fresh kernel from the vanilla setup, you need to make sure that:
  1. You have an existing kernel to fall back to, in case the new kernel you're building fails to boot properly. This is very important unless you don't mind the possibility of ending up with an unbootable machine.
  2. You go through each and every option in the "make xconfig" stage and double-check and triple-check it before running the compilation. I know this is a pain, but on more than one occasion I've been caught out by not checking every single option out there. It is time consuming and painful, but you also learn a lot this way.
  3. Most of the hardware drivers you've chosen are built as modules (M) rather than being compiled into the kernel itself. For some reason or the other I've found that modules are just better - autodetection of hardware is much more reliable this way.
  4. You keep a backup of the last working kernel configuration file after you find that you can successfully boot into Linux using the new kernel.
  5. Last but by no means least - make sure that the drivers for the filesystem you use on your Linux partition are compiled directly into your kernel (and not as modules) unless you rely on initrd. Otherwise your shiny new kernel will throw up a panic message and freeze the system while booting.

Working kernel - what next?

After you got a working custom kernel, you need to make sure that everything works as expected. Check for the following:
  1. Boot up time - if the booting time is significantly different from your older kernel, you should probably look closely at some of the startup messages.
  2. Unusual CPU usage - if you're experiencing a high CPU usage while "idling" the system, you might be missing some essential video drivers or hard disk drivers. You might be using some generic driver which utilizes the CPU more.
  3. The boot up process messages. dmesg can give some clues here. You should look for anything unusual or any error messages thrown up by the new kernel while booting up.
  4. Loaded kernel modules. This will give you a clue whether your hardware has been detected properly and the required drivers have been loaded correctly as modules. This will also let you know whether you've enable module dependency checking in the kernel.
  5. Broken drivers from a previous kernel setup. This can happen with the proprietary ATi or nVidia video drivers. In most cases, simply reinstalling the proprietary driver will fix the issue.
Even if everything looks fine at first, you should still keep your older kernel around for a while just to ensure that the setup is 100% correct and that the system is stable under all conditions.

Newer kernels?

My personal experience is that newer minor kernel versions do not offer anything significantly better in terms of performance or hardware support. This is particularly the case if you have an older machine. In most cases, you're better off using the stock kernel provided with your distribution unless you're 100% sure there's a new feature you absolutely need. Most desktop users will not need a new or custom compiled kernel.

However, over a period of time, once you're fairly familiar with your machine's setup and you really want to squeeze the maximum performance and hardware support from your Linux box, you can think about building a custom compiled version. In that case you'll have the advantage of knowing exactly what configuration you need - based on experience. For instance, on my own desktop machine, I'm very confident of the hardware setup because it was a hand-assembled machine. On the other hand, I'm still not 100% sure of the hardware chipsets on my laptop and therefore am less confident about building a custom kernel that meets its requirements.

Kernel configuration is easy to learn, but difficult to master. The limiting factor will be the lack of knowledge of hardware and system specifications rather than the process itself. So if something does work the first time, keep it.

With most Linux distributions providing a solid, working and reliable kernel setup 90% of the time, custom kernel compiling should be best left for the time when it's absolutely required.

4 comment(s)

  1. Very very nice article, Hari --- this misconception that the recompiled kernel is actually nirvana redefined is something that needs to be broken. And again a question: I think this article is top-notch publishable quality on newsforge, etc. Why didn't you try sending it there?

    Comment by Sudipta Chatterjee (visitor) on Wed, Mar 21, 2007 @ 13:42 IST #
  2. Thanks Sudipta. :smile: Yeah, I guess it could be linked somewhere. I don't exactly have the habit of submitting my own articles to other sites, but if it can be referenced from one of the news sites, why not?

    Comment by hari (blog owner) on Wed, Mar 21, 2007 @ 18:26 IST #
  3. Err... I was actually talking of getting money for publishing it on their newsletter/journal instead of having a link :DBut whatever suits you --- if I write something that I feel is really worth being read by many, I tend to do a self-referral on DesiPundit or Blogbharti, etc.

    Comment by Sudipta Chatterjee (visitor) on Fri, Mar 23, 2007 @ 00:53 IST #
  4. Ah, ok, thanks. I will do that next time I write an article such as this. :cool:

    Comment by hari (blog owner) on Fri, Mar 23, 2007 @ 07:55 IST #

Comments closed

The blog owner has closed further commenting on this entry.