Hari's CornerHumour, comics, tech, law, software, reviews, essays, articles and HOWTOs intermingled with random philosophy now and then
Kernel re-compiling in Linux - general tips
Tutorials and HOWTOs by
Posted on Tue, Mar 20, 2007 at 22:11 IST (last updated: Wed, Oct 29, 2008 @ 21:52 IST)
The whens and the whysHere are some of the situations I can think of for compiling a custom configured kernel.
- 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.
- Your kernel needs to support a strange hardware setup where the default kernel just doesn't work.
- You have special performance requirements or you need a specific flag set on your kernel for a particular purpose.
- You want to do it purely as a learning exercise. In which case, you'd best conduct the experiment in a non-critical box.
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 forEven 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:
- A list of your hardware chipset models. This will greatly reduce guesswork on your part and you can avoid compiling unnecessary drivers.
- 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.
- 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).
- 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.
- 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.
- 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.
- 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.
- 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:
- 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.
- 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.
- The boot up process messages.
dmesgcan give some clues here. You should look for anything unusual or any error messages thrown up by the new kernel while booting up.
- 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.
- 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.