Thread: Compiling a Custom Linux Kernel – 7478 days old

Intro and Gathering Information
Part 2 - Preparing the Source Tree
Part 3 - Configuring the Kernel Source
Part 3 Continued - Configuring the Kernel
Part 4 - Building the Kernel
Part 5 - Installing the Kernel
Part 6 - Editing the Boot Loader Configuration
Reboot the Machine (and Enjoy)
Appendix A - Patching the Kernel Source
Appendix B - Building a 2.6 Kernel
Appendix C - Additional Notes as 2.6 Develops
Appendix D - Using the Initrd


Why?

The focus of this article, is to build a custom Linux kernel for your server or desktop machine. The kernel will be optimized for the machine's processor, and will contain support only for the drivers and features that are going to be needed. Another reason to compile a kernel is to add support for a feature that is missing from a vendor supplied kernel, or to get a piece of hardware working.

The end result will be a smaller, faster kernel with all the fixes and enhancements found in the latest stable version, without such complex workarounds like initial ramdrives (initrd) that allow modular support of critical drivers to support a wide variety of hardware configurations.

Me? Compile a kernel?

Yes, you. While the task may sound daunting, it's really not that difficult. First of all, if you know your machine and are familiar with Linux, the configuration will be intuitively easy for you. Even if you don't, we'll show you how to gather the required information.

It is reasonably safe to attempt this, provided we make correct configuration choices for critical chipset drivers. Data corruption hurts. Also, we always preserve the original vendor supplied kernel, module tree and boot loader entry, so that if we screw up or need to roll back to the original kernel for other reasons, it's a simple matter of restarting the machine and choosing the old kernel from the boot menu. If you are doing this remotely on a server, you will have to call someone to reboot the machine if you lose access. This is usually the worst that will happen, if careful.

Gathering Information

First of all, most of this procedure is going to be performed as a normal unpriviledged user of the system. It is not until we actually install the finished kernel that we need root priviledges. However, this user must have access to the system. A user jailed in his home directory (as is often the case for shell accounts provided with web hosting) will not do.

We are going to be typing commands in a terminal. This can be a tty login, or an xterm or similar GUI terminal program on your local machine or a remote shell login. (SSH... secure shell is preferred)

Let us assume that we're logging onto a machine we know absolutely nothing about. The first thing we'd like to know, is what Linux distribution is on the machine. There is usually a text file in the /etc directory that states the name and version of your distribution. It can be named release, issue, redhat-release, slackware-version... whatever. The /etc/issue file is normally what is used to display a welcome message, when you log on to the system. We then want to know the version of the running kernel.

You can see the commands I've typed at the $ prompt (bash shell):



We view the file /etc/issue and see that we're running Redhat Linux 7.2. The uname command, gives us the kernel revision. It's a stock, redhat supplied 2.4.18 uniprocessor kernel.

There is a wealth of information about the running kernel available by examining the boot messages. This information is conveniently collated in the output of the dmesg command.



This will give you an idea of the features in the running kernel, and the hardware that is initializing. For example, the IDE controller:



The first line of dmesg shows us the kernel version, the user and host it was compiled on, when it was compiled, the compiler used and the distribution it was compiled on. Curiously, this Redhat 7.2 server is running a kernel that was compiled on Redhat 7.3. That just means that someone has installed a newer binary kernel package. Several lines below that, we can see that this machine has 1 Gigabyte of RAM. (This means that we will be enabling HIGHMEM support in the kernel)

Examine the output of dmesg on your own machine. We'll take some of that into consideration, when we configure the new kernel build.

There is also a wealth of information to be gleaned by examining various files on the /proc pseudo filesystem. The /proc filesystem is basically provided by the kernel as an interface to various kernel data structures.

To find out detailed information about the machine's processor(s), we examine /proc/cpuinfo with the cat command.



We already knew this from dmesg but we can see, we're on a uniprocessor system (not a SMP rig with multiple processors) and we have an Intel Pentium4 processor running at approximately 2 GHz. We can also see the flags (e.g. instructions) that the processor supports.

Next, we need to know what chipset and PCI bus devices we have. For a simplified display, we can use the lspci command without switches.



Well, now we know that we have an Intel i845 chipset, with ICH2 IDE controllers and onboard AC'97 Audio and an Nvidia graphics controller.

If we want to view more details about the PCI bus hardware, we use lspci -v for a more verbose display.

If your running kernel was compiled with backwards compatible "legacy /proc/pci support" enabled, more detailed information is also available by viewing /proc/pci with the cat command.



Much of this information may not make sense, for example, just what the Hell is an Intel 82801BA/BAM/CA/CAM Ethernet Controller anyway? We can guess that it's an onboard device. Fortunately, we already know what it is from the output of dmesg:



We know that this onboard ethernet controller uses the Intel EtherExpress Pro driver.

OK, that is an Intel system. What kinds of differences might we see if it were an AMD system? Here's a couple of examples of things to take note of. First in this example, the output of lspci shows that we have a VIA chipset. If this were the machine we were working on, it would be important, while configuring the kernel.



Now, some relevant excerpts from the output of dmesg:





Note the difference in the IDE controller, compared with the Intel configuration above.

Now, back to the Intel Pentium 4 rig, the machine we're going to be working with. There are a few more things we need to look at, before we start working on the kernel sources.

We should see which kernel modules are loaded, in our running kernel. We do this using the lsmod command. Note that as a non-root user, you may have to type the full path to this and other programs in the /sbin directory as it's not always in a normal user's path.



There is nothing out of the ordinary, here. Note that some of these drivers aren't going to be modules. In order for our custom kernel to be able to boot without using an initrd, things like the EXT3 filesystem and disk controller drivers need to be included right in the kernel. We will be compiling our network adapter driver as a module, though, for example.

We need to see the layout of our filesystems, also. What kinds of partition devices and filesystem types are we using? We already have a good idea, based on what we saw with dmesg, but we can view the output of df (diskfree). The -h and -T switches are "human readable" and "show type" respectively.



This is a pretty straight forward setup. A small boot partition that contains the kernel and boot loader, and one large root partition on the first IDE hard disk, /dev/hda. There are no SCSI disk partitions, which would be named /dev/sda1, sda2, sdb1, and so on. The filesystem that is in use, is EXT3. The tmpfs mount, (/dev/shm filesystem) is sort of like a ramdisk, but it's more dynamic. No memory is really used, until something is copied there and it's freed when removed. It exists in the page cache or even in swap.

We must get a look at the /etc/fstab file. This is the "filesystem table" that the system init uses to mount your filesystems. There is something very important here that needs to be checked.

Note that the spacing in fstab is unimportant, as long as there is at least one whitespace or tab between arguments.



See the first two lines with the LABEL= statements? The Ext3 filesystem supports the concept of volume labels. By default on a Redhat system, the partitions are mounted according to labels. It makes it easier to switch drives around on controllers. There's some kernel patch in redhat kernels that makes this work. Guess what? If we build a standard kernel without support for this, the system init scripts will not be able to mount our filesystems during startup. There will be no startup.

Note: While it's true there was a patch to work around this, the magic that makes "mount by label" possible is done using an initrd. If you are going to be using an initrd with your custom kernel, you don't need to change this.

I therefore recommend that we use a text editor, to edit fstab, and use the real partition devices. It's not a big deal, for we know them from the output of df -hT. The / filesystem is mounted on /dev/hda2, and /boot is mounted on /dev/hda1.

So change the LABEL= statements, to look like this:



Use the real partition device names in fstab, for your system. You also must ensure that there isn't anything silly in your boot loader's configuration file like root="label=/" or the kernel won't even be able to mount the root filesystem, but we will cover that later in the article.

Be very careful editing configuration files like fstab. If you stuff them up, you may have to start the system with a rescue disk and fix them. It's generally a good idea to rename a backup copy of configuration files you edit. Easier to rename it back again than to try reconstructing what you hosed.

We should now have enough information to get started. The next task is to unpack the kernel source, and start reading a couple of documentation texts .

Intro and Gathering Information
Part 2 - Preparing the Source Tree
Part 3 - Configuring the Kernel Source
Part 3 Continued - Configuring the Kernel
Part 4 - Building the Kernel
Part 5 - Installing the Kernel
Part 6 - Editing the Boot Loader Configuration
Reboot the Machine (and Enjoy)
Appendix A - Patching the Kernel Source
Appendix B - Building a 2.6 Kernel
Appendix C - Additional Notes as 2.6 Develops
Appendix D - Using the Initrd

Intro and Gathering Information
Part 2 - Preparing the Source Tree
Part 3 - Configuring the Kernel Source
Part 3 Continued - Configuring the Kernel
Part 4 - Building the Kernel
Part 5 - Installing the Kernel
Part 6 - Editing the Boot Loader Configuration
Reboot the Machine (and Enjoy)
Appendix A - Patching the Kernel Source
Appendix B - Building a 2.6 Kernel
Appendix C - Additional Notes as 2.6 Develops
Appendix D - Using the Initrd


Preparing the Source Tree

Download the latest stable kernel source archive. At this time of writing, that is version 2.4.22. Go to www.kernel.org and you will find links to download what you need. The file you want is linux-2.4.22.tar.bz2 which is bzip2 compressed. We choose that format over .tar.gz, because it's got better built-in checksum verification and is significantly smaller to download.

Save it to your home directory, and unpack it somewhere within. Do not unpack it to /usr/src as some outdated kernel howtos may show. You can do it in your home directory and you do not need to have root priviledges to compile the kernel, until it's time to install.

I am unpacking the kernel source to a directory named build, within my home directory:



Note that older versions of tar used the -y switch for bzip2 rather than j. Also note, if you want a verbose display that scrolls filenames faster than you can read them, use the -v switch.

Enter the directory where you unpacked the kernel source. Skim the README file, and note where he warns about using the /usr/src/linux area to unpack kernel source.



Now, enter the Documentation directory and read the file Changes. This is required reading, especially the following section. This means you.



To the right on each line, the comments show you the command to use to determine the version you have. In addition, if you are using disk quotas (which we are on this server) you will need to have a recent version of the Quota Tools. http://sourceforge.net/projects/linuxquota/

If your system is already running a 2.4 series kernel, chances are you satisfy the requirements. As stated in the Changes file, you don't need to worry about things you don't use. If you don't use reiserfs anywhere, you don't compile support for it and therefore don't need to worry about the reiserfs tools. If you don't have an ISDN network connection, you don't need to worry about ISDN tools.

As for compilers, gcc 2.95.3 is the recommended version, but gcc 3.2.x works quite well.

Note that if you have redhat 7.0, you may have a broken version of gcc 2.96 installed. It may fail to compile the kernel. However, also provided is kgcc (which is really EGCS) that can be used to compile the kernel. Ensure that the package is installed, that kgcc is in your command path, and edit the Makefile in the top level kernel source directory. (the linux-2.4.22 directory) Change the name of the compiler from gcc, to kgcc in the following two places:



Only Redhat 7.0 has this problem, the gcc 2.96 in later versions of Redhat should be fine.

Now that you've verified and/or installed the required versions of supporting software, we can begin.

The first command we issue, is make mrproper which cleans the build tree, just in case there is some cruft in the directory. This clobbers any configuration, dependency info and object files. (It doesn't touch the Makefile though)



Now we are ready to start configuring the kernel!

Intro and Gathering Information
Part 2 - Preparing the Source Tree
Part 3 - Configuring the Kernel Source
Part 3 Continued - Configuring the Kernel
Part 4 - Building the Kernel
Part 5 - Installing the Kernel
Part 6 - Editing the Boot Loader Configuration
Reboot the Machine (and Enjoy)
Appendix A - Patching the Kernel Source
Appendix B - Building a 2.6 Kernel
Appendix C - Additional Notes as 2.6 Develops
Appendix D - Using the Initrd

Intro and Gathering Information
Part 2 - Preparing the Source Tree
Part 3 - Configuring the Kernel Source
Part 3 Continued - Configuring the Kernel
Part 4 - Building the Kernel
Part 5 - Installing the Kernel
Part 6 - Editing the Boot Loader Configuration
Reboot the Machine (and Enjoy)
Appendix A - Patching the Kernel Source
Appendix B - Building a 2.6 Kernel
Appendix C - Additional Notes as 2.6 Develops
Appendix D - Using the Initrd


Configuring the Kernel Source

From what we already know about the machine and its purpose, and the information we've gathered, we must now configure the kernel sources. This is where the architecture type is established (i386), and where we choose the features and drivers needed for our kernel.

There are different utilities provided for configuring the kernel, but we will focus on menuconfig which is a menu driven utility that can be used from the command console. It requires that the ncurses library be installed. Something that should be, by default in most distributions. If you are running XFree86 on your machine, you can also use xconfig but in my opinion, it is more confusing and slower to navigate than menuconfig, and it requires that the tk package series be installed.

Click Here to see a screenshot of xconfig (png in new window)

First, a word about make oldconfig. If you've already compiled a 2.4 kernel previously, and have a .config file, you can copy it to the top level kernel source directory and use make oldconfig to fly through the existing configuration. If something new is encountered, oldconfig stops and prompts you to say Y, N or M (for "module"). After doing that, the source is configured and the build should be ready to start, but you really should run menuconfig and check it over, and optionally make changes. Don't use oldconfig unless you've got a valid .config file.



After you've made decisions on anything you've been prompted for (usually no for bizarre hardware, but you have to be careful not to skip over something important if your .config is old and they've significantly changed things), you are returned to the command prompt.

Now, from the top level kernel source directory, type make menuconfig



It will generate a bunch of output as the menuconfig utility is compiling, then your screen should change to the following menu:



The colours may vary a little (e.g. it could be black and white), depending on your terminal or ncurses library.

Essentially, what you must do is, enter each submenu and select the things you need, and deselect the things you don't need. It starts out with a default configuration. This is not usable as is, for the hardware chosen most likely will not match yours.

This is where you must don your thinking cap, and consider the information you've gathered, and read the Help entries on items you do not understand. They are usually pretty informative, sometimes offering answers like "if unsure, say N".

We will cover most of the main submenus. You can explore others, if applicable to you.

You navigate with the arrow keys and/or tab key, and use the space bar to select or deselect a highlighted choice in a menu. If the item has angle brackets, indicating that it's possible to compile as a module, pressing the space bar toggles through the three settings of yes, module and no. Items in square brackets, are either included directly in the kernel only, or are included as part of something else you have built as a module in some cases. It is a yes or no choice.

To read the Help on a selected item, use the tab or arrow keys to activate Help down at the bottom of the menu.

The first submenu, is Code Maturity Level Options. Press Enter to go into the submenu.



With 'Prompt for development and/or incomplete code/drivers' selected, hit tab twice to active Help, and then press Enter.



Press Enter to exit and return back to the submenu.

Now, this is a choice we want to activate, so we can see all the available drivers in the menus.



Press the space bar, to enable this choice and it will be shown with an asterisk. You can also press the Y key to accomplish the same. Press Tab to highlight Exit, and then press enter.

Back at the main menu, use the down arrow key to select the next submenu, Loadable Module Support. Press Enter, to go into the submenu.



These three items are enabled by default. I recommend you leave them that way. The only one that's really *needed* is "Enable Loadable Module Support", but on a Redhat system, you will want to use the Kernel Module Loader (read the help item for more info), and the module versioning choice doesn't do any harm.

Kernel modules are drivers that can be dynamically inserted and removed from the running kernel, as opposed to drivers compiled statically into the main kernel. We will be building some drivers as modules. Pretty much anything that can be initialized later in the boot process. However, anything required to start the system must be compiled statically into the main kernel. That means you must say 'Y'.

Exit back to the main menu, and the next submenu is Processor Type and Features



Now, press Enter to go into the processor choice submenu.



Scroll to see all the choices. This server has a Pentium 4 processor, so the choice is a no brainer. If your CPU is not listed, choose the closest match.

After making your choice, you will be taken back to the Processor Type and Features submenu. There are some items we must decide on here.

First of all, Machine Check Exception. I'd probably disable that for a server you don't have physical access to. We don't need any bogus exceptions occurring.

On this machine, we have a gigabyte of RAM, so we must enable High Memory Support. Choose 4 Gb. After enabling that, a Highmem I/O choice will appear. Enable that too.

MTRR support should probably be enabled. Modern systems support that. This one does.

Symmetric Multiprocessing Support should be disabled here, as we only have one processor.

This is now what we have for Processor Type and Features:



The next submenu is General Setup. Among other things, this is where we choose the types of busses our kernel is going to support.



The first two are no brainers. We know we need networking support and PCI support.

I do not use PCI Device Name Database, but read the help item on it. It is your choice and it does no harm. (It just enlargens the kernel image, but the memory is freed)

We can do without ISA bus support on this server. (note that things that still use the ISA bus, like floppy drives, are still supported without this)

Likewise for hot-plug support on this machine, we don't need it. However, if your machine is a laptop, or if you plan on using USB devices, you will probably want hot pluggable support.

Enable BSD Process Accounting. Leave System V IPC and Sysctl support enabled. You need those.

Leave the kernel core format set to ELF, and leave the binary types enabled.

Because this is a server, I am disabling power management support, and I am not enabling ACPI. We can get along without ACPI support on this rig. However, depending on what kind of system you're compiling a kernel for, enabling ACPI support may be important.

On my rig at home, which is actually very similar in hardware to this rig, I enable ACPI support. At the very least, it gives me proper soft powerdowns.



I generally do at least this, to support the processor's throttling states. (though the kernel will issue the hlt instruction to the processor without this). On a laptop or other specialized system, you may need to enable more of those ACPI support items. Read the Help on the individual items.

Note that depending on your (buggy) chipset, enabling ACPI support may cause problems. The system may not even boot. ACPI handles IRQ routing when it's enabled. It can be disabled by passing parameters to the kernel in the boot loader configuration. For example append="acpi=off"

In addition, ACPI will enlargen your kernel considerably.

This is what I have selected under General Setup.



Exit back to the main menu, and the next submenu is Memory Technology Devices which we are skipping. Don't enable those, unless you plan on using some sort of Flash ROM/RAM chips. As always, you can read the Help item.

Next in the list, is Parallel port support. We can compile it as modules, even though it will probably not be used on this server. These modules won't get loaded. Select M for parallel port support, and it makes the rest of the options available. The IEEE1284 transfer mode option doesn't have a module choice, but this is just code that will be included in the parallel port module if enabled.



Back at the main menu, the next submenu is Plug and Play configuration. I generally disable the items within, as I don't need ISA PNP devices, but read the Help and decide for yourself if you need it. They can be left enabled if you do have cards that would use this.

Next on the agenda, is Block Devices.



I like to build floppy support as a module. No reason to have that compiled statically in the kernel, so I change it to M.

I also like to have the loopback driver as a module, just in case I ever need to mount some disk image file. (for example, an ISO file). It doesn't cost anything, if we compile it as a module. It wouldn't be loaded, until needed.

Per Partition Statistics in /proc/partitions allows system monitoring utilities to display usage statistics for individual partitions.

Exit back out to the main menu, and the next submenu is Multi Device Support (RAID and LVM). Only enable support for this, if you plan on using software raid, or the logical volume manager LVM (combine disks or partitions into a single volume). I am leaving it disabled, for we aren't using that on this machine.

The next submenu on the main menu, is Networking Options. There are some important choices to make here. These are the default settings:



Leave Packet Socket support enabled, at least on a Redhat system.

Enable the Network Packet Filtering choice, which makes the IP: Netfilter Configuration submenu appear.

You need Unix Domain Sockets and TCP/IP Networking enabled.

However, you may not need IP Multicasting. I have disabled it, for this server but it's something you may want. As always, read the Help on any of the items in here and decide if you need them.

Scroll down to the Netfilter Configuration submenu and press Enter. These drivers are for the kernel's built in firewalling. With the relevant drivers loaded, you can use the iptables, or ipchains programs to implement firewall rules. Your distribution probably has a front end, to configure firewalling.



What I do here, is build pretty much all of the drivers under Netfilter Configuration as modules. I leave out the experimental ones, but you could build those as modules too. It does no harm, and I don't really know what I might want to use or play with some day. Only the modules used, would get loaded. On this server, I must enable the old ipchains support. Recall the output of the lsmod command, that module is loaded in the running kernel.

These are the Networking Options I have chosen for this machine.



Everything else in Networking Options has been left at the default settings of disabled. Read and decide for yourself if you need any other functionality.

Back at the main configuration menu, next in the list is Telephony Support. You probably don't need this, but enable it if you intend to do "voice over IP" using a telephony card.

Now, ATA/IDE/MFM/RLL support is the next submenu. Very important drivers in here, if using IDE devices. This is where we configure our IDE chipset, devices, and things like DMA. Unless you are using an all SCSI system, and don't want support for any onboard IDE controllers or devices at all, this means you. Most of this has to be compiled right in our kernel, not as modules.



Leave ATA/IDE/MFM/RLL support enabled. Don't change it to M, unless you know what you're doing. We want to enter the IDE, ATA and ATAPI Block devices submenu.



Enhanced IDE/MFM/RLL disk/cdrom/tape/floppy support stays enabled. If you were to disable it, it would deactivate most all of the choices.

Include IDE/ATA-2 DISK support must also stay enabled.

Use multi-mode by default should probably be disabled. We'd rather let the driver apply the (hopefully) correct UDMA mode. Read the help on the item. I am disabling it for this machine.

Include IDE/ATAPI CDROM support is something you can set to M, to build as a module.

SCSI Emulation Support should be set to M, if you have a CD Writer. I'm leaving it disabled for this machine.

Note that IDE/ATAPI CDROM support and SCSI emulation can both be built as modules. If you are going to load them both at the same time (or build them both statically into the kernel), you will need to specify parameters at the boot loader, for the drive you wish to use in SCSI emulation mode. Something like append="hdc=ide-scsi" for a CD Writer in the secondary master position.

CMD640 chipset bugfix/support can be disabled, unless you have one of those chipsets. If you do, and you don't enable this, you will very quickly corrupt data. I did that once, not long after I first started compiling kernels. It was an old Pentium Compaq Deskpro, with Mandrake 7 installed. It is not harmful to leave this workaround enabled, if unsure.

You need PCI IDE Chipset Support enabled. It needs to be built in, for us.

Now, Generic PCI IDE Chipset Support can be enabled if you're unsure about your chipset. I'm leaving it disabled, because we know what's in this machine.

If your machine supports Sharing PCI IDE interrupts support, you can enable it. I am disabling it.

Generic PCI bus-master DMA support, I leave enabled.

Use PCI DMA by default when available, should remain enabled.

Read the Help items, for other features and drivers you are curious about.

Skipping down to chipset choices, by default, Intel PIIXn chipsets support is enabled. That just happens to be the choice we want for this machine. It detects and supports the Intel IDE controllers.

However, recall the example of the AMD Duron server I showed you. It has a VIA chipset.



For that example, we would want to enable the VIA82CXXX chipset support instead of PIIXn. We would want to say Y to this, which would detect and support the VIA IDE controllers. For the VIA chipsets, we also want to enable "Sharing PCI IDE Interrupts Support"



Enable support for whatever IDE controller is in your machine.

For the Pentium 4 machine we are working on, this is what the IDE/ATAPI Block Devices configuration looks like:



Back out at the main menu, the next submenu is SCSI Support. I am disabling that entirely for this machine, as we do not have anything that uses it.

However, that may not be the case for you. Even if you don't have SCSI hard disks, you may need the SCSI subsystem for CD writing (SCSI emulation needs the scsi layer), or even for something like an external zip drive.



These are the default settings. If you do have SCSI hard disks and especially if you are booting from SCSI, you want to include this support right in the kernel.

You must now enter the SCSI low level drivers submenu.



Deselect SYM53C8XX SCSI support, unless you have one of those controllers. Choose a driver for your SCSI controller, if applicable. If you have a parallel port zip drive, enable one of the IOMEGA parallel port choices.

If you are only building scsi support for CD writing, or for other non critical devices like the zip drive example, you can build all the scsi support as modules. Here's what your SCSI Support submenu should look like, for CD writing:



Exit back out to the main menu, and the next submenu is Fusion MPT device support. This is a specific type of high performance (fiber channel) SCSI controller, that they have in a menu of its own. It depends on SCSI support though. Only enable this if you have one of these controllers.

The next item on the main menu, is IEEE 1394 (FireWire) support. You can enable it, and the appropriate device drivers beneath, if you need it.

Next in the list is I2O Device Support. You probably don't have one of these devices, but you can read the Help item.

The next submenu is Network Device Support. This is a very important section, it's where we configure network interfaces and adapters.



Dummy net driver support is set to M, by default. I usually leave it that way. It's a dummy network device, where anything sent to it is just dropped. I haven't ever used it, but read the Help, there it is.

Enter the Ethernet (10 or 100Mbit) submenu. EtherExpressPro/100 support is enabled by default. That just happens to be what we have, but we want to change this to M, to build it as a module. Deselect it, if that's not the adapter you have. Choose M for the appropriate driver. Note that you may have to select a choice like 3Com cards or Western Digital/SMC cards, to make your desired driver appear.



I do recommend that you build your network adapter as a module, on Redhat systems. I was compiling a kernel on a Redhat server one time, and thought I was doing a good thing by saying Y to the Intel Gigabit e1000 driver. We had to call and have the machine booted to the old kernel, when it didn't come back up. When we got back in, the logs showed it was the network interface that didn't come up. Realizing what happened, I built it as a module on the second try. I've done that ever since.

Of course, if you have something other than 10/100 Ethernet, deselect the default EtherExpressPro choice in there and exit back to the Network Device menu and choose Gigabit, or Wireless submenus if applicable.

If you are at home and using dialup, this is how you will want to configure PPP.



You need PPP Support, as well as support for PPP on asynchronous serial ports. If you like, you can build PPP support right in the kernel so you don't have to worry about how the module is to be loaded. When I used dialup, I generally did that, but built the compressors as modules.

When finished reading and configuring, exit out of the Network Devices submenu, and back at main, the next submenu is Amateur Radio support. Obviously, we're not going there, but it's interesting to read the Help.

Next on the list, is IrDA (infrared) support. It might interest you if you have a laptop.

If you have an ISDN modem and connection, enter the ISDN subsystem menu, and enable it and choose the appropriate drivers. You will probably also have needed to enable PPP support, and support for PPP over synchronous ports (not async).

The next submenu is Input core support. We're not enabling that, but if you have a USB mouse, keyboard or any type of joystick, you will want to build these (probably) as modules.



It's a necessary layer, for USB Human Interface Devices (HID). You do not need this for serial or PS/2 mice or keyboards.

Continued...

Intro and Gathering Information
Part 2 - Preparing the Source Tree
Part 3 - Configuring the Kernel Source
Part 3 Continued - Configuring the Kernel
Part 4 - Building the Kernel
Part 5 - Installing the Kernel
Part 6 - Editing the Boot Loader Configuration
Reboot the Machine (and Enjoy)
Appendix A - Patching the Kernel Source
Appendix B - Building a 2.6 Kernel
Appendix C - Additional Notes as 2.6 Develops
Appendix D - Using the Initrd

Intro and Gathering Information
Part 2 - Preparing the Source Tree
Part 3 - Configuring the Kernel Source
Part 3 Continued - Configuring the Kernel
Part 4 - Building the Kernel
Part 5 - Installing the Kernel
Part 6 - Editing the Boot Loader Configuration
Reboot the Machine (and Enjoy)
Appendix A - Patching the Kernel Source
Appendix B - Building a 2.6 Kernel
Appendix C - Additional Notes as 2.6 Develops
Appendix D - Using the Initrd


Configuring the Kernel (continued)

Character Devices is the next item on the main menu. Miscellaneous input and output devices here.



You need to leave Virtual terminal and Support for console on virtual terminal enabled.

If you intend to use a dial up modem, or other serial based device (such as one attached to your PC's serial ports) you need Standard/generic (8250/16550 and compatible UARTs) serial support. If you only expect to use this rarely, you could build it as a module. That is what I will do for this server.

You need Unix98 PTY support, for pseudo terminals

If you intend to use a printer attached to your PC's parallel port, you will want to enable Parallel Printing Support. Say Y, or M if you like.

In the Mice submenu, ps/2 mouse support is enabled by default. I usually leave it that way, as the ps/2 keyboard support and mouse support are in the same source file.

Enhanced Real Time Clock Support, I would enable, so that when the system clock (software clock) is synchronized with the hardware clock on your systemboard, it can use the /dev/rtc interface instead of writing directly to registers.

If you intend to use Direct Rendering in XFree86 (e.g. for hardware accelerated OpenGL support), you should say M to /dev/agpgart support, the appropriate driver for your AGP chipset, and to DRI support, and the appropriate driver for your video accelerator. Build these as modules. I am disabling these options, for this server.

These are the Character Devices options I have selected for the server:



Back at the main menu, the next submenu is Multimedia Devices. If you need support for audio/video capture and overlay devices or FM radio cards, enter this submenu and read the Help.

Next on the list, is Filesystems. Very important to build support for the filesystems on our disks, right in the kernel. This means, we need EXT3 Journaling Filesystem Support built in, as well as Second Extended (EXT2) Filesystem support. EXT3 is really EXT2 underneath and in fact can be mounted as EXT2.

I have to build disk Quota Support on the server we're working on, but you may not be using it.

If you are dual booting with Windows, you can build DOS FAT and VFAT (you need both) or NTFS filesystems as modules. If you enable NTFS support, you'll see another option for write support that appears. Believe them when they say it's "Dangerous". Don't enable write support. You will cry. There is good read support though. Note that FAT/FAT32 filesystems are well supported, you will be able to safely read and write to them.

I am enabling ISO9660 (CDROM filesystem) support as a module. I'm also building Joliet and transparent compression extensions. They will be modular as well, despite only having one choice. The Joliet probably won't ever be needed on a server (the cdrom drive would only be used in emergencies anyway), but since it's just going to add a bit of bloat to the module that won't normally be loaded, we don't care.

You need to leave the /proc filesystem, as well as the /dev/pts filesystem enabled. Built in.

Enter the Network Filesystems submenu. If you're going to build support for NFS networking, change them to modules. SMBFS is useful to build as a module, if you intend to mount Windows fileshares.

These are the filesystem options I have selected:



Remember: Build support for your native filesystems right in the kernel! We have done that with EXT3 and Second Extended filesystem support. However, if you are using something else like reiserfs, don't forget to include support.

Back to the main menu, the next submenu is Console Drivers. A few items of interest here.



You must leave VGA text console enabled, if you want to have a text mode display. You do!

If you enable Video mode selection support, you can specify a video mode in your boot loader's configuration. (with the "vga =" parameter)

You can also enable Frame Buffer support, which will allow you to run in higher resolution, with higher colour depth and refresh rates in text console mode. You can enable the VESA VGA graphics console (VESA framebuffer), or specific framebuffer support for your display adapter. Read the Help, and the documentation they refer to. (Documentation/fb/framebuffer.txt). You may also have to pass parameters to the kernel, in the boot loader configuration.



Note that with some cards, the framebuffer driver and direct rendering can conflict. Usually the result is that direct rendering (DRI) doesn't work. For example, from personal experience, ATI Radeon users. If you enable framebuffer support (even if you build your framebuffer driver itself as a module, thinking you're going to use the fbset utility to set the mode) XFree86 will fail to initialize the agpgart and DRI modules. I have not seen this problem with Rage 128 based cards though.

I don't need this stuff on a server, so I'm not enabling video mode selection, or framebuffer support.

Next on the list is Sound. This is where we enable sound card support. I am not enabling this, because I'm building a kernel for a server. If I was, I'd be choosing the Intel ICH (i8xx) driver for the onboard sound. We know that from the output of lspci. (and by reading the Help item associated with this driver)



You can select sound card support, in addition to your specific driver as modules. If you enable the OSS sound modules choice, you will see more drivers appear. Deselect the default choice of Creative Ensoniq, unless that is the driver you need to use. (e.g. "Soundblaster PCI" 16 or 128 bit cards use this driver)

Note that if your distribution is using the ALSA system (Advanced Linux Sound Architecture), or you plan to build and install an external kernel module later, all you should do here is enable Sound Card Support. Disable any other drivers. You build and install ALSA drivers afterwards.

Consult http://www.alsa-project.org/ for more information on ALSA support.

Next on the list, is USB Support. I am disabling this entirely, for the server. (there are USB modules in the running kernel, but there's nothing using them)



Note that because we disabled such things as SCSI support and Input Device Support, it's warning us that we must enable these features in the kernel.

Choose the support you are going to need, for your USB devices. For example, if you are using a USB mouse, you need to enable Human Interface Devices. To use a USB flash card reader, you'd need the USB Mass Storage driver. Read the Help items.

Back at the main menu, the next item is Bluetooth Support. It's a type of short range wireless communication. Only enable it if you expect to use bluetooth devices.

Next on the list, is Kernel Hacking. You probably don't need to enable any of these options for debugging the kernel.

You probably don't need the new built in Cryptographic options. That's rather "special purpose" at this time.

For Library Routines it might be a good idea to enable CRC32 functions as a Module. Just in case you ever need to build external kernel modules that need to use that functionality.



Exit back to the main menu. Now, exit menuconfig and select Yes when prompted to save changes.



Kernel configuration is complete and we can proceed with the build! You might first want to go back into menuconfig and double check your choices once more. You don't need to save changes when you exit next time, if you haven't made any.

Intro and Gathering Information
Part 2 - Preparing the Source Tree
Part 3 - Configuring the Kernel Source
Part 3 Continued - Configuring the Kernel
Part 4 - Building the Kernel
Part 5 - Installing the Kernel
Part 6 - Editing the Boot Loader Configuration
Reboot the Machine (and Enjoy)
Appendix A - Patching the Kernel Source
Appendix B - Building a 2.6 Kernel
Appendix C - Additional Notes as 2.6 Develops
Appendix D - Using the Initrd

Intro and Gathering Information
Part 2 - Preparing the Source Tree
Part 3 - Configuring the Kernel Source
Part 3 Continued - Configuring the Kernel
Part 4 - Building the Kernel
Part 5 - Installing the Kernel
Part 6 - Editing the Boot Loader Configuration
Reboot the Machine (and Enjoy)
Appendix A - Patching the Kernel Source
Appendix B - Building a 2.6 Kernel
Appendix C - Additional Notes as 2.6 Develops
Appendix D - Using the Initrd


Building the Kernel

Like menuconfig reminded us after saving changes, we must first build dependencies. This ensures that the required, correct headers are found. Getting ready for the build.



So type make dep and watch a bunch of output scroll by faster than you can read it. It will look like this when it finishes:



Now, we are ready to build our kernel image. What we are going to do is, build a bzImage which is a "big z" compressed (essentially gzipped) kernel image. In the old days, if we kept our kernel image small we could have used "make zImage" which fits into memory a bit differently. Those days, of kernel images smaller than 500 kilobytes, are long gone though. Use bzImage.



You will see plenty of compiler output fly by. This will take a few minutes (maybe several if you have a slow machine). When it completes successfully, this is what you will see:



Our kernel image is just over 600 kilobytes. Not bad for size, as everything critical is built right in.

Now we must compile all the drivers we have selected as modules (M), using the make modules command.



Again, a bunch of compiler output. When it's done:



That's what a successful completion of a "make" operation looks like. If a make operation fails (e.g. compiler or linker error), you would see errors and asterisks. Somewhat like this:



That is what a failed make looks like. You know you have a problem, if make exits in that manner. When you see something like that, you cannot proceed with the next step. What you do about it, would depend on what the problem is. In this particular case, it's a problem with the source file. I removed a brace terminating a function, to generate that error.

We are now finished compiling the Linux kernel! It is now ready to be installed.

Intro and Gathering Information
Part 2 - Preparing the Source Tree
Part 3 - Configuring the Kernel Source
Part 3 Continued - Configuring the Kernel
Part 4 - Building the Kernel
Part 5 - Installing the Kernel
Part 6 - Editing the Boot Loader Configuration
Reboot the Machine (and Enjoy)
Appendix A - Patching the Kernel Source
Appendix B - Building a 2.6 Kernel
Appendix C - Additional Notes as 2.6 Develops
Appendix D - Using the Initrd

Intro and Gathering Information
Part 2 - Preparing the Source Tree
Part 3 - Configuring the Kernel Source
Part 3 Continued - Configuring the Kernel
Part 4 - Building the Kernel
Part 5 - Installing the Kernel
Part 6 - Editing the Boot Loader Configuration
Reboot the Machine (and Enjoy)
Appendix A - Patching the Kernel Source
Appendix B - Building a 2.6 Kernel
Appendix C - Additional Notes as 2.6 Develops
Appendix D - Using the Initrd


Installing the Kernel

First of all, the only truly safe way to install our new kernel, so we don't damage any aspects of our previous configuration, is manually.

This will involve running the make modules_install command to install the module tree under /lib/modules, and copying the kernel image to the /boot directory. That's where it goes on redhat based, and most other systems anyway. However, on some systems it's possible that the kernel image goes in the / directory. We must also copy the System.map file (kernel symbol table) to the boot directory, and edit the boot loader's configuration file.

Before installing the modules, go to /lib/modules and verify that a directory of the same name as our kernel version doesn't exist. It likely won't if you're building a new kernel. In this case, the modules directory is going to be named 2.4.22. This is determined by the Version, Patchlevel, Sublevel, and Extraversion variables in the top level Makefile:



This must be done before you start the build (too late now), but you can add text to the Extraversion that will be included in the kernel's version string. The modules directory will then be named accordingly.

OK, beginning with make modules_install, we now need to have root priviledges to proceed any further. This is done by issuing the su (substitute user) command, and providing the root password when prompted. Note that the prompt will change from a $ to a #, when using the bash shell.



The screen will scroll as make is going through the directories. When it finishes, it will look like this. The last line shows it preparing the module dependencies.



Our modules are now installed in /lib/modules/2.4.22.

The finished kernel image, is located in the arch/i386/boot directory, within the kernel build tree. It is a file named bzImage.

To install it, I'll simply copy it to /boot, as vmlinuz-2.4.22. I like to stick with that convention, though it's arbitrary. You could, I suppose, name the kernel image anything you want as long as you edit the boot loader's config accordingly.



After copying the kernel image, we need to ensure that the permissions are sane. Change them with the chmod command, as shown.

The System.map file, is located in the top level kernel source directory. We will copy it to /boot as System.map-2.4.22 and then move the symbolic link to point to the new System.map file. The -f switch in ln -sf means "force". It essentially overwrites the symbolic link. Double check your typing, whenever you use "force" in any command, as it won't warn or prompt in any way, if you're making a mistake. Before doing this, verify that the current /boot/System.map is indeed a symbolic link and not the file. Rename it, if so.



We are now finished working with the build tree. If you know for sure you don't intend to compile any external modules or software that requires the build tree of the running kernel to be in place, you can delete it.

An example of something that would require it to remain in place, at least until you get it compiled, would be the ALSA project.

There is a symbolic link, in /lib/modules/2.4.22 named build, that points to the location of the build tree. This is how configure scripts find the appropriate kernel source, when compiling external modules.

Myself, I would leave the build tree in place, after typing make clean. This leaves the .config, and the dependency info intact, while cleaning out all the object files and binaries from the build tree. It will remove about 10 megabytes worth of cruft. The make clean command, prepares the tree for a recompile.

The next task, is to configure the boot loader, to boot the new kernel.

Intro and Gathering Information
Part 2 - Preparing the Source Tree
Part 3 - Configuring the Kernel Source
Part 3 Continued - Configuring the Kernel
Part 4 - Building the Kernel
Part 5 - Installing the Kernel
Part 6 - Editing the Boot Loader Configuration
Reboot the Machine (and Enjoy)
Appendix A - Patching the Kernel Source
Appendix B - Building a 2.6 Kernel
Appendix C - Additional Notes as 2.6 Develops
Appendix D - Using the Initrd

Intro and Gathering Information
Part 2 - Preparing the Source Tree
Part 3 - Configuring the Kernel Source
Part 3 Continued - Configuring the Kernel
Part 4 - Building the Kernel
Part 5 - Installing the Kernel
Part 6 - Editing the Boot Loader Configuration
Reboot the Machine (and Enjoy)
Appendix A - Patching the Kernel Source
Appendix B - Building a 2.6 Kernel
Appendix C - Additional Notes as 2.6 Develops
Appendix D - Using the Initrd


Editing the Boot Loader Configuration

There are two mainstream boot loaders for x86 in Linux. GRUB ("Grand Unified Boot Loader") and LILO (Linux Loader). Often, you'll find that both boot loaders are installed and configured, but only one can actually be in use (according to which one is installed in the Master Boot Record). That is the case on this server. There is a configured /boot/grub/grub.conf file, as well an /etc/lilo.conf file.

If you have physical access to the machine, it's a no brainer because you'll see at boot time, which boot loader you are using. However, I don't have physical access to this server. By looking at the contents of /boot (LILO map file present, as well as boot.0300, an undo file for the MBR or boot sector, used for uninstalling LILO) I suspect we are using LILO, but I'm not sure.

To find out for sure, I'm going to make an image of the MBR, and then examine it for strings. If I use the following command as root, it will create a 512 byte dump of the first sector on /dev/hda.

dd if=/dev/hda bs=512 count=1 of=mbr.img

if=/dev/hda is the input file
bs=512 is the number of bytes in both the input and output blocks
count=1 specifies that we only want one block (of 512 bytes)
of=mbr.img is our output file.

Don't screw up with the dd command, or brimstone and fire shall consume thee. You are logged on with effective root credentials, and you are doing a low level operation on the machine's hard disk. It's not going to warn you, it's going to do exactly what you tell it. Triple check your typing.



We obtain root priviledges, type the dd command, view a listing of the file, give ownership to our user (we created the file as root) and then exit the root session. Always exit as soon as you are finished using root priviledges. We then grep for strings. Grep for GRUB first, then LILO. The text GRUB was not found, so it didn't return any output. The string LILO was found. This machine is using LILO.

Viewing the mbr image with an editor in binary mode, confirms. Note the lbaLILO string.



Contrast this, with a dump of the MBR on another machine that's using GRUB.



We will start with GRUB. This is what the /boot/grub/grub.conf file looks like on this machine. (note that it's also called menu.lst, which is a symbolic link to grub.conf)



GRUB isn't terribly difficult to configure, but it is more than a little weird until you understand it. The comments (lines with # in front of them) inform us of the first bit of weirdness. If /boot is a partition, which it is on this machine, the paths to the kernel (and initrd) in grub.conf are relative to /boot. That's simply because there is no concept of a "Linux root filesystem" yet. The "root" is, at that point, the root of the partition where the kernel image is located. With that in mind, it's no longer weird.

Numbering starts at 0 in grub.conf

default=0
This specifies the default boot image (kernel section, or "stanza"). The first one in the list is 0. When we add a second one, for our new kernel, it will be 1.

timeout=10
This is the time in seconds, that elapses before the default choice is automatically started.

splashimage=(hd0,0)/grub/splash.xpm.gz
The image that grub displays as a splash screen. Specified with hard disk device first, as root hasn't been defined yet.

title Red Hat Linux (2.4.18-17.7.x)
The "title" is what will show up in the GRUB boot menu. Pretty fancy, it allows you to use spaces.

Now, under that section:
root (hd0,0)
This is the partition, where our kernel image is to be found. (NOT the Linux root filesystem, yet. That is specified on the same line as the kernel image)

(hd0,0) means the first hard disk, and the first partition. Note that this is weird, if you're used to configuring other boot loaders. Don't be tempted to think it's the same as Windows NT convention in boot.ini. Yes, hard disk numbering starts with 0 for the first disk, but partition numbering starts with 0 for the first partition. However, regardless of how many primary partitions are on the disk, the first logical drive starts at 4. So let's say you had only one primary partition, and one extended partition on the first hard disk. The primary partition would be (hd0,0) and the first logical drive on the extended would be (hd0,4). OK, that's not so bad, right? Also note that there is no distinction between IDE and SCSI disks for this convention in grub.conf, with respect to disk numbering. The way the disks are numbered will depend on which are being initialized first.

kernel /vmlinuz-2.4.18-17.7.x ro root=/dev/hda2

This is the business end, the line that tells grub how to find the kernel. Parameters are also passed on this line. For example, the kernel is told to mount the root filesystem "ro" (read only) initially. The system init scripts remount it read/write later in the startup process. root=/dev/hda2 is telling the kernel where our Linux root filesystem is. This is where it will find /sbin/init.

Recall earlier on, when we edited /etc/fstab to change the LABEL= statements to real partition devices. If you see root=LABEL=/ in your kernel command line, you should change it to the real partition device. (/dev/hda2 in this case)

The next line in the kernel section,
initrd /initrd-2.4.18-17.7.x.img
specifies the initrd (initial ramdisk) image. It gets mounted like a filesystem, and critical drivers can be loaded as modules from there. We will not be specifying an initrd for our new kernel, as we don't use one.

Now, we will add a new section, for our new kernel, leaving the old one exactly as is:



I have specified default=1 to make the second kernel section (our new kernel) the default.

I also added a line, fallback 0 which causes GRUB to "fall back" to the first kernel in the list, if the default choice fails. Otherwise GRUB would just sit there, waiting for command input from a user to recover from that situation. Note that this will not help you with a bad kernel, it will only help if you've stuffed up the section in the file, or the kernel image is not found for whatever reason. If it loads a kernel, the fallback mechanism doesn't come into play.

That's all there is to it, we have a very simple setup here. Note that with GRUB, simply editing the grub.conf file effects the changes. They will be there on the next boot. There's no need to run any sort of binary to reinstate GRUB to change the configuration. (like we must do with LILO)

Here is the existing /etc/lilo.conf file on this machine.

Yours might not look exactly like this, depending on who or what generated the lilo.conf file. Just follow the same conventions used in your file, to be on the safe side.



prompt
This directive tells the LILO boot loader to prompt to choose an operating system.

timeout=50
This directive must be specified along with prompt, otherwise the machine can't be booted remotely. It would sit there waiting for input. It is the time in 10ths of a second, until the default boot image is automatically loaded. A value of 50 means a 5 second delay.

default=linux
This specifies the default boot choice. It is the name given in the label= line, under the desired image section. (stanza) If default is not specified, the image listed first in the file, will be the default boot choice.

boot=/dev/hda
This specifies that LILO is to be installed to /dev/hda, which means the Master Boot Record of the first IDE hard disk. This is what you want, in most cases, though it's possible to install LILO to the superblock (kind of like a boot sector) on the partition you wish to boot from, for use with other boot loaders.

map=/boot/map
This specifies LILO's map file. If not given, it defaults to /boot/map. This file contains the data that the LILO code in the MBR needs to find the rest of itself (secondary stage), and the data the secondary stage uses to load a kernel image.

install=/boot/boot.b
This specifies the location of the file containing the code for the secondary stage, boot.b.

message=/boot/message
This is the location of a file used to display a message when LILO loads. It was traditionally a text file, but depending on your distribution it can be a .pcx image file renamed to message. This is the case here on this machine.

linear
This is copied and pasted from the lilo.conf man page:

Generate 24-bit linear sector addresses instead of cylinder/head/sector (geometric) addresses. Linear addresses are translated at run time to geometric addresses, and are limited to cylinders <= 1023. When using `linear' with large disks, /sbin/lilo may generate references to inaccessible disk cylinders. 'lba32' avoids many of these pitfalls with its use of packet addressing, but requires a recent BIOS (post-1998).

On a large IDE hard disk, we really should be using lba32 instead of linear, but since we have a small /boot partition it doesn't matter. A kernel image will never end up being located beyond cylinder 1023 where it's inaccessible using this method. Linear is normally used for SCSI disks.

So unless you have a small /boot partition, you should certainly use the LBA32 directive so that kernels can be loaded from anywhere on the disk.

Here is how I have edited the lilo.conf file, to add the new kernel:



I changed the timeout value to give someone in the server room 10 seconds to choose a kernel, if it ever comes to that.

I change the default to boot our new kernel, that I labelled 2422. Note that you can't have spaces in the label= name.

Again, we don't specify an initrd file in our new kernel stanza, because we aren't using one for this kernel.

Now that the lilo.conf file has been edited, we must re-instate LILO to effect the changes. This is done by typing the lilo command (or /sbin/lilo if /sbin isn't in your path) as root. This will read the lilo.conf file, rewrite the lilo code in the MBR, and rewrite the map file. Serious business.

LILO always warns if something is wrong, but we can test our configuration before installing it for real, using the -t switch. We can also use the -v switch for more verbose output.



That passed without errors or warnings. Note that the default boot label is indicated with an asterisk.

Once you're sure of your configuration, you can now issue the lilo command for real, without the -t switch.

Intro and Gathering Information
Part 2 - Preparing the Source Tree
Part 3 - Configuring the Kernel Source
Part 3 Continued - Configuring the Kernel
Part 4 - Building the Kernel
Part 5 - Installing the Kernel
Part 6 - Editing the Boot Loader Configuration
Reboot the Machine (and Enjoy)
Appendix A - Patching the Kernel Source
Appendix B - Building a 2.6 Kernel
Appendix C - Additional Notes as 2.6 Develops
Appendix D - Using the Initrd

You are now ready, to reboot your machine to your shiny new kernel. You have taken steps to ensure that you've compiled in the correct drivers needed to boot the system. You have taken steps to preserve your old kernel in case the new one has a problem.

If you are working on a remote server, do this at such a time when you will quickly be able to get someone on site, to go and reboot your machine and choose the old kernel at the boot loader prompt. In fact, you should wait to edit the boot loader configuration until the time that you are ready to reboot.

Enjoy!

Intro and Gathering Information
Part 2 - Preparing the Source Tree
Part 3 - Configuring the Kernel Source
Part 3 Continued - Configuring the Kernel
Part 4 - Building the Kernel
Part 5 - Installing the Kernel
Part 6 - Editing the Boot Loader Configuration
Reboot the Machine (and Enjoy)
Appendix A - Patching the Kernel Source
Appendix B - Building a 2.6 Kernel
Appendix C - Additional Notes as 2.6 Develops
Appendix D - Using the Initrd

Intro and Gathering Information
Part 2 - Preparing the Source Tree
Part 3 - Configuring the Kernel Source
Part 3 Continued - Configuring the Kernel
Part 4 - Building the Kernel
Part 5 - Installing the Kernel
Part 6 - Editing the Boot Loader Configuration
Reboot the Machine (and Enjoy)
Appendix A - Patching the Kernel Source
Appendix B - Building a 2.6 Kernel
Appendix C - Additional Notes as 2.6 Develops
Appendix D - Using the Initrd


There are times when you may need to apply a patch (usually a compressed diff file) before compiling a kernel to correct a problem, or to add features or "hacks".

One good example here are the prerelease kernels. In a stable series like 2.4 that's matured, it should be reasonably safe to try these kernels on your own system or non production system, bearing in mind that they are of beta status. One feature that comes to mind here, is that DRI support for XFree86 4.3 has been included in 2.4.23-pre. If you're using X 4.3, you would otherwise have to compile the external modules from the XFree86 4.3 distribution to get Direct Rendering to work.

Start with a clean build tree. I generally start with freshly unpacked kernel source, depending on the nature of the patch, to avoid problems. At least do make mrproper

First, we download the desired patch and put it in the directory that contains our build tree. (One level up from the top level source directory). This is normally the convention used when diffs are formatted for patching. We then enter the top level source directory, and type the command to apply the patch.



This is a bzip2 compressed diff file. If it is gzipped (.gz) then simply substitute gzip instead of bzip2 in the command.

The -d switch is decompress, and the -c switch causes the output to go to stdout.

The ../patch-2.4.23-pre9.bz2 specifies that the patch file is one directory level up.

The output is piped to the patch program. The -s switch causes it to be silent, and not print any output unless there are errors.

The -p switch tells it to strip directory prefixes from filenames. It's sometimes referred to as the "patch level". It has to do with how directory path prefixes in filenames within the diff are treated. Depending on the level specified, path elements are stripped from the filename. If -p0 is given, the path is used as written. This would imply that you must have the same directory structure that the patch author used, and be at the same level. If -p1 is given, then the first prefix is stripped from the paths in the filenames.

Because we used -s, a successful operation returns no output.

Now, if you're applying a patch that's already decompressed, you can usually apply it like this:

cat ../filename.diff | patch -s -p1

If ever a patching operation fails with errors that say "file to patch?" you have likely used the wrong -p level. If nothing was patched, simply press ctrl-c to abort, and try your command with a different -p level.

After applying this patch in the example above, the EXTRAVERSION variable in the top level Makefile will be -pre9.

Follow the usual procedures for building and installing the kernel.

Intro and Gathering Information
Part 2 - Preparing the Source Tree
Part 3 - Configuring the Kernel Source
Part 3 Continued - Configuring the Kernel
Part 4 - Building the Kernel
Part 5 - Installing the Kernel
Part 6 - Editing the Boot Loader Configuration
Reboot the Machine (and Enjoy)
Appendix A - Patching the Kernel Source
Appendix B - Building a 2.6 Kernel
Appendix C - Additional Notes as 2.6 Develops
Appendix D - Using the Initrd

Intro and Gathering Information
Part 2 - Preparing the Source Tree
Part 3 - Configuring the Kernel Source
Part 3 Continued - Configuring the Kernel
Part 4 - Building the Kernel
Part 5 - Installing the Kernel
Part 6 - Editing the Boot Loader Configuration
Reboot the Machine (and Enjoy)
Appendix A - Patching the Kernel Source
Appendix B - Building a 2.6 Kernel
Appendix C - Additional Notes as 2.6 Develops
Appendix D - Using the Initrd


Well, now that the 2.6.0 Linux kernel has been officially released to the masses, we will point out some differences in the build and configuration process. While the same principles apply, there are some differences and potential "gotchas" in the configuration .

First of all, although this is considered the "latest stable release" it still needs more testing on a broader range of systems, and therefore it's probably not a good idea to use this on production systems just yet. There also may be some miscellaneous broken drivers in the tree, waiting for someone to test and fix. Since it's stable (and pretty darned good) on the majority of hardware, it is time to make an official release. The kind of testing and fine tuning that has to take place, can't really occur until it's been adopted.

Why would we want to try this new version, when the 2.4 kernel series is rock solid, and is going to be maintained for considerable time? We are of course, looking for improvements of which there are many. Following is a semi-official document that discusses them:

The Wonderful World of Linux 2.6

Unpack the kernel source in the usual manner, just the same as you would for the 2.4 kernel.

Read the Documentation/Changes file and make sure you have the prerequisite versions of utilities installed. Extremely important, are the module-init-tools for the kernel module loading system has changed drastically.

CD into the directory, and issue make mrproper

Note that they have silenced much of the build output on the screen, it no longer displays the entire commands being executed. This pretties it up some, but if you wish to go back to the old way, where you can see the full output, the kernel build system looks for an environment variable. For the Bash shell, type the following command before you start (C shell variants use the setenv command)

export KBUILD_VERBOSE=1

Now, we are ready to configure the kernel options. The machine I'm using here, is my home PC, a desktop system. It is a Pentium4 2 GHz system, on an Intel i845 chipset (Gigabyte motherboard). It is running Slackware Linux. Similar chipset as the server used for the 2.4 kernel examples. My hardware is well supported, and I've been using the 2.5/2.6-test kernels for a while now. This isn't something I'd put on someone else's server yet though!

Do not use a .config file from kernel 2.4 and the make oldconfig command. You are just asking to have problems if you do.

There are a few new options for configuring the kernel source. The make xconfig command is now a qt based GUI instead of TK. It requires that you have the qt GUI toolkit library (and qt-devel depending on your distribution) installed. There is also make gconfig that launches a GTK+ based GUI configurator. It requires that the GTK+ toolkit be installed.

Click Here to see a screenshot of xconfig (png in new window)

Note that the colours and style come from your KDE configuration, whether you're running it at the time or not. (hopefully you have better tastes than I)

Click Here to see a screenshot of gconfig (png in new window)

We are going to use make menuconfig



The first thing you'll notice, is that they've moved many of the options into a separate Device Drivers submenu, which makes the main menu look a bit smaller.

It is now time to put on your thinking cap, and consider what you already know about configuring a 2.4 kernel. Be mindful of options that are enabled by default. Don't disable them unless you have read the help item, and understand. For example, under General Setup



You'll see an option Support for paging of anonymous memory. If you were to disable that option, the kernel would not be able to use swap devices!

Also of significance here is Kernel .config support which stores the kernel's configuration details within the kernel image. It can be retrieved from a running kernel. Read the help item, but this is what it's about:

"This information can be extracted from the kernel image file with the script scripts/extract-ikconfig and used as input to rebuild the current kernel or to build another kernel"

If you enable the /proc/config.gz support, all you have to do is copy the /proc/config.gz file somewhere and gunzip it and rename it to .config to have a working config.

I wouldn't normally enable that, as it would enlarge the kernel image, and I always know what options I personally used to configure a kernel. (I'll have saved my .config file)

Next on the agenda, is Loadable Module Support. There are a few new options here.



I'd recommend enabling Module Unloading and Forced Module Unloading (so that you can use rmmod -f to remove a module from the running kernel if necessary. Always good to have options, but know what you're doing before forcing a module unload. You could be in for a nasty surprise). Read the help, but if you don't enable module unloading, you won't be able to unload modules once loaded. I don't use Automatic kernel module loading ("kernel module loader") on my own systems, but you will (probably) want to. I either just load modules manually, or make scripts to do it semi-manually. Automatic module loading invokes modprobe when a particular module is called for and it may be important, for your distribution.

Next, I'll point out a few differences under Processor Type and Features



First of all, there's a subarchitecture type. That'll probably be already configured for you by menuconfig, but it's now an option.

There's a new option called Preemptible Kernel, that will allow some low priority kernel mode processes to be pre-empted by higher priority processes (e.g. keyboard input), to improve the general responsiveness of the system while under load. This is purported to be an improvement for desktop systems.

The rest of this is similar to the 2.4 configuration. On this system I enable local apic support for uniprocessors, so that my advanced programmable interrupt controller can route IRQs.

Power Management, Bus Options and Executable File Formats are self explanatory, if you are familiar with the 2.4 kernel configuration.

The Device Drivers submenu, should look somewhat familiar to you.



Basically, go through the categories and configure what's needed for your system. I'll point out a few interesting differences, and potential "gotchas" here.

Generic Driver Options currently does nothing. Presumably, it's a category where miscellaneous drivers are to be added, in future, or perhaps we haven't enabled any options that would cause anything to appear under that menu.

Skipping down to ATA/ATAPI/MFM/RLL support, the options here haven't changed much. The only difference is, you may no longer need to configure SCSI emulation support, as CD writing using the ATAPI driver (ide-cd) is now supported.



Now, IEEE 1394 (FireWire) support is enabled by default. Disable it if you don't have any firewire hardware.

The Networking support menu, now contains all of the networking options, including those that were previously under Network Device Support. You have to be careful to enter the submenus within, and configure what is needed for your system. For example, my D-Link 530TXS network card uses the Sundance Alta driver, under the Ethernet (10 or 100Mbit) submenu.



Now, under Input Device Support in the final they've removed some of the options that could be potential "gotchas", but there are still a few things to be aware of.



The horizontal and vertical screen resolutions, are for graphics tablets and the like. They are ignored for normal mice.

Be sure and enable Serial Port Line Discipline if you intend to use serial input devices (like a serial mouse)

Also, enable Misc and enable PC Speaker Support if you want to hear beeps and boops from the console.

Note: If you should happen to see the following extra options, in the example below, concerning mice and keyboards/keyboard controllers, make sure you enable them. Legacy /dev/psaux support may be necessary for your existing XF86Config file to work for your ps/2 mouse. These are "gotchas". If your Input Device Support menu looks like the example above, then those options are safely enabled by default. It seems that if I start with a fresh build tree, on the first build I don't see those extra options. If I make mrproper and menuconfig again, they are selectable.



Now, under Character Devices there's a separate submenu for Serial Drivers. Just be aware of that, though by default what you need should be enabled. Character Devices is also where you enable AGP support, and support for Direct Rendering, just like in the 2.4 kernels.



Now, under Graphics Support again, they've removed some "gotchas" in the final but there are a few points to cover.



Now, Framebuffer Support. First of all, it now appears that the Framebuffer driver with ATI Radeon video cards can now coexist with agpgart and DRI! (in previous versions it did not, there was a conflict with a kernel context). I now have both working on my rig. Yay.

If you do configure framebuffer support, here is one gotcha. Go down to Console display driver support and enable Framebuffer Console support. Without it, you can't have your framebuffer console. Also enable Video Mode Selection Support



Just for interest's sake, one of the "gotchas" in here was VGA text console... it was possible for that to be disabled which caused nothing but a black screen on trying to boot your new kernel. This often happened, when people used their old configs with the 2.5/2.6-test kernels. So if you did use a previous .config file from a 2.4 or earlier 2.5/2.6-test kernel, or you are seeing that as an option for whatever reason, make sure that is enabled! Note that if you used a config file from the 2.6-test series, you may still see some of these "gotchas" as selectable options. I do in one of my other build trees. My next build I am going to configure from scratch.

Next, under Sound there have been some changes. Namely, the ALSA (Advanced Linux Sound Architecture) System has been merged into the kernel. So if your distribution uses ALSA, you need not build external kernel modules afterwards.

The original OSS (Open Sound System) drivers are still available, for those who would rather fight than switch. (Like me... I just have a plain jane Soundblaster PCI... why would I want this complex ALSA stuff when I can just type modprobe es1371 using the old OSS driver that works perfectly)



Now, not all audio applications on your system will be up to speed here, so you had better enable backwards compatible OSS support options here, like shown. (essentially so apps can still use /dev/dsp and /dev/mixer)

Enter the PCI Devices submenu, and enable support for your card. Also check and see if you want anything under Generic Devices

Alternatively, disable the ALSA support altogether, and enable the OSS support options instead.

Configure your USB Support options, if you use USB devices. (I don't). It should be similar to your kernel 2.4 USB configuration.

Now, back out at the main menu, Filesystems has changed a little. They've condensed some options into submenus. Otherwise, it's the same options you will want to configure.



Again, don't forget that anything needed to boot the system (like ext2/ext3 filesystem support) must be built right in your kernel image, not as modules.

Enter the Kernel Hacking submenu. There are a couple of items enabled by default, that you can disable, if you don't intend to debug the kernel. You can always recompile with those options turned on, if you need to seek that kind of help or you wish to file a bug report and need to gather useful information.



After you are finished configuring your kernel options, exit menuconfig and save your changes.



Now, as you can see, the build process has changed slightly. It's now even easier. There's no more make dep (dependency info is generated automatically). Simply typing make builds the bzImage and the modules.

Note that the new kernel build system will still take the old commands (make dep, bzImage, modules), without causing any failures. This is just so they don't break people's build scripts and the like.

Now su to root, and make modules_install

Manually install your new kernel image (arch/i386/boot/bzImage), and System.map file in the same manner as 2.4, and add your new kernel to your boot loader's configuration. Be sure and preserve your existing kernel, as always.

Intro and Gathering Information
Part 2 - Preparing the Source Tree
Part 3 - Configuring the Kernel Source
Part 3 Continued - Configuring the Kernel
Part 4 - Building the Kernel
Part 5 - Installing the Kernel
Part 6 - Editing the Boot Loader Configuration
Reboot the Machine (and Enjoy)
Appendix A - Patching the Kernel Source
Appendix B - Building a 2.6 Kernel
Appendix C - Additional Notes as 2.6 Develops
Appendix D - Using the Initrd

Intro and Gathering Information
Part 2 - Preparing the Source Tree
Part 3 - Configuring the Kernel Source
Part 3 Continued - Configuring the Kernel
Part 4 - Building the Kernel
Part 5 - Installing the Kernel
Part 6 - Editing the Boot Loader Configuration
Reboot the Machine (and Enjoy)
Appendix A - Patching the Kernel Source
Appendix B - Building a 2.6 Kernel
Appendix C - Additional Notes as 2.6 Develops
Appendix D - Using the Initrd


The 2.6 series kernel will be going through considerable changes as it matures. For example, we have a 2.6.1 release already. As things progress, I may make further additions to this howto and mention some of the more significant new configuration options or features, so check back periodically.

Optimizing for Size

In addition to being careful to only include drivers and features that you need in your main kernel, and building non-essential or not always used drivers as modules, compiler optimizations can also reduce the size of your compiled kernel code.

In kernel version 2.6.1, they have added a new configuration option to Optimize for Size, which causes the build scripts to pass the -Os optimization flag to the compiler, instead of the long standing Makefile default of -O2 (that's an upper case 'o', not a zero)

This size optimization, can result in significant savings in the size of the generated code, even more so with newer versions of the gcc compiler. At this time, that's gcc 3.2.x or gcc 3.3.x (gcc 3.3 really is a bit young for compiling the kernel at this time, though should be safe in most cases. I'm using gcc 3.3.2 now.)

You can read about compiler optimizations here:

Options That Control Optimization

The kernel is not the thing to use to experiment with compiler optimizations, the link is for interest's sake.

Previously, in order to build the kernel with -Os, you had to edit the top level Makefile. I have been doing that for quite a while, and it hasn't ever done any harm to my kernels and generally seems to be a good thing to reduce the size of the kernel. The reasoning is, that if the code is smaller, more of it can fit in cache memory.

Now that it's a configurable option, that lends more validity to it, and I'll pass it on to you.

Under General Setup, activate the Remove Kernel Features choice.



Press enter, to bring up the menu and you'll see the new Optimize for Size configuration option.



While you're in there, you can safely disable the Load all symbols for debugging option as well.

Don't disable Eventpoll or Futex support unless you specifically know what you are doing. (you won't want to do that on a normal system)

A word about the schedulers in the 2.6 kernel. Because different machines have different purposes, and therefore different workloads, a choice of three block i/o schedulers are selectable at boot time, by passing the elevator="" (="as", "deadline" or "noop") parameter. For example in an append= directive in the lilo.conf file.

The Anticipatory I/O Scheduler is the default, and deemed to be the best for most common workloads. It has algorithms that pause after read operations on the assumption that another nearby read will be needed.

This is not always the best behaviour, for example, on some database servers where there are mostly single quick reads to areas all over the disk, it is recommended to use the Deadline Scheduler which minimizes seek operations and only allows an i/o request to wait for a specific period of time. It is also smaller and less complex.

Because at this time, I only want to use the Anticipatory Scheduler on my workstation, I have disabled the other two. If I ever want to switch to the deadline scheduler, I'll just enable the option again and build a new kernel. You may not want to do that... leaving the other schedulers enabled probably doesn't increase the size that much in itself. Even if it did, it's not really code that's going to get loaded.

Now, using -Os (optimize for size) I get a nice small 770 kilobyte kernel image. That's pretty good for 2.6, considering that I have most of my core functionality compiled right in, and I'm using ACPI.

Intro and Gathering Information
Part 2 - Preparing the Source Tree
Part 3 - Configuring the Kernel Source
Part 3 Continued - Configuring the Kernel
Part 4 - Building the Kernel
Part 5 - Installing the Kernel
Part 6 - Editing the Boot Loader Configuration
Reboot the Machine (and Enjoy)
Appendix A - Patching the Kernel Source
Appendix B - Building a 2.6 Kernel
Appendix C - Additional Notes as 2.6 Develops
Appendix D - Using the Initrd

Intro and Gathering Information
Part 2 - Preparing the Source Tree
Part 3 - Configuring the Kernel Source
Part 3 Continued - Configuring the Kernel
Part 4 - Building the Kernel
Part 5 - Installing the Kernel
Part 6 - Editing the Boot Loader Configuration
Reboot the Machine (and Enjoy)
Appendix A - Patching the Kernel Source
Appendix B - Building a 2.6 Kernel
Appendix C - Additional Notes as 2.6 Develops
Appendix D - Using the Initrd


In this tutorial I have advocated not using an initrd (initial ramdrive) when compiling a custom kernel, because we can make everything needed to start the system, built right in. In the past, I've always managed to get along without one on any system I've compiled a kernel for. For example, on Redhat systems I got around using one by changing the mount by label related configuration in /etc/fstab and the boot loader's configuration file. With that detail, it was surmountable.

Times have changed.

Modern distributions using the 2.6 kernel, may use the udev system to create and initialize the system's device nodes. In fact they may rely on it completely without providing an underlying /dev directory populated with the device nodes necessary to start the system. Backwards compatibility be damned.

For example, while playing with Fedora Core 3 on a spare hard disk I discovered that my freshly built 2.6.10 kernel.org kernel was unable to boot the system. The first visible symptom was the inability to create an initial console. After that the boot process would just hang.

So I recompiled with different display options (e.g. no framebuffer) and that still didn't work. I then realized it had nothing to do with my graphics/console configuration, it was because the necessary device nodes weren't available at that stage of the boot. Chicken before egg.

I needed to use an initrd so that udev could initialize the devs, if I wanted to boot a kernel on that system. Now I suppose I could have booted up with a rescue disk of some sort to use mknod to create a real /dev/console and /dev/hda and friends but why fight it.

Another reason that you might certainly need an initrd, is if you or your distribution's installer has set up the partitions to be LVM (Logical Volume Manager) volumes. If the root partition is a logical volume, you need an initrd image that initializes it or the system can't boot. For example, the "automatic partitioning" choice during the installation of Fedora Core 3 creates the root partition as a LVM logical volume.

So, the first step is to go back and reconfigure the kernel to enable the necessary choices to use an initrd and the udev system.

Under General Setup, ensure that hotplug support is enabled.



Under Device Drivers, in the Block Devices submenu, be sure and enable RAM DIsk Support, and Initial Ram Disk Support.

Note: Newer distros that use an initrd are increasing the default size of the RAM disk. Fedora Core 4 specifies 16384, and SuSE 9.3 specifies 64000, for examples.



You also should enable loopback device support.

Under Filesystems, enable ext2 filesystem support. It's what is used in the initrd image.

Now, under Filesystems in the Pseudo Filesystems submenu, make sure that sysfs is enabled. (It should be, unless you specifically disabled it)



A bit off topic here, but if you are using LVM for your partitions, you also need to enable the following options under Device Drivers, in the "Multi Device Support" submenu.



Build your kernel like normal, install your bzImage and do make modules_install (it will be necessary to create the initrd)

The mkinitrd utility is a script provided (perhaps customized) by your distribution vendor. Please see your distribution's documentation or man page for mkinitrd, because the usage differs.

It's very simple to use, for example:

mkinitrd /boot/initrd-2.6.10.img 2.6.10

The first argument is the name of the initrd image you are creating. The second argument is the kernel version string. (i.e. Version, Patchlevel, Sublevel and Extraversion, reflecting the name of the modules directory for that kernel in /lib/modules)

The command should complete silently, if successful. (use the -v switch if you want verbose output)

That was all fine and dandy on the hard disk install with normal IDE disks, but I ran into a snag while trying it in a vmware virtual machine, which was emulating a scsi adapter.

[root@localhost linux-2.6.10]# /sbin/mkinitrd /boot/initrd-2.6.10.img 2.6.10
No module BusLogic found for kernel 2.6.10, aborting.

Oops! What if you see an error like that? The mkinitrd script may want to preload some modules, and also may want to incorporate modules that are defined in your /etc/modprobe.conf file.

If you see that, go back and reconfigure your kernel and build that device as a module instead of built in, or edit your modprobe.conf file. (I'd recommend leaving modprobe.conf alone, so you can still work with vendor supplied kernels)

If you have to reconfigure your 2.6 kernel, you don't need to make clean. Just run menuconfig and change it to build that device as a module and run make. It will only rebuild and relink the objects it needs to and may only take a few seconds.

After building the low level SCSI driver as a module and reinstalling the kernel, here's the (successful) output of mkinitrd -v

[root@localhost linux-2.6.10]# /sbin/mkinitrd -v /boot/initrd-2.6.10.img 2.6.10
Creating initramfs
Looking for deps of module scsi_mod
Looking for deps of module sd_mod
Looking for deps of module unknown
Looking for deps of module BusLogic
Looking for deps of module ide-disk
Looking for deps of module ext3
Using modules: ./kernel/drivers/scsi/BusLogic.ko
/sbin/nash -> /tmp/initrd.LF5984/bin/nash
/sbin/insmod.static -> /tmp/initrd.LF5984/bin/insmod
/sbin/udev.static -> /tmp/initrd.LF5984/sbin/udev
/etc/udev/udev.conf -> /tmp/initrd.LF5984/etc/udev/udev.conf
copy from /lib/modules/2.6.10/./kernel/drivers/scsi/BusLogic.ko(elf32-i386) to /tmp/initrd.LF5984/lib/BusLogic.ko(elf32-i386)
Loading module BusLogic

After you get your kernel installed, your initrd image created (and copied to /boot in the process) you must edit your boot loader's configuration file.



The kernels worked perfectly in Fedora Core 3 after taking these steps.

Intro and Gathering Information
Part 2 - Preparing the Source Tree
Part 3 - Configuring the Kernel Source
Part 3 Continued - Configuring the Kernel
Part 4 - Building the Kernel
Part 5 - Installing the Kernel
Part 6 - Editing the Boot Loader Configuration
Reboot the Machine (and Enjoy)
Appendix A - Patching the Kernel Source
Appendix B - Building a 2.6 Kernel
Appendix C - Additional Notes as 2.6 Develops
Appendix D - Using the Initrd

If compiling the 2.6 kernel with the gcc 4.0 compiler (you probably shouldn't be if you can help it), do not use "Optimize for Size" (-Os) for it may subtly break some drivers at this time. The latest kernel at this time is 2.6.12-rc6, soon to be 2.6.12.

Fedora Core 4 uses gcc 4.0.0 as the system compiler and since I've taken the -Os optimization for granted (has worked for years, and is fine with gcc 3.4.x), I ended up with a humdinger of a problem.

Somehow the RTNETLINK (or related) code got subtly broken, and network interfaces weren't getting routes assigned by the "ip route" command at boot. Using the old "route add" command manually after the system was up, worked fine. It was a very strange problem that had me chasing my tail for several hours, modifying the networking config and retrying.

It turned out to be the usage of -Os, so I pass this on so nobody else makes this mistake. The only good part about beating your head against the wall is that it feels so darned good when you finally stop.

Also, at the time of writing, the i2c drivers do not compile with gcc 4.0 without patching the kernel sources. I think the patch will be included very soon, so this point may be irrelevant by the time you read this. This definitely applies to kernel 2.6.11 and sub releases (e.g. 2.6.11.12).

The i2c compile problem is fixed in 2.6.12.