Skip to main content

By clicking Submit, you agree to the developerWorks terms of use.

The first time you sign into developerWorks, a profile is created for you. Select information in your profile (name, country/region, and company) is displayed to the public and will accompany any content you post. You may update your IBM account at any time.

All information submitted is secure.

  • Close [x]

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerworks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

By clicking Submit, you agree to the developerWorks terms of use.

All information submitted is secure.

  • Close [x]

developerWorks Community:

  • Close [x]

LPI exam 102 prep: Kernel

Junior Level Administration (LPIC-1) topic 105

Ian Shields, Senior Programmer, IBM
Ian Shields
Ian Shields works on a multitude of Linux projects for the developerWorks Linux zone. He is a Senior Programmer at IBM at the Research Triangle Park, NC. He joined IBM in Canberra, Australia, as a Systems Engineer in 1973, and has since worked on communications systems and pervasive computing in Montreal, Canada, and RTP, NC. He has several patents. His undergraduate degree is in pure mathematics and philosophy from the Australian National University. He has an M.S. and Ph.D. in computer science from North Carolina State University. You can contact Ian at
(An IBM developerWorks Contributing Author)

Summary:  In this tutorial, Ian Shields begins preparing you to take the Linux Professional Institute® Junior Level Administration (LPIC-1) Exam 102. In this first in a series of nine tutorials, Ian introduces you to the kernel on Linux®. By the end of this tutorial, you will know how to build, install, and query a Linux kernel and its kernel modules.

View more content in this series

Date:  21 Mar 2006
Level:  Intermediate PDF:  A4 and Letter (416 KB | 22 pages)Get Adobe® Reader®


Customize and build kernels and kernel modules

This section covers material for topic 1.105.2 for the Junior Level Administration (LPIC-1) exam 102. The topic has a weight of 3.

In this section, learn how to:

  • Customize the current kernel configuration
  • Build a new kernel and appropriate kernel modules
  • Install a new kernel and any modules
  • Ensure that the boot manager can locate the new kernel and associated files

As you learned in the previous section, Runtime kernel management, the kernel provides the low-level support for your system hardware and file systems. A modern kernel image usually contains only essential functions, but is configured to support additional functions that you might need through the use of kernel modules. The additional support is loaded only when needed, for example when a device is plugged in or otherwise enabled.

The modular code becomes an integral part of the kernel, dynamically extending the kernel functions. If the functions of a loaded kernel module have not been used for several minutes, the kernel can voluntarily disassociate it from the rest of the kernel and unload it from memory through a process known as autocleaning.

Without kernel modules, your running kernel, which is loaded from disk as a single binary file, would have to contain all the functionality you might possibly ever need. You would also need to build a completely new kernel every time you wanted to add functionality to your system.

You cannot put everything in a module, however. At a bare minimum, the kernel image that is loaded must be able to mount your root file system. But, as you learned in the tutorial "LPI exam 101 prep (topic 102): Linux installation and package management," your boot loader can load an initial RAM disk (or initrd), which may contain the modules necessary to mount the root file system. Nevertheless, the kernel image must at least contain support for the RAM file system used in the initial RAM disk. If it does not, your system will not boot.

Once your system has bootstrapped itself this far, it proceeds to mount the root file system and then start the other initialization processes. After a few seconds, the system is up and ready for you to use. The kernel, however, remains in control awaiting requests to perform work for user processes and scheduling the system resources among the tasks that require them.

Modular kernels work well in modern systems with plenty of RAM and disk space. However, you may have a new piece of hardware, such as a video card or storage system, that is not supported by the kernel that came with your distribution. Indeed, some drivers contain proprietary code that is said to taint a pure Linux kernel, so some distributors will not include it, even if the vendor license terms permit it to be distributed by your chosen distributor. In this case, you will need to at least build new modules, and possibly even build a new kernel.

Linux can be used in many environments, from embedded systems such as mobile phones, to networking devices such as routers, to set-top boxes as well as more traditional computing environments. Some of these devices use a kernel that is customized to support only those functions that the system is intended to support. For example, a system intended to be a diskless firewall probably does not need support for any file system other than the read-only file system from which it loaded, yet it may need support for advanced networking hardware that is not part of a standard kernel. Again, a custom kernel will be required.

Source packages

The ultimate source for the Linux kernel is the Linux Kernel Archives (see Resources for a link). Unless you already know what you are doing, you should use a kernel package from your Linux distribution, because your distributor may have added custom patches. If you are already familiar with obtaining and extracting source packages, review the tutorial "LPI exam 101 prep (topic 102): Linux installation and package management." As with anything that may change your system, make backups first so that you can recover if things go wrong.

If you download source from the public kernel archives, you will download a compressed file, and you will need to decompress it using gzip or bzip2, according to whether you download the .gz or the .bz2 version of the kernel source. The pub/linux/kernel/ directory on the download server has a directory for each kernel version, such as 2.4, 2.5, or 2.6. At the date of this writing, the latest bzip2 version of the 2.6 kernel is linux-2.6.15.tar.bz2.

In that kernel directory, you will also see a corresponding ChangeLog- file that describes changes in this version, and a patch-2.6.15.bz2, which is a smaller file that allows you to patch the prior version of source to bring it up to 2.6.15 level. You will also notice signature files that you may use to verify that your downloaded file was not corrupted, either accidentally or maliciously.

The compressed source is normally uncompressed in /usr/src, and it creates a new subdirectory for the kernel version, such as linux-2.6.15, containing the tree of files needed to build your kernel. If you already have such a directory, you may want to back it up or rename it before unpacking the new kernel source. This will ensure that you can go back if you need to, and also that you will not have stray files that should not be in your kernel source tree. You need about 40MB of disk space for the tarball and about 350MB for the expanded source code.

Some distributors, notably Red Hat, now distribute the kernel headers and source necessary for building kernel modules as a kernel development package. Documentation may be in a separate kernel documentation package. These are designed for and sufficient for building modules, such as a proprietary vendor graphics card module, but they are not sufficient for rebuilding a custom kernel. Your distribution should have information about how to rebuild a kernel and how the source can be obtained. Check for documentation such as release notes.

Suppose you use FTP or HTTP to download the kernel-2.6.15-1.1833_FC4.src.rpm source RPM from the pub/fedora/linux/core/updates/4/SRPMS/ at, and the file is in the /root directory. Note that version numbers used here will probably be different for your system, so make sure you get the updated version of source corresponding to your installed kernel. Now, for Fedora, you must install the source RPM, then switch to the /usr/src/redhat/SPECS directory, and finally build the source RPM in order to create the Linux kernel source tree as shown in Listing 13.

Listing 13. Creating the kernel source tree for Fedora Core
[root@attic4 ~]# uname -r
[root@attic4 ~]# rpm -Uvh kernel-2.6.15-1.1833_FC4.src.rpm
   1:kernel                 ########################################### [100%]
[root@attic4 ~]# cd /usr/src/redhat/SPECS
[root@attic4 SPECS]# rpmbuild -bp --target $(arch) kernel-2.6.spec
Building target platforms: x86_64
Building for target x86_64
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.23188
+ umask 022
+ cd /usr/src/redhat/BUILD
+ export LANG
+ unset DISPLAY
+ '[' '!' -d kernel-2.6.15/vanilla ']'
+ cd /usr/src/redhat/BUILD
+ rm -rf kernel-2.6.15
+ /bin/mkdir -p kernel-2.6.15
+ cd kernel-2.6.15
+ /usr/bin/bzip2 -dc /usr/src/redhat/SOURCES/linux-2.6.15.tar.bz2
+ tar -xf -
+ echo '# x86_64'
+ cat .config
+ perl -p -i -e 's/^SUBLEVEL.*/SUBLEVEL = 15/' Makefile
+ perl -p -i -e 's/^EXTRAVERSION.*/EXTRAVERSION = -prep/' Makefile
+ find . -name '*.orig' -o -name '*~' -exec rm -f '{}' ';'
+ exit 0

The Linux kernel source for Fedora is now located in /usr/src/redhat/BUILD/kernel-2.6.15/linux-2.6.15. By convention, the /linux-2.6.15 tree is often moved to /usr/src and symbolically linked to /usr/src/linux, as shown in Listing 14. This is not strictly necessary, but it's easier to follow along with references that assume the kernel source tree will be in .usr./src/linux.

Listing 14. Moving the source tree to ./usr/src
[root@attic4 SPECS]# mv ../BUILD/kernel-2.6.15/linux-2.6.15 /usr/src
[root@attic4 SPECS]# cd /usr/src
[root@attic4 src]# ln -s linux-2.6.15 linux
[root@attic4 src]# ls -ld lin*
lrwxrwxrwx   1 root root   12 Mar 20 18:23 linux -> linux-2.6.15
drwxr-xr-x  20 root root 4096 Mar 20 18:13 linux-2.6.15

Before you attempt to build anything, review the Changes file that is located in the Documentation directory. Among other things, it lists the minimum levels of various software packages that you need to build a kernel. Make sure that you have these packages installed.

You may notice Makefile and .config among the files shown in Listing 13. The make file contains several make targets for tasks such as configuring the kernel options, building the kernel and its modules, and installing the modules and building RPM or deb packages. More recent kernel sources allow you to use make help for brief help on each target. For older systems, you may need to consult the documentation or examine the make file. Listing 15 shows partial output for make help.

Listing 15. Help for kernel building make file
[ian@attic4 linux-2.6.15]$ make help
Cleaning targets:
  clean           - remove most generated files but keep the config
  mrproper        - remove all generated files + config + various backup files

Configuration targets:
  config          - Update current config utilising a line-oriented program
  menuconfig      - Update current config utilising a menu based program
  xconfig         - Update current config utilising a QT based front-end
  gconfig         - Update current config utilising a GTK based front-end
  oldconfig       - Update current config utilising a provided .config as base
  randconfig      - New config with random answer to all options
  defconfig       - New config with default answer to all options
  allmodconfig    - New config selecting modules when possible
  allyesconfig    - New config where all options are accepted with yes
  allnoconfig     - New minimal config

Other generic targets:
  all             - Build all targets marked with [*]
* vmlinux         - Build the bare kernel
* modules         - Build all modules
  modules_install - Install all modules
  dir/            - Build all files in dir and below
  dir/file.[ois]  - Build specified target only


The .config file in your kernel build directory contains configuration information for your kernel, including the target machine environment, the features to be included, and whether a feature should be compiled into the kernel or built as a module. Creating a .config file is the first step to building or rebuilding a kernel. You create it using one of the configuration targets in the make file.

The main configuration options are:

The config target uses a command-line interface to obtain answers to many questions to either build or update your .config file. With the advent of the menu-based configuration targets, this command-line interface is rarely used today.
The menuconfig target uses an ncurses-based, menu-based program to create or update your .config file. You need only answer questions for items you want to change. This approach has superseded the older config target. You run this in a terminal window either remotely or locally.
The xconfig target uses a graphical menu system based on a QT front-end, like the one used with the KDE desktop.
The gconfig target uses a graphical menu system based on a GTK front-end, like the one used with the GNOME desktop.
The oldconfig target allows you to build a configuration using an existing .config file, such as you might have from a previous build or another system. For example, if you installed the kernel source for Fedora as described above, you may copy the configuration file for your running system from /lib/modules/$(uname -r)/build/.config to /usr/src/linux. Once you've built it, you may use one of the menu configuration targets to modify it if necessary.

Figure 1 shows what you might see if you run make menuconfig for a 2.4 series kernel. Press Enter to descend into lower-level menus, and press Esc to return. Help is available for most items. Either tab to the < Help > button and press Enter, or simply type h. Press Esc to return to configuring.

Figure 1. Running make menuconfig on a 2.4 kernel
Running make menuconfig on a       2.4 kernel

Table 4 shows the various options for including features in the kernel, either built in or as modules. When an option is highlighted, press the space bar to toggle between the allowable choices for that feature. You can also press y to enable an option, n to disable it, or m to have it compiled as a module if possible.

Table 4. Options for menuconfig
[*]Feature will be built into the kernel.
[ ]Feature will not be included in the kernel.
<M>Feature will be built as a kernel module.
< >Feature will not be included in the kernel but is capable of being built as a module.

Figure 2 shows what you might see if you run make gconfig for a 2.6 series kernel. Click the arrows to expand or collapse menu items. Help is displayed in a lower pane.

Figure 2. Running make gconfig on a 2.6 kernel
Running make gconfig on a       2.6 kernel

The major configuration sections for a 2.6 kernel are described below. You may not find all of these with 2.4 and earlier kernels, but this list gives you an overview of where to find what.

Code maturity level options
This section contains an option that determines whether remaining options give you a choice for code that is considered experimental. If you do not select this option, then you will be able to select only options that are considered stable. Be warned that functions you choose may or may not work at the current code level on your system, so you might have a chance to help with debugging.
General setup
This section lets you include an identification string with your new kernel, along with options for several kernel attributes that do not belong elsewhere but that you must specify.
Loadable module support
This section contains an option that determines whether your kernel will support modules and whether they may be automatically loaded and unloaded. You should enable module support.
Block layer
This section contains support for disks larger than 2TB, and allows you to choose the type of disk scheduling that you would like.
Processor type and features
This section contains CPU-specific configuration options. Here you choose the processor or processor family that your kernel will support, as well as whether or not to enable access to various processor features. Be sure to enable symmetric multi-processing support if you have more than one CPU or a hyperthreaded CPU. Generally, you should enable the MTRR option to allow better graphic performance with AGP or PCI video cards.
Power management options
This section contains several power management options. These are particularly useful on laptops. Besides controlling power states, you will find options here to control and monitor such things as temperatures or fan states.
Bus options (PCI etc.)
This section contains options for buses supported by your system, such as PCI, PCI Express, and PC Card buses. You can also enable the /proc/pci file system here, although you should generally use lspci instead.
Executable file formats / Emulations
This section contains options for supporting various binary file formats. You should enable ELF binary support. You may also enable support for DOS binaries to run under DOSEMU, as well as wrapper-driven binaries such as Java™, Python, Emacs-Lisp, and so on. Finally, for a 64-bit system that supports 32-bit emulation, you probably want to enable 32-bit binary support.
The networking section is large. Here you can enable basic sockets and TCP/IP networking, as well as packet filtering, bridging, routing, and support for a variety of protocols such as IPV6, IPX, Appletalk, and X.25. You can also enable wireless, infrared, and amateur radio support here.
Device drivers
This section is also very large. Here you enable support for most of your hardware devices, including IDE/ATAPI or SCSI hard drives and flash memory devices. Enable DMA for your IDE devices; otherwise, they will work in the slower PIO mode. If you want support for multiple devices such as RAID or LVM, this is where you enable it. You can also configure parallel port support here if you want parallel printer support. This is also where you configure a vast range of possible networking devices to support the networking protocols you configured above. You will also find support here for audio and video capture devices, USB and IEEE 1384 (Firewire) devices, as well as a variety of hardware monitoring devices. Under the character devices subsection, you will probably want to enable parallel print support and direct rendering support.
Firmware drivers
This section contains a few options related to BIOS setting and updating, such as using the Dell System Management functions on certain Dell systems.
File systems
This section is for configuring the file systems that you want your kernel to support, either compiled in or as modules. You will also find file systems here for removable media such as diskettes and CD or DVD devices, along with support for networked file systems such as NFS, SMB, or CIFS. Support for a variety of partitions and Native Language Support is found here too.
Instrumentation support
This section allows you to enable experimental profiling support for profiling your system's activity.
Kernel hacking
This section allows you to enable kernel debugging and choose which features will be enabled.
Security options
This section allows you to configure several security options and to enable and configure SELinux (Security Enhanced Linux).
Cryptographic options
This section allows you to configure several cryptographic algorithms, such as MD4, DES, and SHA256.
Library routines
This section allows you to decide whether certain CRC algorithms should be compiled in or built as modules.


Now that you've seen the major aspects of configuring a kernel, you're ready to build one. If you are not sure of the state of your build tree, run make clean before configuring your new kernel. For an even more extreme cleanup target, run make mrproper; this will remove your .config file as well as some other files used by the build process. If you do this and then need to restore a backed up .config file, you will need to run make oldconfig before configuring.

While you are experimenting, you should give your new kernel a custom name so you can easily identify it. Do this by setting a local version value and enabling the option to automatically append version information to the version string under the General setup section as shown in Figure 3.

Figure 3. Configuring a custom kernel
Configuring a custom kernel

In the spirit of taking small steps, the examples in the remainder of this tutorial are based on building a kernel with just the two changes shown in Figure 3.

In principle, the kernel does not require root authority to build, although you will need root authority to install your new kernel. However, if you are using the package installed by your distribution, you will probably have to run as root because of the file and directory permissions that have been set up. You can practice in user mode by downloading a kernel source tarball from the Linux kernel archives and unpacking it in your home directory, or by making a copy of your kernel build tree and changing the permissions to your userid.

To start building a 2.6 kernel, type make.

To start building a 2.4 kernel, run these three commands:
make dep
make bzImage
make modules
The first makes necessary dependency files. The second builds the kernel. And the last builds your modules.

Running make on my AMD Athlon 3500+ system takes about a half hour to complete the build from a clean start. Slower systems may take a couple of hours to complete the job, so take a break or do something else while you wait. You will see progress messages such as those in Listing 16 while the build is running.

Listing 16. Running make
[root@attic4 linux]# make
  CHK     include/linux/version.h
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/basic/split-include
  HOSTCC  scripts/basic/docproc
  SPLIT   include/linux/autoconf.h -> include/config/*
  CC      arch/x86_64/kernel/asm-offsets.s
  GEN     include/asm-x86_64/asm-offsets.h
  LD [M]  sound/usb/snd-usb-lib.ko
  CC      sound/usb/usx2y/snd-usb-usx2y.mod.o
  LD [M]  sound/usb/usx2y/snd-usb-usx2y.ko


When you have completed building your kernel, you still have a couple of steps to go. First, you need to run make modules_install to install your kernel modules in a new subdirectory of ./lib/modules.

If you need proprietary modules for a video card or network driver, as I need for my nVidia graphics card and nForce 4 motherboard chipset, now is a good time to build those modules using the vendor-supplied tools.

Finally, you need to run make install to install the new kernel and initial RAM disk in /boot and update your boot loader configuration. These steps are illustrated in Listing 17.

Listing 17. Installing the kernel and modules
[root@attic4 linux]# make modules_install
  INSTALL arch/x86_64/crypto/aes-x86_64.ko
  INSTALL arch/x86_64/kernel/cpufreq/acpi-cpufreq.ko
  INSTALL arch/x86_64/kernel/microcode.ko
  INSTALL arch/x86_64/oprofile/oprofile.ko
  INSTALL crypto/aes.ko
  INSTALL crypto/anubis.ko
  INSTALL crypto/arc4.ko
[root@attic4 linux]# ls -lrt /lib/modules | tail -n 3
drwxr-xr-x  5 root root 4096 Mar  4 14:48 2.6.15-1.1831_FC4
drwxr-xr-x  5 root root 4096 Mar 20 18:52 2.6.15-1.1833_FC4
drwxr-xr-x  3 root root 4096 Mar 20 21:38 2.6.15-prep-Topic105
[root@attic4 linux]# sh  /root/ -a \
>  -n -K -k 2.6.15-prep-Topic105
Verifying archive integrity...OK
Uncompressing NVIDIA nForce drivers for Linux-x86_64 1.0-0310...................
[root@attic4 linux]# sh  /root/ -a \
> -n -K -k 2.6.15-prep-Topic105
Verifying archive integrity... OK
Uncompressing NVIDIA Accelerated 
   Graphics Driver for Linux-x86_64 1.0-8178.................
[root@attic4 linux]# make install
  CHK     include/linux/version.h
  CHK     include/linux/compile.h
  CHK     usr/initramfs_list
Kernel: arch/x86_64/boot/bzImage is ready  (#2)
sh /usr/src/linux-2.6.15/arch/x86_64/boot/ 2.6.15-prep-Topic105 
arch/x86_64/boot/bzImage "/boot"
[root@attic4 linux]# ls -lrt /boot | tail -n 6
-rw-r--r--  1 root root 1743149 Mar 20 21:45 vmlinuz-2.6.15-prep-Topic105
lrwxrwxrwx  1 root root      28 Mar 20 21:45 vmlinuz -> vmlinuz-2.6.15-prep-Topic105
-rw-r--r--  1 root root  980796 Mar 20 21:45
lrwxrwxrwx  1 root root      31 Mar 20 21:45 ->
-rw-r--r--  1 root root 1318741 Mar 20 21:45 initrd-2.6.15-prep-Topic105.img
drwxr-xr-x  2 root root    4096 Mar 20 21:45 grub

Initial RAM disk

Notice that the build process automatically created the necessary initial RAM disk (initrd) for you. If you ever need to create one manually, you do so using the mkinitrd command. See the man pages for details.

Boot loaders

If everything worked correctly, the make install step should have also updated your boot loader configuration. Some lines from mine are shown in Listing 18.

Listing 18. Updated GRUB configuration file
password --md5 $1$y.uQRs1W$Sqs30hDB3GtE957PoiDWO.
title Fedora Core (2.6.15-prep-Topic105)
        root (hd0,11)
        kernel /boot/vmlinuz-2.6.15-prep-Topic105 ro root=LABEL=FC4-64 rhgb quiet
        initrd /boot/initrd-2.6.15-prep-Topic105.img
title Fedora Core -x86-64 (2.6.15-1.1833_FC4)

The entry for the newly built kernel has been placed at the top, but the default entry has been adjusted to remain as the previous default. If you use LILO instead, then the grubby command that is used in the build script should have updated your LILO configuration. If the configuration was not updated correctly for any reason, refer to the tutorial "LPI exam 101 prep (topic 102): Linux installation and package management," where you will find full instructions on setting up your boot loader.

One final note. You may wonder why the sample configuration added -Topic105, yet the created files all had -prep-Topic105 instead. This is a Fedora safety measure to prevent you from inadvertently destroying your live kernel. This is controlled by the EXTRAVERSION variable set near the top of the main make file, as shown in Listing 19. Edit the file if you need to remove this.

Listing 19. Updated GRUB configuration file
[root@attic4 linux]# head -n 6 Makefile
NAME=Sliding Snow Leopard


If all is well, you should now be able to boot your new system. You will need to select the configuration entry for the new kernel because it is not (yet) the default. After you are happy with it, you can make it the default. When you reboot, use the uname command to check your system's kernel as shown in Listing 20.

Listing 20. Checking your new system
[ian@attic4 ~]$ uname -rv
2.6.15-prep-Topic105 #2 Mon Mar 20 21:13:20 EST 2006

3 of 5 | Previous | Next


Zone=Linux, Open source
TutorialTitle=LPI exam 102 prep: Kernel

Table of contents

3 of 5 | Previous | Next