October 31, 2014
 
 
RSSRSS feed

Custom Linux Kernels Trim Fat and Tune Performance - page 2

Why?

  • August 6, 2007
  • By Carla Schroder

You can get freshly-baked kernels and the latest patches from Kernel.org. These are called vanilla kernels because this is where the original, unmodified kernels live. Then you need to assemble your build environment. Both Fedora and Debian make this easy. On Fedora, install the Development Tools package group:

 # yum groupinstall 'Development Tools' 

You'll also want Qt:

 # yum install qt-devel 

On Debian use this command:

 # aptitude install build-essential libqt3-mt-dev qt3-dev-tools

The Documentation/Changes file in your unpacked source tarball gives you a basic list of applications that you need for a build environment. In fact you should invest a lot of time exploring the documentation that comes in the kernel tarball--there is a wealth of knowledge squirreled away in there.

When you download and unpack your new kernel sources don't put them in /usr/src, and pay no attention to all the people who tell you to do that. Create a directory in your home directory to keep your source trees in. The kernel README itself says:

"...put the kernel tarball in a directory where you have permissions (eg. your home directory)...Do NOT use the /usr/src/linux area! This area has a (usually incomplete) set of kernel headers that are used by the library header files. They should match the library, and not get messed up by whatever the kernel-du-jour happens to be."

I use /home/carla/kernel.

Unpack your kernel tarball with tar zxvf linux-2.6.22.tar.bz2, using your correct version of course. Then change to the top-level kernel source directory and open the Makefile in your favorite text editor. Change the EXTRAVERSION = line to something unique, like EXTRAVERSION = .1-carla.

Next, let's see what options the make command has:

 $ make help 

This is going to spit out a lot of information. Take some time to look it over. Read the Makefile itself, which is a plain-text file. Then do a bit of housecleaning:

 $ make mrproper

Read the output of make help to see what this does. It shouldn't be necessary at this stage, but it's cheap insurance and sometimes you inherit funky stuff.

Now we get to the fun part- configuring our new kernel-to-be:

 $ make xconfig

You'll see something like Figure 1.

This is the part that takes a lot of time. If you don't have a config file in your kernel source tree or supply one on purpose, xconfig will use your /boot/config-2.6.* file. This isn't a problem, but a good starting point. You can change anything you want anyway. Click the Help button to see how to use xconfig. Every configuration option has a description, and next week we'll review some of them.

Once you are happy with your configuration, run the make command with no options. This will take some time, maybe up to an hour or more. Then change to root and run these commands:

# make modules_install
# mkinitrd -o /boot/initrd-2.6.22.img
# cp ~/kernel/linux-2.6.22/arch/i386/boot/bzImage /boot/vmlinuz-2.6.22
# cp ~/kernel/linux-2.6.22/System.map /boot/System.map-2.6.22

arch/i386/boot/bzImage is your new kernel, and it must be copied to the /boot directory. Copy over the matching System.map, and your new initrd image should already be there.

Add all of this to your GRUB menu, reboot, and give it a whirl. This is an example menu.lst entry:

title homebrew 2.6.22 kernel 
root (hd0,0)
kernel /boot/vmlinuz-2.6.22 root=UUID=b099f554-db0b-45d4-843e-0d6a1c43ba44 ro
initrd /boot/initrd-2.6.22.img

The kernel names and initrd image names are arbitrary; you could call them anything you want, as long your menu.lst entries match. GRUB counts from zero, so /dev/hda1, which is the first partition on the first hard drive, equals (hd0,0) in menu.lst.

The root partition's UUID comes from running the blkid command:

$ blkid
/dev/sda1: UUID="b099f554-db0b-45d4-843e-0d6a1c43ba44" SEC_TYPE="ext2" TYPE="ext3"
/dev/hda1: UUID="1a5408ad-7d1d-4e24-b9db-d132d76e9e8e" SEC_TYPE="ext2" TYPE="ext3"

In this shiny new era of udev, you should use UUIDs to identify your block devices because /dev names are no longer static, but at the mercy of udev. You need to create an initrd image because the /dev directory is not populated until after boot, so there is no way (that I know of) to build the boot device into the kernel anymore.

Next time we'll learn the Debian and the Fedora way of customizing kernels, and review some of the meelyuns of kernel compilation options.

Resources

Sitemap | Contact Us