Notes on Customizing the Kernel

1. The Linux Kernel Archives is the official repository of Linux kernel source trees. If you are moving from one version to the next, it is simpler to patch your existing source tree. Otherwise it is easier to download the new source tree for the version you want to install.

   Note the increase in size of the kernel files as the release numbers increase. This is an illustration of code bloat, which is endemic to computer software as new features and support for new hardware are added. One major reason for re-building your kernel is to reduce the negative impact of code bloat by tailoring the kernel to match your needs.

2. Since kernel source tree tarball sizes are in excess of 2³² bits, it is to be expected that downloads may occasionally be corrupt. In order to verify your download, you should check the signature against the one from the archive. For example, if you downloaded linux-2.6.37.tar.bz2, you should also download linux-2.6.37.tar.bz2.sign and execute the following commands:

   gpg --keyserver wwwkeys.pgp.net --recv-keys 0x517D0F0E
   gpg --verify linux-2.6.37.tar.bz2.sign linux-2.6.37.tar.bz2

   If you see a message like 'gpg: Good signature from "Linux Kernel Archives Verification Key "', the download was successful. Otherwise you should remove the source tree tarball and start over.

   If there is a question about the correctness of the public key, see http://www.kernel.org/signature.html.

3. Compressed kernel images are stored in /boot, along with corresponding system symbol maps. It is a good idea to store a copy of the kernel configuration file for each image there as well. This allows a quick feature check for each image you might want to boot.

   Kernel modules are used to reduce memory requirements; they are only loaded as needed. They are stored in /lib/modules, with a seperate sub-directory for each kernel version. Modules can be loaded and removed manually with insmod and rmmod, but usually one uses the modprobe command so that all the required modules are loaded at once. Both insmod and modprobe allow the setting of module parameters, but unless you are playing or debugging, module parameters are usually stored in /etc/modules.conf:

   options (module-name, without the ".ko") (parameters)

   Note that in order to build a kernel, the root filesystem must be mounted writable since both /boot and /lib are written to.
4. The following commands, issued at the top level of the kernel source tree (often /usr/src/linux-(version)), will perform a complete kernel build:

   make mrproper
   cp /boot/config-2.6.32.full .config
   make menuconfig
   cp .config /boot/config-custom
   (make) 2>&1 | tee ../kernel.log
   cp arch/i386/boot/bzImage /boot/bzImage-custom
   cp System.map /boot/System.map-custom
   (make modules_install) 2>&1 | tee -a ../kernel.log
   

   These commands assume that you wish to modify the existing kernel configuration (stored in /boot/config-lfsgeneral). It is always a good idea to make relatively few changes at a time to an existing, tested configuration.

   The make targets perform the following actions on the kernel source tree:

   • mrproper - cleans up the source tree in preparation for an entirely new build
   • menuconfig - configuration of kernel parameters
   • (no target) - compiles, links and compresses the kernel
   • modules_install - copies the modules into /lib/modules and runs depmod to determine module dependencies for modprobe

5. In general, it's safest to avoid kernel configuration parameters which are labeled "Experimental". Otherwise, the most important thing is to make sure that your hardware is supported by your configuration.

   Some options must be selected to be built-in, ie., not as a module. This includes any support necessary to access your root filesystem (ie., Enable the block layer, Device Drivers - ATA/ATAPI/MFM/RLL support with its subcategories generic ATA/ATAPI disk support and ATA disk dupport, and any chipset support required).

   Some hardware seems to work best built-in, but if you build it as a module you have the option to play with parameters without rebooting, which can be a real benefit if you're having trouble getting it working. And some parameters are not available as modules; these must either be built-in in order to function properly, or are parameters which do not involve additional code.

   A few configuration parameters deserve additional comment:

   • General Setup - Prompt for development and/or incomplete code/drivers - you need to select this option if you need any of the experimental drivers, or if you want to be able to use the "Magic SysRq key" (see below);
   • General Setup - enable at least Support for paging of anonymous memory (swap) and System V IPC;
   • you want to select Enable loadable module support and Module unloading; otherwise your kernel will not be able to use modules;
   • Processor Type and Features - you will not be able to run this kernel on any "lower" processor type (ie., if you choose Pentium II you will not be able to run it on a Pentium); in general you want to enable all options which apply to your hardware;
   • Bus options (PCI etc.) - once again, enable all options which apply to your hardware; make sure PCI support is built-in, not a module;
   • Executable file formats - enable Kernel support for ELF binaries; ELF is the standard format for all executable programs in Linux;
   • Networking support - again, enable all devices which you might ever use as modules; under Networking Options, enable Packet socket, Unix domain sockets, TCP/IP networking and any other protocols in use on your LAN; also Network packet filtering framework (Netfilter) and all of its sub-options as modules;
   • Device Drivers

     In general, enable all devices which you might ever use as modules; in particular,

     • Block Devices - Loopback device support - needed for mount -o loop;
     • ATA/ATAPI/MFM/RLL support - enable all options which apply to your motherboard/chip set; if you fail to do this, you may not, for instance, be able to use DMA on your ATA devices; also Include IDE/ATAPI CDROM support;
     • SCSI device support - SCSI device support, SCSI disk support and SCSI CDROM support - also need these in order to use USB flash drives;
     • Network device support and any drivers for your NIC(s);
     • Input device support - probably Mouse interface, Mice - PS/2 mouse and any other devices you might want to use as modules;
     • Character devices - Virtual terminal, Unix98 PTY support, Legacy (BSD) PTY support (needed for xterm);
     • Graphics support - /dev/agpgart (AGP Support) and Direct Rendering Manager (XFree86 4.1.0 and higher DRI support) (and any appropriate drivers under these categories);
     • Sound card support - probably Advanced Linux Sound Architecture and your particular hardware as modules;
     • USB support - at least Support for Host-side USB, USB device filesystem, EHCI HCD (USB 2.0) support and either OHCI HCD support or UHCI HCD (most Intel and VIA) support depending on your hardware; USB Mass Storage support in order to use flash drives, and any other modules you might ever want to use;

   • File systems
     • Second extended fs support - since we've installed all our Linux filesystems as ext2, you need this; and it can't be a module;
     • CD-ROM/DVD Filesystems - ISO 9660 CDROM file system support - you need this in order to read any CD-ROM; Microsoft Joliet CDROM extensions is a pretty good idea as well;
     • DOS/FAT/NT Filesystems - enable all as modules, except possibly NTFS support;
     • Pseudo filesystems - /proc file system support - can't imagine you'd want to run a Linux system without /proc;
     • Native Language Support - at least Codepage 437 (United States, Canada) and NLS ISO 8859-1 (Latin 1; Western European Languages) as modules;

     and any other filesystem types you may have lying around;
   • Kernel hacking - you probably want Magic SysRq key support; it allows you to use the following keystrokes in case of catastrophic failure:
     • ALT-SysRq-s - tells the kernel to attempt to sync all mounted filesystems
     • ALT-SysRq-u - tells the kernel to attempt to remount all mounted filesystems readonly
     • ALT-SysRq-b - tells the kernel to attempt to reboot

   There is help available for the vast majority of configuration parameters, and you can learn a great deal about how the kernel works by reading it!
6. Be sure to update /boot/grub/grub.cfg or menu.lst (on sdb5 in our lab) to include your new kernel.

   There are several kernel boot options which may be useful:

   • noapic - some Advanced Programmable Interrupt Controllers are problematic...
   • nolapic - ditto
   • ramdisk_size=(Kb) - to change the size of RAM disks
   • ro - mount the root filesystem readonly (if it is usually mounted writeable on startup)
   • root= - allows you to specify which device is the root filesystem
   • S - init single user mode

   See /usr/src/linux-2.6.37/Documentation/kernel-parameters.txt for more options.
7. EXERCISES on Customizing the Kernel:
   1. Build the 2.6.37 kernel.
   2. Add a grub menu entry (as we did in week 2) and boot your new kernel. Compare the log entries from this boot with the one from your 2.6.32 boot (use diff).
   3. Execute an lsmod to list the modules now loaded.

©2012, Kenneth R. Koehler. All Rights Reserved. This document may be freely reproduced provided that this copyright notice is included.

Please send comments or suggestions to the author.