Kernel 6: Build the Kernel

In 2.4 kernels, you would first check dependencies:

make dep

This would check dependencies for each source file and include dependent binaries in various makefiles.

2.6 and later kernels don’t need it.



make clean

to prepare the source tree for your new build.


Historical note:

Once upon a time, the Linux kernel fit easily on a floppy disk. You would use compression, with a command like:

make zImage

Or, to save to both hard disk and floppy:

make zdisk #good for testing

Or, if necessary to create a really compressed image:

make bzImage

However, since version 2.4 the kernel is usually too large to fit on a floppy disk. There are various how-tos on the Internet for putting either the kernel or a bootloader on a CD, DVD or a USB key, if you’re interested.


The command you’ll end up using for modern compilations is:

make bzImage

Yes, that’s it. After a lengthy compilation, the resulting image will be in /usr/src/linux/arch/i386/boot/. The image itself likely will be called bzImage.

You must copy this file to /boot, as well as the file /usr/src/linux/


Patching the Kernel

Remember those patch files I mentioned at the beginning of this lesson? If you’re a genuine kernel-jockey and have already built a kernel on your current machine, you may be interested in patching your kernel. Patching is actually very simple, but it does require existing source code in /usr/src/linux. Download the next numerical version patch for your kernel. You must patch one version at a time: to go from 2.6.5 to 2.6.7, you must install the 2.6.6 patch first, then the 2.6.7 patch.

Uncompress the patch into your /usr/src/linux directory, and command:

patch < patchfile

You will then need to compile your kernel as I described above.



Make Any Modules

If you’ve chosen the M option in the configuration stage (and there are many defaults that use this setting), you’re also going to have modules to compile in your working directory. Command:

make modules

and then

make modules_install

They’ll end up in the /lib/modules/kernel_version directory.


About Modules

Module: a file containing code for a specific driver

See the man pages for the modprobe and insmod commands, for info on loading and unloading modules on the fly. With the 2.6 kernel, this is usually unnecessary. In most cases kudzu will detect hardware properly, which means the right modules for any new hardware get loaded automatically.

Generally, a list of modules is loaded at boot, taken from the file /etc/modprobe.conf. (Older distros may have the files /etc/modules.conf or /etc/conf.modules.)

However, here is some basic information for those occasions when you have to load modules yourself, or load them from a script.

You will typically find kernel modules in a subdirectory of /lib/modules/<kernel_version>/. Typically they are compiled files with a .ko (kernel object) file extension. (Older kernels, 2.4 and prior, used a .o extension.) insmod requires that you know the exact name of the module to be inserted, so most likely you will have to look in this directory. If I have an SIS video card, for instance, I can issue the command:

insmod sisfb

This will load the module, but won’t check for any dependencies it may have. To do a dependency check as well as loading the module, use the modprobe command:

modprobe sisfb


Module Commands


creates a dependency file for modules, which then can be used by modprobe

depmod –a

creates dependency files for modules listed in /etc/conf.modules

Some modules, whether very new or very old, may require manual editing of the /etc/modprobe.conf file.

cat this file to see its format. The syntax of each line is:

alias <device_alias> <driver_module>

For example, to load a DEC Tulip NIC with the device name of eth0, you would add the line:

alias eth0 tulip




loads a module into the kernel; once upon a time you had to do this manually or with a script to initialize, for instance, a sound card.


lists all loaded modules and their size (in units of 4k)

rmmod module(s)

unloads a module or list of modules from the kernel (this only works if they are not currently in use)

rmmod –r

recursively” removes all modules, i.e., if dependent modules are left behind on the first pass, they’ll be removed in another pass

modprobe module(s)

attempts to load the specified module and any dependent modules. Note that if you list more than one module, the others will load only if the first one fails.

modprobe –a module(s)

loads all of the modules, not just the first one

modprobe –r module(s)

removes specified modules and their dependencies.


Make an Initial RamDisk

Your kernel will need to load several modules at boot, which is tricky because the kernel needs the filesystem modules to access the filesystem (among other problems). The solution is a ramdisk: a filesystem image that is loaded into RAM at boot, as a step in the bootstrap process.


mkinitrd -v /boot/initrd-<kernel_version>.img <kernel_version>