Chapter 7. Configuring a Linux Kernel

Table of Contents

Introduction
Obtaining Hardware Information
Introduction
Device Information
Configuring a Linux Kernel
Kernel Modules
Using Gentoo's genkernel Script
Manually Configuring a Kernel
Building a Linux Kernel
Rebuilding a Kernel
Initial ram file systems
Configuring the Boot Loader
Installing GRUB
Configuring GRUB
Troubleshooting Boot Failures
When a system fails to boot...
Kernel Boot Failures
System Boot Failures
Exercises

Introduction

The Linux kernel is responsible for the majority of the hardware support. It contains the drivers to access and communicate with hardware. However, there are also quite some user-space tools required in order to successfully work with the hardware. For instance, support for printing inside the kernel is limited to support to the LPT printer port or USB, but the printer drivers themselves are user-space.

Another example are scanners: inside the kernel, you need either USB or SCSI support, but there are no drivers for scanners themselves. Those are available in the user-space.

Terms like user-space (everything running as a regular process or data found in non-kernel-reserved memory) and kernel-space (in-kernel tasks or data in kernel-reserved memory) are not that frequently used in documentation about applications, but for drivers, the distinction is quite important. Everything in kernel-space can have quite an impact to performance (it must be fully tuned and proofread by various developers before it is accepted). As such, if particular drivers can be made part of a user-space design (this is not often possible) it is preferred to make them user-space drivers.

To support all the hardware in your system well, you first need to identify what hardware is inside your system. Then, you need to find the correct configurations inside the Linux kernel that match against the hardware. Before building the Linux kernel, you also need to include support for the non-hardware related features you need (such as filesystem support). Once the kernel is built, you can store it to disk and update the boot loader to use the new kernel. Finally, you install and configure the user-space tools needed to deal with your hardware.

Obtaining Hardware Information

Introduction

If you don't know what hardware is inside your system (and I'd be very surprised if you know all components, including vendor and type of your system) you will be glad to know Linux has quite some interesting tools to tell you what it found. The results of these tools are regardless of whether or not your kernel has support for these devices (although some small support is required, but most, if not all default kernels have this included).

Device Information

Processor

Information regarding the processor(s) in your system can be found inside the /proc/cpuinfo file. This file is not a real file but a representation of what the Linux kernel finds in your system. In effect, every file in the /proc file system is a representation of the kernel's information and every time you read it it gives you the last known state.

$ cat /proc/cpuinfo
processor    : 0
vendor_id    : GenuineIntel
cpu family   : 6
model        : 13
model name   : Intel(R) Pentium(R) M processor 1.73GHz
stepping     : 8
cpu MHz      : 800.000
cache size   : 2048 KB
fdiv_bug     : no
hlt_bug      : no
f00f_bug     : no
coma_bug     : no
fpu          : yes
fpu_exception: yes
cpuid level  : 2
wp           : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
               mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss
               tm pbe nx est tm2
bogomips     : 1597.26
clflush size : 64

The information might overwhelm you - don't let it. The most interesting information here is the model name as it effectively tells you what brand and type of CPU this is. If you have multiple CPUs inside your system (or multiple cores) then you'll find multiple entries - one for each CPU / core.

Memory

Similar to CPU information, you can view the information from the /proc/meminfo file to obtain information regarding your memory. Or, you can use the free command to obtain the current memory usage statistics - including the total amount of memory your system has.

PCI Devices

PCI device information can be obtained using the lspci tool. Just entering lspci already gives you a nice overview of the PCI devices found inside your system. I recommend to use lspci -k as it will also display which kernel drivers are already used to manage the PCI device:

# lspci -k
00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 03)
        Subsystem: Fujitsu Technology Solutions Device 107d
        Kernel driver in use: agpgart-intel
00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
        Subsystem: Fujitsu Technology Solutions Device 107d
00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
        Subsystem: Fujitsu Technology Solutions Device 107d
00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 04)
        Kernel driver in use: pcieport
00:1c.1 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 2 (rev 04)
        Kernel driver in use: pcieport
00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 04)
        Subsystem: Fujitsu Technology Solutions Device 107d
        Kernel driver in use: uhci_hcd
00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 04)
        Subsystem: Fujitsu Technology Solutions Device 107d
        Kernel driver in use: uhci_hcd
00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 04)
        Subsystem: Fujitsu Technology Solutions Device 107d
        Kernel driver in use: uhci_hcd
00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 04)
        Subsystem: Fujitsu Technology Solutions Device 107d
        Kernel driver in use: uhci_hcd
00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 04)
        Subsystem: Fujitsu Technology Solutions Device 107d
        Kernel driver in use: ehci_hcd
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev d4)
00:1e.2 Multimedia audio controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 04)
        Subsystem: Fujitsu Technology Solutions Device 107d
        Kernel driver in use: Intel ICH
00:1e.3 Modem: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Modem Controller (rev 04)
        Subsystem: Fujitsu Technology Solutions Device 107d
00:1f.0 ISA bridge: Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge (rev 04)
        Subsystem: Fujitsu Technology Solutions Device 107d
00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller (rev 04)
        Subsystem: Fujitsu Technology Solutions Device 107d
00:1f.2 SATA controller: Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 04)
        Subsystem: Fujitsu Technology Solutions Device 107d
        Kernel driver in use: ahci
00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 04)
        Subsystem: Fujitsu Technology Solutions Device 107d
06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10)
        Subsystem: Fujitsu Technology Solutions Device 107d
        Kernel driver in use: r8169
06:04.0 Network controller: Intel Corporation PRO/Wireless 2200BG [Calexico2] Network Connection (rev 05)
        Subsystem: Intel Corporation Device 2702
        Kernel driver in use: ipw2200
        Kernel modules: ipw2200
06:09.0 CardBus bridge: Texas Instruments PCIxx21/x515 Cardbus Controller
        Subsystem: Fujitsu Technology Solutions Device 107d
06:09.2 FireWire (IEEE 1394): Texas Instruments OHCI Compliant IEEE 1394 Host Controller
        Subsystem: Fujitsu Technology Solutions Device 107d
06:09.3 Mass storage controller: Texas Instruments PCIxx21 Integrated FlashMedia Controller
        Subsystem: Fujitsu Technology Solutions Device 107d
        Kernel driver in use: tifm_7xx1
        Kernel modules: tifm_7xx1
06:09.4 SD Host controller: Texas Instruments PCI6411/6421/6611/6621/7411/7421/7611/7621 Secure Digital Controller
        Subsystem: Fujitsu Technology Solutions Device 107d
        Kernel driver in use: sdhci-pci
        Kernel modules: sdhci-pci

This gives all the information you might need to know about your PCI devices. For instance, to find out what graphical controller you have (video card), look for the "VGA compatible controller" entry.

The kernel driver/module information offered in the output is only available if the mentioned driver is in fact used on the system. When you are installing a Linux system from another Linux environment, chances are that this is indeed already the case.

USB Devices

Similar to the lspci tool, there is also an lsusb tool showing you which USB devices are attached to your system:

# lsusb
Bus 001 Device 001: ID 1d6b:0002  
Bus 005 Device 001: ID 1d6b:0001  
Bus 004 Device 001: ID 1d6b:0001  
Bus 003 Device 002: ID 04b0:012e Nikon Corp. Coolpix 5600 (ptp)
Bus 003 Device 001: ID 1d6b:0001  
Bus 002 Device 001: ID 1d6b:0001

To find out which device file is used, check the dmesg output (dmesg returns the kernel message output):

# dmesg | tail
sd 4:0:0:0: [sdb] Mode Sense: 18 00 00 08
sd 4:0:0:0: [sdb] Assuming drive cache: write through
sd 4:0:0:0: [sdb] 1990656 512-byte hardware sectors: (1.01 GB/972 MiB)
sd 4:0:0:0: [sdb] Write Protect is off
sd 4:0:0:0: [sdb] Mode Sense: 18 00 00 08
sd 4:0:0:0: [sdb] Assuming drive cache: write through
 sdb: sdb1
sd 4:0:0:0: [sdb] Attached SCSI removable disk
sd 4:0:0:0: Attached scsi generic sg1 type 0
usb-storage: device scan complete

In this example, the device is known as /dev/sdb and has one partition (/dev/sdb1).

Configuring a Linux Kernel

There are two ways you can configure a Linux kernel in Gentoo Linux. One is the easiest method, yet not 100% reliable regarding supported hardware: it is a script Gentoo provides that builds a Linux kernel with a generic configuration and lots of loadable modules to include as much hardware support as possible. It works well for standard setups (both hardware and system setup) but might fail for more complex systems. The second method is the most reliable - you configure everything manually yourself. If it fails, it's most likely your own fault.

But before we focus on these methods, a small introduction to the Linux kernel modules administration-wise.

Kernel Modules

The Linux kernel is a file loaded into memory by the boot loader. However, Linux supports loadable kernel modules.

A Linux kernel module is a part of the Linux kernel which can be dynamically loaded and unloaded from memory. As such, it is possible to build a kernel which supports certain hardware, but doesn't load support for these modules until absolutely necessary.

Kernel modules are often used for detachable devices (such as USB devices) but also for distributions who want to provide a kernel to their users regardless of the hardware these users own: during the boot-up sequence, the distribution will load the modules needed to support the hardware found and leave all other modules untouched.

It is important to understand though that these modules are read from somewhere - you can't put the driver for your disk in a module and store that module on disk - the Linux kernel doesn't know what a disk is at that point and can therefore not find the module. Similar, don't put support for a particular file system (such as ext3) in a module and store that module on an ext3 file system.

To be able to use kernel modules even though they might be required to access devices such as disks, you can create an intermediate root disk (initial root disk or initrd or initial ram file system or initramfs). This contains the modules that might be needed in order to successfully boot the system. Support for the initrd or initramfs format is built in-kernel (in-kernel is the term denoting that support is not built as a kernel module but immediately made part of the Linux kernel image loaded by the boot loader).

The boot loader itself is responsible for placing the initrd or initramfs in memory and informing the Linux kernel where the initial root disk/file system can be found.

Working with Modules

The three most important commands to use for kernel modules manipulation are lsmod, modprobe and rmmod.

To list the currently loaded modules, use lsmod:

# lsmod
Module                  Size  Used by
ieee80211_crypt_wep     3584  1 
i915                   29184  2 
drm                    69664  3 i915
ieee80211_crypt_tkip     8896  0 
pcmcia                 31764  0 
sdhci_pci               6976  0 
sdhci                  14660  1 sdhci_pci
yenta_socket           22860  1 
ipw2200               133492  0 
mmc_core               42068  1 sdhci
rsrc_nonstatic          8960  1 yenta_socket
pcmcia_core            31248  3 pcmcia,yenta_socket,rsrc_nonstatic
tifm_7xx1               5568  0 
tifm_core               6420  1 tifm_7xx1

The lsmod output gives you what modules are loaded, the size it takes in memory and how many/what other modules use it.

To remove a loaded module, first ensure that the module is not used by any other module any more (i.e. the "Used by" listing should be empty in the lsmod output) and then use rmmod:

# rmmod ipw2200

If you want to load a module in memory, you should use modprobe[1]:

# modprobe ipw2200

One of the advantages of using modules is that you can pass on additional options to a module, effectively changing its behaviour. But first some information on getting more information on modules.

An interesting command is modinfo, which displays information about a module. Although its output might seem cryptic, it nevertheless gives some interesting pointers to what options a module supports.

# modinfo uvcvideo
filename:       /lib/modules/3.1.6/kernel/drivers/media/video/uvc/uvcvideo.ko
version:        v0.1.0
license:        GPL
description:    USB Video Class driver
author:         Laurent Pinchart <laurent.pinchart@skynet.be>
srcversion:     6B23A0D849FE5EC0262441F
alias:          usb:v*p*d*dc*dsc*dp*ic0Eisc01ip00*
alias:          usb:v1C4Fp3000d*dc*dsc*dp*ic0Eisc01ip00*
...
depends:        
vermagic:       3.1.6 SMP preempt mod_unload 
parm:           clock:Video buffers timestamp clock
parm:           nodrop:Don't drop incomplete frames (uint)
parm:           quirks:Forced device quirks (uint)
parm:           trace:Trace level bitmask (uint)
parm:           timeout:Streaming control requests timeout (uint)

The above example shows that the uvcvideo module uses the GPL license, is the USB Video Class driver, ... and supports parameters clock, nodrop, quirks, trace and timeout. Of course, it does not give you information what these parameters mean, but that is what you have Google for, right?

Anyway, suppose you want to load the uvcvideo module with the nodrop=1 argument (you might be instructed to do so from a bugreport or forum posting). You can do this using modprobe:

# modprobe uvcvideo nodrop=1

This does not make the option permanent though: when you reboot, the module will be loaded in without this option. And repeatedly rmmod'ing the module just to load it again with a parameter is quite resource-intensive. The solution is to tell modprobe that a particular option should be set by default. This can be accomplished by setting the necessary directives in /etc/modprobe.conf or in a file inside the /etc/modprobe.d directory. The latter is more often used: people or projects create a file inside /etc/modprobe.d named after the module itself, which makes management easier.

The content of /etc/modprobe.d/uvcvideo in the previous example would then be:

options uvcvideo nodrop=1

Loading Modules

By default, Linux will load the modules you need for your system. It relies on hardware detection (modern hardware always exposes information about itself on a standardized manner) combined with the drivers of the kernel modules, which describe for which hardware they are made (and which other modules they require). What happens then is that udev (we'll talk about udev in the next chapter) gets informed by the Linux kernel about new hardware being detected. Udev then triggers a modprobe for that hardware, and based on the module information, modprobe knows which module to load.

The module information is generated by depmod when kernel modules are installed (copied) to a system. That's a "nice-to-know" item, because it will happen transparently for the user (you'll most likely never need to run depmod yourself).

However, not all drivers know up-front which hardware they support (some hardware doesn't expose this information) or they collide with other drivers and, as a result, a system is configured not to autoload any module for that hardware. When you are in such a situation, you can still instruct your system to automatically load a particular kernel module at boot time. All you need to do is add the kernel module name to /etc/conf.d/modules. The file is self-explanatory, but below you can find an example for auto-loading the ipw2200 module.

modules="ipw2200"

You can also ask your system not to automatically load a particular module. To accomplish this, add the kernel module name as a blacklist inside /etc/modprobe.d/blacklist.conf

blacklist uvcvideo

Blacklisting a module doesn't mean that the module cannot be loaded any more. It means that the automated load, based on the hardware information, is disabled. In other words, the link between a hardware device id and the module is blacklisted. A manual modprobe will still do the trick, and if the hardware isn't managed by another module yet, then this module will handle the hardware device.

Using Gentoo's genkernel Script

Gentoo has a script called genkernel which builds a complete Linux kernel based on some default configuration. Most hardware support is put in loadable modules although the configuration attempts to put all required device support in-kernel.

To use genkernel, we first need to install it. As root, execute the following command (software installation is covered later in this book):

# emerge genkernel

The installation shouldn't take long. Once finished, run the genkernel tool with the all argument (this assumes that a Linux kernel source code is already installed - if Gentoo has been installed, this is already the case):

# genkernel all

Once finished, the script will have created the Linux kernel itself, the various modules and an initrd file containing the necessary modules that might be required to boot the system. The Linux kernel file and initial root disk are then used by the boot loader to boot up Linux.

Simple, isn't it?

Manually Configuring a Kernel

Building a Linux kernel can take a while, but the majority of time comes in the configuration of the kernel. Especially the first Linux kernel configuration might even take over an hour to complete because there are so many options to select (or deselect). Luckily, configurations can be saved and reused later on, so subsequent configurations will be much faster.

Loading the Kernel Configuration Utility

The Linux kernel provides its own configuration utility; if you go to the Linux source code and type in "make menuconfig" you'll be greeted with the index of the Linux kernel configuration:

# cd /usr/src/linux
# make menuconfig

Note

The visual representation (more specifically, the location of the menu entries) might be different on your system. The location of settings changes very often and chances are that the kernel version you are using is different from the one this chapter is based upon.

---------------  Linux Kernel Configuration  ---------------
Arrow keys navigate the menu. <Enter> selects submenus --->.
Highlighted letters are hotkeys. Pressing <Y> includes, <N>
excludes, <M> modularizes features. Press <Esc><Esc> to exit,
<?> for Help, </> for Search. Legent: [*] built-in, 
[ ] excluded, <M> module, < > excluded module

      General setup --->
  [*] Enable loadable module support --->
  -*- Enable the block layer --->
      Processor type and features --->
      Power management and ACPI options --->
      Bus options (PCI etc.) --->
      Executable file formats / Emulations --->
  [*] Networking support --->
      Device Drivers --->
      Firmware Drivers --->
      File systems --->
      Kernel hacking --->
      Security options --->
  -*- Cryptographic API --->
  [*] Virtualization --->
      Library routines --->
---
  Load an Alternate Configuration File
  Save an Alternate Configuratio File

  <Select>  <Exit>  <Help>

This tool doesn't do much more than edit a configuration file called /usr/src/linux/.config so it will not reconfigure your current kernel setup. As such, I recommend you to try it out. If you want to be absolutely sure that you don't mess anything up, you can make a backup of the current configuration file prior to starting the menuconfig:

# cp .config .config~

A new feature, available from Linux 2.6.32 onwards, is the make option localmodconfig (and a derivative called localyesconfig). These options are interesting if you are currently running a LiveCD or different distribution with a default distribution kernel (a fits-all kernel that uses kernel modules) as they will enable the drivers that are currently loaded (when you execute the commands) in the kernel configuration, giving a nice configuration to start from.

# make localmodconfig

The localmodconfig enables the drivers as kernel modules. The localyesconfig target enables the drivers as in-kernel selections (no modules).

You should understand that your current Linux kernel (the one you're booted with) is stored elsewhere in the system (probably in /boot) and that this kernel doesn't need to know its configuration file any more - it has been built using a particular configuration and will remain as-is.

Configuring your own kernel is most likely a trial-and-error process: you configure a new kernel, boot it, play around and if you're not satisfied (or it doesn't boot at all), just reboot with the old kernel (having several kernels next to each other is not a problem).

The menuconfig utility has an extensive help system built in. For instance, select "Enable loadable module support" and select <Help> (or press "?"):

------------   Enable loadable module support ----------
CONFIG_MODULES:

Kernel modules are small pieces of compiled code which can
be inserted in the running kernel, rather than being
permanently built into the kernel. You use the "modprobe"
tool to add (and sometimes remove) them. If you say Y here,
many parts of the kenel can be built as modules (by 
answering M instead of Y where indicated): this is most
useful for infrequently used options which are not required
for booting. For more information, see the man pages for
modprobe, lsmod, modinfo, insmod and rmmod.

If you say Y here, you will need to run "make
modules_install" to put the modules under /lib/modules/
where modprobe can find them (you may need to be root to do
this).

If unsure, say Y.

Symbol: MODULES [=y]
Prompt: Enable loadable module support
  Defined at init/Kconfig:607
  Location:
    -> Loadable module support

As you can see, the system gives information about the selected option as well as an indication whether or not you should select this ("If unsure, say Y.").

The system also has a search system. Press "/" and type in "initrd" to look for the configuration entry where you can enable initrd support inside the kernel:

------------   Search Results   ------------
Symbol: BLK_DEV_INITRD [=n]
Prompt: Initial RAM filesystem and RAM disk (initramfs/initrd) support
  Defined at init/Kconfig:326
  Depends on: BROKEN || !FRV
  Location:
    -> General setup

The search results give you a one-liner explanation of the found results as well as where you can find the option (here: in the "General setup" tab). It also shows you when the option is selectable (when the configuration BROKEN is set, or when FRV is not selected - FRV is an architecture, just as x86 and SPARC are - so for a non-FRV architecture it is always selectable).

In certain cases it can also tell you what new options it will allow once selected.

Recommended Linux Kernel Configurations

Although this might be a bit boring for some people, I'll discuss what I see as recommended Linux kernel configurations regardless of the hardware support you add on later...

General Setup

In "General Setup", miscellaneous configurations for the Linux kernel can be found.

[ ] Prompt for development and/or incomplete code/drivers
()  Local version - append to kernel release
[ ] Automatically append version information to the version string
    Kernel compression mode (Gzip) -->
[*] Support for paging of anonymous memory (swap)
[*] System V IPC
[ ] BSD Process Accounting
[ ] Auditing Support
    RCU Subsystem --->
<*> Kernel .config support
[*]   Enable access to .config through /proc/config.gz
(16) Kernel log buffer size (16 => 64KB, 17 => 128 KB)
[ ] Control Group support --->
[ ] enable deprecated sysfs features to support old userspace tools
[ ] Kernel->user space relay support (formerly relayfs)
-*- Namespaces support
[ ]   UTS namespace
[ ]   IPC namespace
[ ] Initial RAM filesystem and RAM disk (initramfs/initrd) support
[ ] Optimize for size
[ ] Configure standard kernel features (for small systems) --->
    Kernel Performance Events And Counters --->
[ ] Disable heap randomization
    Choose SLAB allocator (SLUB (Unqueued Allocator)) --->
[ ] Profiling support
[ ] Kprobes
    GCOV-based kernel profiling --->
[ ] Slow work debugging through debugfs

The following configurations are recommended to be enabled in this section:

  • Support for paging of anonymous memory (swap)

    You will need this enabled if you want to enable swap space on your system. You generally want this, unless you're confident that you have enough memory (RAM) in your system for every possible situation. Swap space is used when free memory is needed but not available. In that case, the Linux kernel will move out old pages of memory (which are most likely not going to be used in the near future) to the swap space.

  • System V IPC

    IPC (Inter Process Communication) allows programs to share and exchange information between them. Many programs on a Linux system will not start if System V IPC support isn't enabled in the kernel. System V IPC allows programs to use message queues, semaphores and shared memory segments.

  • RCU Subsystem

    RCU (Read Copy Update) is a synchronisation primitive supported by the Linux kernel which offers fast access to shared resources (programming-terms) in case of a many-read and infrequent write access behaviour. That might sound terribly geekish and programmer-specific - and it is - but if you have multiple cores or processors in your system, it is wise to enable it. Otherwise, set it to UP-kernel (UniProcessor).

        RCU Implementation (Tree-based hierarchical RCU) --->
    [ ] Enable tracing for RCU
    (32) Tree-based hierarchical RCU fanout value
    [ ] Disable tree-based hierarchical RCU auto-balancing
  • Kernel .config support

    Although definitely not mandatory for a kernel, building in .config support allows you to obtain the configuration for a running kernel from the kernel itself. This can come in handy if you don't keep track of the configurations you use(d) for kernels. You can, for instance, base a new kernel configuration on this configuration to get a good start.

    The subselection to support /proc/config.gz is an easy-to-use interface to the kernel configuration of a running kernel: extract /proc/config.gz (for instance, zcat /proc/config.gz > /usr/src/linux/.config and you have this kernel's configuration at hand.

You also notice that initramfs support is not enabled: I'm no proponent of initrd's, it is in my opinion better that a user configures his kernel to his system rather than hoping that an initrd will help with configuration failures.

Enable Loadable Module Support

I recommend enabling loadable module support if you use or will use detachable devices (such as USB devices).

--- Enable loadable module support
[ ]   Forced module loading
[*]   Module unloading
[ ]   Module versioning support
[ ]   Source checksum for all modules

The following settings are recommended:

  • Module unloading

    You will probably want to unload kernel modules if you don't need them any more.

Enable the Block Layer

I recommend enabling the block layer as you'll most likely want to use block devices or Linux kernel components that use functions from the block layer (such as SCSI or SCSI emulating devices, the ext3 file system or USB storage).

--- Enable the block layer
[ ]   Block layer SG support v4
[ ]   Block layer data integrity support
      IO Schedulers --->
------------   IO Schedulers   ------------
<*> Deadline I/O scheduler
<*> CFQ I/O scheduler
    Default I/O scheduler (CFQ) --->

The important setting here are the IO schedulers. These control how (and when) the Linux kernel writes or reads data to/from disks. There are different IO schedulers available because, depending on the system's use, a specific implementation can give a nice performance boost. The CFQ scheduler is a good implementation for desktop systems.

Processor Type and Features

The following settings are the recommended settings. However, these settings depend heavily on the system you have (as your CPU is most likely different from the one I use):

[*] Tickless System (Dynamic Ticks)
[*] High Resolution Timer Support
[*] Symmetric multi-processing support
[ ] Support sparse irq numbering
[ ] Enable MPS table
[ ] Support for extended (non-PC) x86 platforms
[*] Single-depth WCHAN output
[ ] Paravirtualized guest support
[*] Disable bootmem code
[ ] Memtest
    Processor family (Core 2/newer Xeon) --->
[ ] AMD IOMMU support
(8) Maximum number of CPUs
[*] SMT (Hyperthreading) scheduler support
[*] Multi-core scheduler support
    Preemption Model (Preemptible Kernel (Low-Latency Desktop)) --->
[ ] Reroute for broken boot IRQs
[*] Machine Check / overheating reporting
[*]   Intel MCE features
[ ]   AMD MCE features
< > Machine check injector support
< > Dell laptop support
[ ] Enable X86 board specific fixups for reboot
< > /dev/cpu/microcode - Intel IA32 CPU microcode support
< > /dev/cpu/*/msr - Model-specific register support
< > /dev/cpu/*/cpuid - CPU information support
[ ] Numa Memory Allocation and Scheduler Support
    Memory model (Sparse Memory) --->
[*] Sparse Memory virtual memmap
[ ] Allow for memory hot-add
[ ] Enable KSM for page merging
(65536) Low address space to protect from user allocation
[ ] Enable recovery from hardware memory errors
[ ] Check for low memory corruption
[ ] Reserve low 64K of RAM on AMI/Phoenix BIOSen
-*- MTRR (Memory Type Range Register)
[ ]   MTRR cleanup support
[ ] EFI runtime service support
[*] Enable seccomp to safely compute untrusted bytecode
    Timer frequency (1000 HZ) --->
[ ] kexec system call
[ ] kernel crash dumps
[ ] Build a relocatable kernel
-*- Support for hot-pluggable CPUs
[ ] Compat VDSO support
[ ] Built-in kernel command line

The following settings are recommended:

  • Tickless System (Dynamic Ticks)

    Unless you need the shortest latency possible, using dynamic ticks will ensure that timer interrupts only fire when needed.

  • High Resolution Timer Support

    Most relatively modern systems (Pentium III and higher) have high resolution timers, allowing for more precise timing. Not really mandatory, but some applications like mplayer can benefit from using hi-res timers.

  • Symmetric multi-processing support

    If you have multiple (identical) CPUs or your CPU has multiple cores, enable this.

  • Single-depth WCHAN output

    WCHAN is the abbreviation for "waiting channel" and identifies where tasks are currently waiting for. With this enabled, the calculation for the waiting channel is simplified at the expense of accuracy. Most users don't need this level of accuracy and the simplifications means less scheduling overhead.

  • Disable bootmem code

    This optimizes some complex initial memory allocation fragments within the Linux kernel.

  • Processor family (Pentium M)

    I have selected "Pentium M" here as this is my CPU type (see the /proc/cpuinfo information). You should select the processor family of your CPU here.

  • SMT (Hyperthreading) scheduler support

    This should be selected if you have a modern Pentium chip with hyperthreading support. It is not mandatory though (the kernel will run fine without it) but might improve scheduling decisions made by the kernel.

  • HPET Timer Support

    This enables support for the High Precision Event Timer, which can be seen as a time-source resource on somewhat more modern systems. Especially if you have more than 1 core/CPU, enabling this offers "cheaper" time access than without HPET Timer support.

  • Multi-core scheduler support

    Enable this if you have a CPU with multiple cores inside; it will improve the CPU scheduler performance.

  • Preemption Model (Preemptible Kernel (Low-Latency Desktop))

    Preemption means that a priority process, even when currently in kernel mode executing a system call, can yield his CPU time to another process. The user will notice this as if his system is running somewhat more 'smoothly' as applications might react faster to user input.

    There are three models available:

    • No Forced Preemption, or

    • Voluntary Kernel Preemption, where low-priority processes can voluntarily yield CPU time, or

    • Preemptible Kernel, where all processes can yield CPU time (as long as they're not in a critical kernel region at that moment)

  • Machine Check / overheating reporting

    MCE allows the processor to notify the kernel when problems are detected (like overheating); based on its severity, the Linux kernel can report the issue or take immediate action.

  • Intel MCE features

    This is part of the "Machine Check / overheating reporting" section, and enables Intel-specific MCE features. I enable this, as I have an Intel-based system.

  • Memory Model (Sparse Memory)

    If you have a 32-bit processor, selecting Flat Memory is what you need. CPUs with a larger address space support (like 64-bit CPUs) most likely only allow you to select "Sparse Memory" as you are not likely to have more than a few thousand terabytes of RAM ;-) When "Sparse Memory" is selected, "Sparse Memory virtual memmap" should be selected as well.

  • MTRR (Memory Type Range Register) support

    With MTRR support, applications such as the X server can control how the processor caches memory accesses, boosting performance for reads/writes to certain memory ranges.

  • Enable seccomp to safely compute untrusted bytecode

    As recommended by its help description, we enable this in case an application might want to use it. It has no impact if no such applications exist on your system, and if they do, you most likely want the added security measures this provides.

Power Management and ACPI Options

The power management options provide power-saving features for Linux, not only the APM / ACPI support, but also suspend-to-ram and standby support.

[*] Power Management support
[ ]   Power Management Debug Support
[*] Suspend to RAM and standby
[*] Hibernation (aka 'suspend to disk')
(/dev/sda5) Default resume partition
[ ] Run-time PM core functionality
[*] ACPI (Advanced Configuration and Power Interface) Support --->
[ ] SFI (Simple Firmware Interface) Support --->
    CPU Frequency Scaling --->
-*- CPU idle PM support
    Memory power savings --->

The following options are of particular interest:

  • Power Management Support

    Enable this to be able to select one or more of the other power management options.

  • Suspend to RAM and standby

    If you will have moments where you temporarily leave your system but don't want to shut it down and boot it back later, you can opt to have the system suspend itself into memory - in this case, many powerconsuming devices are shut down but you don't lose any information as everything remains in memory (and memory remains powered up).

  • Hibernation (aka 'suspend to disk')

    In hibernation, all devices shut down. The current state of your system (such as your memory content) is saved into your swap space. When you boot your system back, the Linux kernel will detect this in the swap space and load all information back into memory so you can continue where you left off.

    With suspend to disk enabled, set the default resume partition to your swap partition.

  • ACPI (Advanced Configuration and Power Interface) Support

    Within this section you can configure several aspects of the ACPI support. Enabling ACPI can be of great help to reduce power consumption as it is a powerful technology. Sadly, not every device follows the ACPI guidelines strictly. You will find topics on the internet where boot failures or network irregularities can be solved by disabling a part of the ACPI support inside Linux.

    --- ACPI (Advanced Configuration and Power Interface Support)
    [*]   Deprecated /proc/acpi files
    [*]   Deprecated power /proc/acpi directories
    < > ACPI 4.0 power meter
    [*]   Future power /sys interface
    [*]   Deprecated /proc/acpi/event support
    <*> AC Adapter
    <*> Battery
    <*> Button
    <*> Video
    <*> Fan
    <*> Processor
    <*>   Thermal Zone
    [ ] Debug Statements
    < > PCI slot detection driver
    < > Smart Battery System

    Within the ACPI configuration you should select the components for which you want support. On regular desktops, you most likely don't have a battery so support for that (and AC Adapters) won't be necessary.

    I select a few "deprecated" settings as I know the reporting tools I use (for battery status etc.) still rely on these files, directories and events to function correctly.

  • CPU Frequency Scaling

    If you own a laptop you'll most likely want to enable CPU Frequency scaling as it will slow down the CPU speed (and the power consumption with it) when the CPU isn't used.

    [*] CPU Frequency scaling
    [ ]   Enable CPUfreq debugging
    <*>   CPU frequency translation statistics
    [ ]      CPU frequency translation statistics details
          Default CPUFreq governor (performance) --->
    -*- 'performance' governor
    < > 'powersave' governor
    < > 'userspace' governor for userspace frequency scaling
    < > 'ondemand' cpufreq policy governor
    < > 'conservative' cpufreq governor
          *** CPUFreq processor drivers ***
    < >   Processor Clocking Control interface driver
    <*>   ACPI Processor P-States driver
    < >   AMD Opteron/Athlon64 PowerNow!
    < >   Intel Enhanced SpeedStep (deprecated)
    < >   Intel Pentium 4 clock modulation

    In the above, only the "performance" governor is selected, as the laptop will always be used as a workstation. However, you definitely want to enable additional governors for other purposes as well. A governor can be seen as a policy when and how the CPU frequency needs to be changed.

Bus options (PCI etc.)

A bus is a physical connection between several devices. The most popular bus technology within a computer nowadays is PCI (or PCI Express) but a few other bus technologies exist (for instance PCMCIA).

[*] PCI Support
[*]   Support mmconfig PCI config space access
      PCI access mode (Any) --->
[*] PCI Express support
[ ]   Root Port Advanced Error Reporting support
[ ] Message Signaled Interrupts (MSI and MSI-X)
[ ] PCI Debugging
< > PCI Stub driver
[ ] Interrupts on hypertransport devices
[ ] PCI IOV support
< > PCCard (PCMCIA/CardBus) support --->
< > Support for PCI Hotplug --->

In the above example I only selected PCI, mmconfig PCI config space access and PCI-X support; laptop users will most likely enable PCCard support as well. Within the submenu of the PCCard configuration you will be asked to select the supporting bridge. A bridge is a component that links one bus technology with another. A PCMCIA bridge allows PCMCIA devices to connect to your system. Most systems with PCMCIA support have a CardBus yenta-compatible bridge.

Although I own a laptop, I have no PC cards of any kind nor do I suspect I will need them quickly, so I leave out support for that.

Executable File Formats / Emulations

Within this section you can select what binaries (format for executable files with machine instructions inside) Linux should support.

[*] Kernel support for ELF binaries
[ ] Write ELF core dumps with partial segments
< > Kernel support for MISC binaries
[*] IA32 Emulation
< > IA32 a.out support

The binary format used by Linux is ELF. Very old Linux systems and a couple of BSD operating systems use a.out binaries but it isn't necessary to include support for those any more. If you are configuring for a 64-bit system, definitely enable IA32 Emulation. You'll need it. Trust me.

Networking

Inside the networking configuration tab you configure the various aspects related to your network.

[*] Networking support
      Networking options --->
[ ]   Amateur Radio support --->
< >   CAN bus subsystem support --->
< >   IrDA (infrared) subsystem support --->
< >   Bluetooth subsystem support --->
-*-   Wireless --->
< >   WiMAX Wireless Broadband support --->
< >   RF switch subsystem support --->

Within the 'Networking options', you will need to enable support for the networking technologies (not hardware) you want to support.

----- Networking Options -----
<*> Packet socket
<*> Unix domain sockets
< > PF_KEY sockets
[*] TCP/IP networking
[ ]   IP: multicasting
      ...
[ ] Security Marking
[*] Network packet filtering framework (Netfilter) --->
< > Asynchronous Transfer Mode (ATM)
< > 802.1d Ethernet Bridging
[ ] Distributed Switch Architecture support --->
< > 802.1Q VLAN Support
< > DECnet Support
< > ANSI/IEEE 802.2 LLC type 2 Support
< > The IPX protocol
< > Appletalk protocol support
< > Phonet protocols family
[ ] QoS and/or fair queuing --->
[ ] Data Center Bridging support
    Network testing --->

The most notable options here are:

  • Packet socket

    This allows programs to interface with the network devices immediately (without going through the network protocol implementation on the Linux kernel). It is required by tools such as tcpdump / wireshark (popular network analysing tools). You don't need to enable this, but I often perform network analysis myself so I need to have this enabled.

  • Unix domain sockets

    Sockets are a standard mechanism in Unix for processes to communicate with each other. This is an important setting that you must leave on.

  • TCP/IP networking

    Although you don't have to select any of the subfeatures that are shown when you enable this, TCP/IP networking support is definitely a must-have.

  • Network packet filtering framework (Netfilter)

    Enable this if you are planning on configuring a firewall on your system or have your system act as a gateway for others. Enable the 'IP tables support' found under 'IP: Netfilter Configuration' and select:

    <*> IPv4 connection tracking support (required for NAT)
    [*]   proc/sysctl compatibility with old connection tracking
    <*> IP tables support (required for filtering/masq/NAT)
    <*>   Packet filtering
    <*>      REJET target support
    <*>   LOG target support
    < >   ULOG target support
    <*>   Full NAT
    <*>     MASQUERADE target support
    <*>   Packet mangling

Users of a wireless network card will, under 'Networking', also select the Wireless configuration.

--- Wireless
<*>  cfg80211 - wireless configuration API
[ ]     nl80211 testmode command
[ ]     enable developer warnings
[ ]     cfg80211 regulatory debugging
[*]     enable powersave by default
[ ]     cfg80211 DebugFS entries
[ ]     cfg80211 wireless extensions compatibility
[*] Wireless extensions sysfs files
-+-  Common routines for IEEE802.11 drivers
[ ]   lib80211 debugging messages
< >  Generic IEEE 802.11 Networking Stack (mac80211)

I've selected these options because IEEE 802.11 is the standard for wireless networking:

  • cfg80211 - wireless configuration API

    You need to enable this if you have a wireless card

  • enable powersave by default

    Enables powersaving features of the wireless cards - definitely a must-have if you have wireless on a laptop as this reduces power consumption dramatically.

Device Drivers

Within this section you can configure support for the various devices in your system. It is with this configuration that the output of the lspci command (and other system information) is needed. The next example is merely that - an example. As this is very specific to your system, it is not possible to provide a general example that suits everybody. For completeness sake, I'll give the configuration for my own system with the motivation of the selection of each item.

    Generic Driver Options --->
< > Connector - unified userspace <-> kernelspace linker --->
< > Memory Technology Device (MTD) support --->
< > Parallel port support --->
-*- Plug and Play support --->
[*] Block devices --->
[ ] Misc devices --->
< > ATA/ATAPI/MFM/RLL support (DEPREACATED) --->
    SCSI device support --->
<*> Serial ATA and Parallel ATA drivers --->
[ ] Multiple devices driver support (RAID and LVM) --->
[ ] Fusion MPT device support --->
    IEEE 1394 (FireWire) support --->
< > I2O device support --->
[ ] Macintosh device drivers --->
[*] Network device support --->
[ ] ISDN support --->
< > Telephony support --->
    Input device support --->
    Character devices --->
{*} I2C support --->
[ ] SPI support --->
    PPS support --->
[ ] GPIO support --->
< > Dallas's 1-wire support --->
-*- Power supply class support --->
< > Hardware Monitoring support --->
-*- Generic Thermal sysfs driver --->
[ ] Watchdog Timer Support --->
    Sonics Silicon Backplane --->
    Multifunction device drivers --->
[ ] Voltage and Current Regulator Support --->
< > Multimedia support --->
    Graphics support --->
<*> Sound card support --->
[*] HID Devices --->
[*] USB support --->
<M> MMC/SD/SDIO card support --->
[ ] LED Support --->
[ ] Accessibility support --->
< > InfiniBand support --->
[ ] EDAC (Error Detection And Correction) reporting --->
< > Real Time Clock --->
[ ] DMA Engine support --->
[ ] Auxiliary Display support --->
< > Userspace I/O drivers --->
    TI VLYNQ --->
[ ] Staging drivers --->
[*] X86 Platform Specific Device Drivers --->

As you can see, most of the options are not selected and almost all of them provide subsections. This is of course expected, as device driver support is a huge part of the Linux source code, and the end user will only select a very small part of it.

Block devices

Block devices are devices where you can access data in blocks (as opposed to characters). Not all block devices are configurable through this menu (a well-known block device type, hard disk, is configured elsewhere) as you notice from the available configuration options:

--- Block devices
< >   Normal floppy disk support
< >   Compaq SMART2 support
< >   Compaq SMart Array 5xxx support
< >   Mylex DAC960/DAC1100 PCI RAID Controller support
<*>   Loopback device support
< >     Cryptoloop Support
< >   DRBD Distributed Replicated Block Device support
< >   Network block device support
< >   Promise SATA SX8 support
< >   Low Performance USB Block driver
< >   RAM block device support
< >   Packet writing on CD/DVD media
< >   ATA over Ethernet support
[ ]   Very old hard disk (MFM/RLL/IDE) driver
  • Loopback device support

    The only block device I enable is loopback support. This allows me to mount images (files) just like they were devices.

SCSI device support

Although my system doesn't have SCSI, it has Serial ATA (SATA) with disks attached to it. SATA support in Linux is brought through the SCSI subsystem, so I need to configure SCSI device support.

< > RAID Transport Class
-*- SCSI device support
< > SCSI target support
[ ] legacy /proc/scsi/ support
    *** SCSI support type (disk, tape, CD-ROM) ***
<*> SCSI disk support
< > SCSI tape support
< > SCSI OnStream SC-x0 tape support
< > SCSI CDROM support
< > SCSI generic support
< > SCSI media changer support
    *** Some SCSI devices (e.g. CD jukebox) support multiple LUNs ***
[ ] Probe all LUNs on each SCSI device
[ ] Verbose SCSI error reporting (kernel size +=12K)
[ ] SCSI logging facility
[ ] Asynchronous SCSI scanning
    SCSI Transports --->
[ ] SCSI low-level drivers --->
< > SCSI Device Handlers --->
< > OSD-Initiator library
  • SCSI disk support

    SCSI disk support is needed for the SATA disks.

Serial ATA and Parallel ATA drivers

Serial ATA support is needed to be able to access my disks.

--- Serial ATA and Parallel ATA drivers
[ ]   Verbose ATA error reporting
[*]   ATA ACPI Support
[ ]   SATA Port Multiplier support
<*>   AHCI SATA support
< >   Silicon Image 3124/3132 SATA support
[*]   ATA SFF support
< >     ServerWorks Frodo / Apple K2 SATA support
<*>     Intel ESB, ICH, PIIX3, PIIX4 PATA/SATA support
< >     Marvell SATA support
      ...
  • ATA ACPI Support

    Enables retrieving ACPI related files (performance, security, power management ...) from the ACPI BIOS and save them on the disk controller.

  • Intel ESB, ICH, PIIX3, PIIX4 PATA/SATA support

    The only selection made in this configuration is the support for my SATA chip set of which lspci told me it was an Intel ICH6 chip set:

    # lspci | grep SATA
    00:1f.2 SATA controller: Intel Corporation 82801FBM (ICH6M)
            SATA Controller (rev 04)

    All the other options are drivers for other chip sets.

Network device support

Inside network device support we configure the drivers for the networkcards.

--- Network device support
<*>   Dummy net driver support
< >   Bonding driver support
< >   EQL (serial line load balancing) support
< >   Universal TUN/TAP device driver support
< >   Virtual ethernet pair device
< >   General Instruments Surfboard 1000
< >   ARCnet support --->
[ ]   Ethernet (10 or 100Mbit) --->
[*]   Ethernet (1000 Mbit) --->
[ ]   Ethernet (10000 Mbit) --->
[ ]   Token Ring driver support --->
[*]   Wireless LAN --->
      USB Network Adapters --->
[ ]   Wan interfaces support --->
< >   FDDI driver support
< >   PPP (point-to-point protocol) support
< >   SLIP (serial line) support
[ ]   Fibre Channel driver support
< >   VMWare VMXNET3 ethernet driver
  • Dummy net driver support

    This driver allows me to create an interface which takes on all packets and just ignores them. This seems to be a weird driver, but it can come in handy from time to time. Also, this has no impact on my kernel size so I don't mind enabling this for the few times I actually use it.

  • Ethernet (1000 Mbit)

    I have a Realtek 8169 ethernet card (which is a 1Gbit network card) as mentioned by lspci:

    # lspci | grep Ethernet
    06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
            RTL-8169 Gigabit Ethernet (rev 10)

    As such I select the 'Realtek 8169 gigabit ethernet support' option in the configuration screen.

  • Wireless LAN

    As my system is a laptop with onboard wireless network card, I need to enable WLAN support as well.

    --- Wireless LAN
    < >   Cisco/Airnet 34X/35X/4500/4800 ISA and PCI cards
    ...
    <M>   Intel PRO/Wireless 2200BG and 2915ABG Network Connection
    [*]     Enable promiscuous mode
    -*-       Enable radiotap format 802.11 raw packet support
    [*]       Enable creation of a RF radiotap promiscuous interface
    [ ]     Enable QoS support
    ...
    • Wireless LAN (IEEE 802.11)

      The network card I have is an 802.11-something so I need to enable this.

    • Intel PRO/Wireless 2200BG and 2915ABG Network Connection

      lspci says that my wireless card is an Intel PRO/Wireless 2200BG one, so I need to enable support for it:

      # lspci | grep Wireless
      06:04.0 Network controller: Intel Corporation PRO/Wireless
              2200BG Network Connection (rev 05)
    • Enable promiscuous mode

      I need promiscuous mode when I want to analyse the wireless network I work on.

Input device support

Input devices are the devices you know to interact with your system, such as a keyboard and a mouse.

-*- Generic input layer (needed for keyboard, mouse, ...)
< >   Support for memoryless force-feedback devices
< >   Polled input device skeleton
< >   Sparse keymap support library
      *** Userland interfaces ***
-*-   Mouse interface
[*]     Provide legacy /dev/psaux device
(1024)  Horizontal screen resolution
(768)   Vertical screen resolution
< >   Joystick interface
<*>   Event interface
< >   Event debugging
      ** Input Device Drivers ***
-*-   Keyboards --->
[*]   Mice --->
[ ]   Joysticks/Gamepads --->
[ ]   Tables --->
[ ]   Touchscreens --->
[ ]   Miscellaneous devices --->
    Hardware I/O ports --->
  • Generic input layer (needed for keyboard, mouse, ...)

    As the title says already, I need this for keyboard/mouse support

  • Mouse interface

    Enable mouse support

  • Horizontal screen resolution / Vertical screen resolution

    Actually, this setting is ignored as it is only really used if your pointing device is a digitizer or tablet rather than a simple mouse.

  • Event interface

    This enables evdev support, which is somewhat mandatory if you want to work with graphical interfaces (for instance, the xorg configuration requires this).

  • Keyboards

    Keyboard support is automatically selected, but in the subconfiguration you don't need to select anything unless you have a very special keyboard.

  • Mice

    Within the mouse configuration, I enable 'PS/2 mouse' as my mouse is a PS/2 one.

  • Hardware I/O ports

    Inside this configuration section, 'Serial I/O support' should be automatically selected as it is used by the keyboard/mice support.

Character devices

Character devices are devices that are accessed character per character. An example of a character device is a terminal.

-*- Virtual terminal
[ ]   Support for binding and unbinding console drivers
[ ] /dev/kmem virtual device support
[ ] Non-standard serial port support
< > HSDPA Broadband Wireless Data Card - Globe Trotter
    Serial drivers --->
-*- Unix98 PTY support
[ ]   Support multiple instances of devpts
[*] Legacy (BSD) PTY support
(256) Maximum number of legacy PTY in use
< > IPMI top-level message handler --->
<*> Hardware Random Number Generator Core support
< >   Timer IOMEM HW Random Number Generator support
<*>   Intel HW Random Number Generator support
< >   AMD HW Random Number Generator support
< >   AMD Geode HW Random Number Generator support
< >   VIA HW Random Number Generator support
< > /dev/nvram support
< > Enhanced Real Time Clock Support (Legacy PC RTC driver)
< > Generic /dev/rtc emulation
< > Siemens R3964 line discipline
< > Applicom intelligent fieldbus card support
< > ACP Modem (Mwave) support
< > NatSemi PC8736x GPIO Support
< > NatSemi Base GPIO Support
< > AMD CS5535/CS5536 GPIO (Geode Companion Device)
< > RAW driver (/dev/raw/rawN)
[ ] HPET - High Precision Event Timer
< > Hangcheck timer
< > TPM Hardware Support --->
< > Telecom clock driver for ATCA SBC
  • Virtual terminal

    Support for virtual terminals is automatically selected. You need it as you'll work with virtual consoles all the time in Linux: if you're opening a terminal window, you're working in a virtual console.

  • Unix98 PTY Support

    This should be automatically selected; it is the support for virtual PTYs which you definitely need.

  • Legacy (BSD) PTY support

    Enables support for virtual PTYs, but then a different kind. Although not selecting this option won't break your kernel, you'll most likely get a few (cosmetic) errors every time you open a terminal. So better enable this.

  • Hardware Random Number Generator Core support

    To have support for the hardware random number generator, select this and the specific generator in the next list.

  • Intel HW Random Number Generator support

    My generator provider is an Intel one (as my CPU is an Intel CPU).

Graphics support

Graphical card support is configured here as well as framebuffer support (allowing applications to access the graphics hardware through a well-defined interface).

<*> /dev/agpgart (AGP Support) --->
-*- VGA Arbitration
(2)   Maximum number of GPUs
[ ] Laptop Hybrid Graphics - GPU switching support
<M> Direct Rendering Manager (XFree86 4.1.0 and higher DRI support) --->
{M} Lowlevel video output switch controls
{*} Support for frame buffer devices --->
< > CyberPro 2000/2010/5000 support
< > Arc Monochrome LCD board support
[ ] Asiliant (Chips) 6900 display support
[ ] IMS Twin Turbo display support
< > VGA 16-color graphics support
[*] VESA VGA graphics support
< > N411 Apollo/Hecuba devkit support
< > Hercules mono graphics support
...
[ ] Backlight & LCD device support --->
    Display device support --->
    Console display driver support --->
[ ] Bootup logo --->
  • /dev/agpgart (AGP Support)

    I know my laptop has an on-board AGP card. lspci tells me what card it is:

    # lspci | grep VGA
    00:02.0 VGA compatible controller: Intel Corporation Mobile
            915GM/GMS/910GML Express Graphics Controller (rev 03)

    As such, I also enable 'Intel 440LX/BX/GX, I8xx and E7x05 chip set support'. You might believe that I am in error because the title doesn't mention 915GM (as shown in lspci's output) but if I read the help for the option, I read that I915 is supported through this driver as well.

  • Direct Rendering Manager (XFree86 4.1.0 and higer DRI support)

    DRM is needed by XFree86 to improve graphic performance (including 3D support). Within the subconfiguration, I enable drivers for my Intel graphical card:

    --- Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)
    < >   3dfx Banshee/Voodoo3+
          ...
    <M>   Intel 830M, 845G, 852GM, 855GM, 865G
    < >     i830 driver
    <M>     i915 driver
    < >   Matrox g200/g400
          ...
  • Support for frame buffer devices

    I want frame buffer support because that allows me to display more characters than just 80x25 when working in the command-line mode (console). In the subconfiguration, I enable 'VESA VGA graphics support' which enables standard VESA support for framebuffer access.

  • Console display driver support

    Within the console display driver support, I enable framebuffer support for the console:

    -*- VGA test console
    [ ]   Enable Scrollback Buffer in System RAM
    {*} Framebuffer Console support
    [ ]   Map the console to the primary display device
    [ ]   Framebuffer Console Rotation
    [ ] Select compiled-in fonts
Sound

To support my sound card, I enable sound card support and the sound system I want to use.

<*> Sound card support
[ ]   Preclaim OSS device numbers
<*>   Advanced Linux Sound Architecture --->
< >   Open Sound System (DEPRECATED) --->

ALSA (Advanced Linux Sound Architecture) is the latest sound system supported by Linux. OSS is deprecated and ALSA provides OSS compatibility for those applications that still require OSS.

<*> Advanced Linux Sound Architecture
<*>   Sequencer support
< >     Sequencer dummy client
< >   OSS Mixer API
< >   OSS PCM (digital audio) API
[ ]   OSS Sequencer API
[ ]   Dynamic device file minor numbers
[ ]   Support old ALSA API
[ ]   Verbose procfs contents
[ ]   Verbose printk
[ ]   Debug
[ ]   Generic sound devices --->
[*]   PCI sound devices --->
[ ]   USB devices --->
< >   ALSA for SoC audio support --->
  • PCI sound devices

    Under the PCI devices, select the audio card you have. Again, lspci can show you what device you have:

    # lspci | grep Audio
    00:1e.2 Multimedia audio controller: Intel Corporation
            82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio
            Controller (rev 04)

    With this information, I know that I need to select 'Intel/SiS/nVidia/AMD/ALi AC97 Controller'.

HID Devices

A HID device (Human Interface Device) is a device that takes input from the user. An important class of devices that use the HID interface are USB keyboards and mice.

--- HID Devices
-*-   Generic HID support
[ ]     /dev/hidraw raw HID device support
      *** USB Input Devices ***
<*>   USB Human Interface Device (full HID) support
[ ]   PID device support
[ ]   /dev/hiddev raw HID device support
      Special HID drivers --->
  • USB Human Interface Device (full HID) support

    I select this as I often use a USB mouse on my laptop.

USB support

USB devices come in various types and classes; the USB support screen is therefore quite a large device driver configuration screen with many options.

--- USB support
<*> Support for Host-side USB
[ ]   USB verbose debug messages
[ ]   USB announce new devices
      *** Miscellaneous USB options ***
[ ]   USB device filesystem (DEPRECATED)
[ ]   USB device class-devices (DEPRECATED)
...
      *** USB Host Controller Drivers ***
< >   Cypress C67x00 HCD support
<*>   EHCI HCD (USB 2.0) support
< >   ISP116X HCD support
<*>   OHCI HCD support
<*>   UHCI HCD (most Intel and VIA) support
< >   SL811HS HCD support
< >   R8A66597 HCD support
      *** USB Device Class drivers ***
< >   USB Modem (CDC ACM) support
<*>   USB Printer support
    *** NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
    *** may also be needed; see USB_STORAGE Help for more information
<*> USB Mass Storage support
< >   USB Mass Storage verbose debug
      ...
[ ] The shared table of common (or usual) storage devices
    *** USB Imaging devices ***
< > Microtek X6USB scanner support
[ ] USB Monitor
    *** USB port drivers ***
< > USB Serial Converter support --->
    *** USB Miscellaneous drivers ***
< > EMI 6|2m USB Audio interface support
    ...
  • Support for Host-side USB

    This enables general USB support (technology-wise)

  • USB device filesystem

    With this enabled, the Linux kernel will create information files inside /proc/bus/usb about each device. This information can come in handy to debug USB device support but is also used by tools to provide more information about a USB device.

  • EHCI HCD (USB 2.0) support

    There are a few standards for USB controllers. For USB 2.0 support, you need to enable EHCI HCD support.

  • UHCI HCD (most Intel and VIA) support

    UHCI is Intels' interface for USB 1.0 and 1.1 support.

  • USB Printer support

    As I do want to print occasionally, I need to enable USB printer support (as my printer is a USB printer).

  • USB Mass Storage support

    USB Mass Storage support is needed to be able to access USB sticks, USB disks and other USB media that I want to be able to access as a remote disk. This includes most digital cameras.

MMC/SD card support

My laptop supports MMC/SD cards so I want to support this in my kernel as well.

[ ] MMC debugging
[ ] Assume MMC/SD cards are non-removable (DANGEROUS)
    *** MMC/SD Card Drivers ***
<M> MMC block device driver
[*]   Use bounce buffer for simple hosts
< > SDIO UART/GPS class support
< > MMC host test driver
    *** MMC/SD HOst Controller Drivers ***
<M> Secure Digital Host Controller Interface support
<M> SDHCI support on PCI bus
< > Winbond W83L51xD SD/MMC Card Interface
< > ENE CB710 MMC/SD Interface support
< > VIA SD/MMC Card Reader Driver
  • MMC block device driver

    This driver enables the Linux kernel to mount an MMC/SD card as a file system.

  • Use bounce buffer for simple hosts

    The Linux kernel help system has informed me that this helps performance on certain controllers. Although I don't know if I really need this, I've enabled this as I was unsure, and the help says I need to say 'Y' if I am unsure.

  • Secure Digital Host Controller Interface support

    Inside the help of this option it says that this enables SD controller support for controllers manufactured by Texas Instruments, Ricoh and Toshiba. lspci informs me that I have a Texas Instruments device, so I enable this:

    # lspci | grep SD
    06:09.4 SD Host controller: Texas Instruments
            PCI6411/6421/6611/6621/7411/7421/7611/7621 Secure
            Digital Controller
File Systems

Our next stop is file system support. A file system is the formatting structure used on a (disk)partition as we mentioned before. It is important here that you build support for the file systems in the kernel (and not as a module) as you could otherwise end up with a kernel that needs file system support to mount the file system... where your kernel modules are installed.

<*> Second extended fs support
[ ]   Ext2 extended attributes
[ ]   Ext2 execute in place support
<*> Ext3 journalling file system support
[ ]   Default to 'data=ordered' in ext3
[ ]   Ext3 extended attributes
< > The Extended 4 (ext4) filesystem
[ ] JDB (ext3) debugging support
< > Reiserfs support
< > JFS filesystem support
< > XFS filesystem support
< > OCFS2 file system support
[*] Dnotify support
[*] Inotify file change notification support
[*]   Inotify support for userspace
[ ] Quota support
< > Kernel automounter support
< > Kernel automounter version 4 support (also supports v3)
< > FUSE (Filesystem in Userspace) support
    Caches --->
    CD-ROM/DVD Filesystems --->
    DOS/FAT/NT Filesystems --->
    Pseudo filesystems --->
[ ] Miscellaneous filesystems --->
[*] Network File Systems --->
    Partition Types --->
-*- Native language support --->
< > Distributed Lock Manager (DLM) --->
  • Second extended fs support

    My /boot partition uses the ext2 file system...

  • Ext3 journalling file system support

    ... and all other partitions I have use the ext3 file system

  • Dnotify support

    Some applications might need Dnotify support (a notification system where the kernel sends a signal to a userspace application to notify it about file changes).

  • 'Inotify file change notification support' and 'Inotify support for userspace'

    Inotify is a better implementation of a file notification system than Dnotify and is used by various applications.

  • CD-ROM/DVD Filesystems

    Within this subsection, enable 'ISO 9660 CDROM file system support' as well as 'Microsoft Joliet CDROM extensions' (to support the larger file name scheme used by Microsoft).

  • DOS/FAT/NT Filesystems

    If you are never going to work on FAT/NTFS file systems, you don't need this, but I occasionally attach a FAT/NTFS formatted disk on my laptop to help people.

    <*> MSDOS fs support
    <*> VFAT (Windows-95) fs support
    (437) Default codepage for FAT
    (iso8859-15) Default iocharset for FAT
    <*> NTFS file system support
    [ ]   NTFS debugging support
    [ ]   NTFS write support

    You notice that I don't enable NTFS write support. This is because the in-kernel NTFS write support is very limited (thank you Microsoft for hiding how NTFS works).

  • Pseudo filesystems

    Pseudo file systems are virtual file systems where the kernel maps information onto virtual files which you can read or write.

    -*- /proc file system support
    [*]   /proc/kcore support
    [*] Virtual memory file system support (former shm fs)
    [ ]   Tmpfs POSIX Access Control Lists
    [ ] HugeTLB file system support
    < > Userspace-driven configuration filesystem

    Apart from the /proc file system support, I also enable 'Virtual memory file system support' (also known as tmpfs) which allows you to map a portion of your virtual memory as a file system (every file you create inside a tmpfs file system is stored in memory or swap space; when unmounted, the files are lost).

    Tmpfs is often used for the /tmp location.

  • Network File Systems

    Network file systems allow you to access files on remote sites as if they were local (rather than using tools / technologies like FTP to store or retrieve them).

    <*> NFS file system support
    [*]   Provide NFSv3 client support
    [ ]     Provide client support for the NFSv3 ACL protocol extension
    [ ]   Allow direct I/O on NFS files
    <*> NFS server support
    [ ]   Provide NFSv3 server support
    [*]   Provide NFS server over TCP support
    < > SMB file system support (OBSOLETE, please use CIFS)
    <*> CIFS support (advanced network filesystem, SMBFS successor)
    [ ]   CIFS statistics
    [ ]   Support legacy servers which use weaker LANMAN security
    [ ]   CIFS extended attributes
    [ ]   Enable additional CIFS debugging routines
    < > NCP file system support (to mount NetWare volumes)
    < > Code file system support (advanced network fs)
    • NFS file system support

      I use NFS to share Gentoo's portage tree with other systems (and even virtual machines) so I need to enable NFS support

    • Provide NFSv3 client support

      With this I can act as an NFS client (to mount remote NFS shares)

    • NFS server support

      With this I can act as an NFS server (to provide remote NFS shares)

    • Provide NFS server over TCP support

      Enable NFS servers with TCP support; the Linux kernel help system tells me that this is interesting when the network is lossy or congested. As I'm using a wireless network, this seems to be a good choice.

    • CIFS support

      CIFS enables support for mounting SAMBA shares as well as Windows shares (and authenticate my own system on a Windows network).

Cryptographic API

Some kernel subsystems require in-kernel cryptographic algorithm support. The algorithms that are needed will be automatically selected, so you don't have to configure anything here.

Building a Linux Kernel

Once your kernel configuration is finished, save the configuration (select 'Exit' and confirm that you want to save the new kernel configuration). Next, build the main kernel and the modules by entering the make command.

$ make

The make command reads in a specific configuration file (the Makefile) which contains the instructions for building the Linux kernel completely. This can take a while; when finished, the kernel image will be stored in (for x86 architecture) arch/i386/boot and is called bzImage.

By default, the make command will launch the build instructions one at a time. However, most systems have multiple cores (or even CPUs) at their disposal, so it makes sense to - when possible - run multiple instructions next to each other. This can be accomplished using the -j# command (where '#' is the number of parallel build instructions).

A common value is the number of cores available on the system, so for a 4-core single-processor system:

$ make -j4

Next, you need to install the kernel modules (if any) on your system. Type in make modules_install to have the make command automatically copy the kernel modules to the correct location (/lib/modules/kernelversion):

# make modules_install

Finally, copy over the kernel image to the /boot location. If /boot is a separate partition (as it is on my system) which isn't automatically mounted, mount it first:

# mount /boot
# cp /usr/src/linux/arch/x86/boot/bzImage /boot/kernel-3.10.7

You can also use make install right after (or before) the make modules_install step. This will copy the kernel to /boot, calling it /boot/vmlinuz, copying the previous kernel to /boot/vmlinuz.old. If you rather have it not overwrite kernels, you can also first create a symbolic link /boot/vmlinuz pointing to the correct kernel (say /boot/vmlinuz-3.8.5). A make install will then save the new kernel (as a new file) and update the link instead, keeping the old kernel image available for future use. I actually recommend to either manually copy the kernel, or use the symbolic link approach.

To safely support make install, do the following steps only once:

# cp /usr/src/linux/arch/x86/boot/bzImage /boot/vmlinuz-3.10.7
# cd /boot
# ln -s vmlinuz-3.10.7-r2 vmlinuz

Rebuilding a Kernel

Suppose that you have successfully built a kernel and are happily working with it. At some point in time, you'll need to upgrade your kernel. Luckily, there is no reason to perform the above steps over and over again.

Go to the source location of your new kernel sources (most likely, still /usr/src/linux) and get your current kernel configuration. If you've followed the above configuration directives, you'll have access to these settings in /proc/config.gz:

# cd /usr/src/linux
# zcat /proc/config.gz > .config

The zcat command will "load" your current kernel configuration into the .config file, which is the file used by the kernel building process to find the (new) configuration settings. Next, tell the kernel build tool to use this configuration as if it is your old(er) configuration. This will result in the build process to only ask for validation when new configuration items are found (in the new sources) that weren't available previously.

# make oldconfig

When this is finished, continue with the make (or make -j# with # the number of parallel build instructions allowed) and make modules_install commands, finishing off with the mount and copy commands to install the new kernel at the /boot location.

Initial ram file systems

I have touched the concept of initrd and initramfs already in the earlier sections. Its purpose is clear: to offer the booting system the necessary tools, files, libraries and modules so that the boot process can be continued on a fully prepared (and all hardware properly detected) system.

Although initrd might still be in use, most distributions nowadays suggest the use of initramfs. Whereas an initrd is a full device (for which you pass on an image), an initramfs is an archive that is extracted on an tmpfs file system. This offers more flexibility and less resource consumption within the kernel.

To generate an initial ram file system, I recommend that you use the genkernel application (even if you configured and build your kernel manually). Its usage is quite simple:

# genkernel --install --lvm initramfs

When genkernel has built its initial ram file system archive, you will find it in the /boot location, cleverly named starting with initramfs-.

Configuring the Boot Loader

Before you can use the new kernel, you need to edit your boot loader configuration to use the new kernel. The bootloader I recommend is GRUB, the GRand Unified Bootloader, but others exist (especially for non-x86 compatible architectures which might need different boot loaders). In this section, I'll focus on GRUB2 (the previous GRUB, nowadays called GRUB Legacy, is no longer maintained).

Installing GRUB

Before you can start using GRUB, you need to install GRUB onto your MBR, or Master Boot Record. That is a special location on your disk (the first 512 bytes of a disk) which is loaded by the BIOS and executed (if it contains executable material).

By installing GRUB into the MBR, GRUB is automatically started after the BIOS POST processing (Power On Self Test).

First of all, you need to install GRUB:

# emerge grub:2

Next, we install GRUB onto the MBR:

# grub-install /dev/sda

If the disk is not configured with sufficient space after the MBR but before the first partition, you will need to force the installation. GRUB will use a special support mode in that case:

# grub-install -f /dev/sda

Configuring GRUB

Unlike GRUB Legacy, GRUB is configured through variables in /etc/default/grub, which are used to auto-generate the configuration file.

# nano -w /etc/default/grub

The variable that, if you need to set anything, is the most likely candidate, is GRUB_CMDLINE_LINUX. This variable content is added to the kernel line and is used to pass on additional kernel parameters. For instance, to pass on the parameter "dolvm" (to support a logical volume as root file system, needed for some init scripts):

GRUB_CMDLINE_LINUX="dolvm"

In most cases though, you will not need to set anything. For instance the root file system, which needed to be set individually in the past, is automatically detected by the GRUB2 configuration command.

So, let's generate the configuration file:

Important

Make sure that the output of the command shows that linux (and perhaps initrd) images are detected. If none are detected, then GRUB will not be able to boot the system as it has not found a Linux kernel to boot with.

# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-3.10.7
Found initrd image: /boot/initramfs-genkernel-x86_64-3.10.7
done

That's it - GRUB is now installed and configured.

Troubleshooting Boot Failures

One of the worst issues you can face is an unbootable system. Yes, it is bad, because without being able to boot, how can you fix the system (or debug / troubleshoot)? Before continuing with the most frequent boot failures (and how to deal with them), first a quick look at how to generally act when a system fails to boot...

When a system fails to boot...

A boot failure can either be due to:

  • kernel configuration issue, or

  • system configuration issue, or

  • hardware malfunction

It's pretty easy to guess which one is the hardest to detect but easiest to resolve (hint: it's the hardware malfunction one). The other ones, well, they require a bit preparation in order to easily troubleshoot and, eventually, solve.

Kernel Parameters

GRUB allows you to boot a kernel / system with a modified set of parameters for a single time (i.e. the changes are not persisted). This allows you to (re)boot a kernel with additional parameters.

  1. When you are at the GRUB screen, highlight the entry you want to boot, and press e (for edit).

  2. Highlight the line starting with "kernel", and press e again.

  3. Edit the line accordingly (a kernel parameter is often a word or key=value set appended to the line), and press Enter to save the changes (remember, it is just for this single boot)

  4. Press b (for boot) to boot the kernel.

You will find that several of the kernel boot failures can be helped with one or more kernel parameters being added.

Rescue Live Linux Environment

If a system fails to boot due to a system configuration issue, I recommend to boot from a rescue environment (SysRescCD comes to mind). Since USB sticks are widely spread and easy to work with, I suggest that you configure your system to be able to boot from USB and test it. It is faster than booting from most CD/DVD drives (sorry, I still don't have a Blu-Ray drive at the time of writing) and a rescue USB stick is easier to carry with you.

Having a rescue live Linux environment around you is really worth it. Configuration failures are easily made, and can have serious consequences. Gentoo Linux doesn't have a roll-back scenario (yet) that allows you to boot with previous settings.

Kernel Boot Failures

Kernel boot failures can have multiple causes, but usually the output on the screen allows you to identify the issue rapidly.

ACPI Issues

ACPI is a common source of boot failures. It isn't that the (ACPI) standard is bad, or that Linux drivers often implement it wrongly. Rather, some hardware is known not to follow the ACPI standard to the letter, making it difficult to write drivers that comply to the ACPI standard with this hardware.

Issues with ACPI support are often seen through kernel oops messages (which is a dump to the screen offering information for kernel developers regarding the problem) that point to acpi_* functions:

[     0.873537]  [<ffffffff8134ecba>] ? acpi_video_register+0x3f/0x71
[     0.873596]  [<ffffffff8100c36a>] ? do_one_initcall+0x34/0x1a0
[     0.873656]  [<ffffffff8175147d>] ? kernel_init+0x164/0x1be
[     0.876714]  [<ffffffff8100c36a>] ? child_rip+0xa/0x20
[     0.876773]  [<ffffffff81751319>] ? kernel_init+0x0/0x1be
[     0.876832]  [<ffffffff8100c360>] ? child_rip+0x0/0x20

Whenever you suspect that ACPI is the source of your issue, boot the same kernel, but with the noacpi parameter.

Unable to mount root-fs

Most likely one of the most occurring issue (but once you solved it, you most likely are never going to see it again):

Unable to mount root fs on unknown-block(0,0)

or

VFS: Cannot open root device "sda3" or unknown-block(8,3)
Please append a correct "root=" boot option; here are the available partitions:
  sda driver: sd
    sda1 sda2

The digits "0,0" or "8,3" can be different in your case - it refers to the device that the kernel tries to access (and which fails). Generally speaking one can say that, if the first digit is 0, then the kernel is unable to identify the hardware. If it is another digit (like 8), it is unable to identify the file system (but is able to access the hardware).

The problem here is that the kernel that you are booting cannot translate the "root=/dev/..." parameter you gave it (inside the boot loader configuration) into a real, accessible file system. Several reasons can result in such a failure:

  • the kernel configuration is missing drivers for your HDD controller (cases 1, 4, 5)

  • the kernel configuration is missing drivers for the bus used by your HDD controller

  • the kernel configuration is missing drivers for the file system you are using

  • the device is misidentified in your root= parameter (cases 2, 3)

Resolving the issue is easy if you know what the reason is. You most likely don't, so here's a quick check-up.

Open the kernel configuration wizard (the make menuconfig part) so that you can update the kernel configuration accordingly.

  • Check if you have built in (and not as a module) support for the bus / protocol that your harddisk controller uses.

    Most likely this is PCI support, SATA support (which is beneath SCSI device support), ...

  • Check if you have built in (and not as a module) support for the HDD controller you use.

    One of the most frequent cases: you selected support for your harddisk controller protocol (IDE, SATA, SCSI, ...) but forgot to select the HDD controller driver itself (like Intel PIIX). Try running the following lscpi command, and paste its output on http://kmuto.jp/debian/hcl/. The site will show you which kernel drivers you need to select for your system. Within the menuconfig, you can type "/" to open the search function, and type in the driver name to find out where it resides.

    # lspci -n
  • Check if you have built in (and not as a module) support for the file system(s) you use.

    Say your root file system uses btrfs (which I definitely don't recommend) but you didn't select it, or selected it to be built as a module, then you'll get the error you see. Make sure the file system support is built in the kernel.

  • Check if the kernel parameter for root= is pointing to the correct partition.

    This isn't as stupid as it sounds. When you are booted with one kernel, it might list your partition as being /dev/hda whereas your (configured) kernel is expecting it to be /dev/sda. This is not because kernels are inconsistent with each other, but because of the drivers used: older drivers use the hda syntax, newer sda.

    Try switching hda with sda (and hdb with sdb, and ...).

    Also, recent kernels give an overview of the partitions they found on the device told. If it does, it might help you identify if you misselected a partition (in the example given at the beginning of this section, only two partitions are found whereas the kernel was instructed to boot the third). If it doesn't, it is most likely because the kernel doesn't know the device to begin with (so it can't attempt to display partitions).

  • Check if the kernel that is being boot by the boot loader is the correct kernel.

    I have seen people who, after building a first kernel (which doesn't boot), forget that they have to mount /boot before the overwrite the kernel with a new one. As a result, they copy the kernel to the root file system (/) whereas the boot loader still expects the kernel image to be on the /boot partition.

System Boot Failures

The following set of subsections explain various failures you might get in contact with. These failures are less (or not) related with the kernel build process, but since they occur at boot-time (and due to lack of a better location in this book) I've included them in this chapter...

X (graphical environment) comes up, but keyboard or mouse doesn't work

You might have this issue when you have just upgraded your graphical environment or HAL process. By itself not a very easy thing to debug, but you'll need to get access to your system, and rebooting doesn't help (as you'll get into the same situation anyhow).

Luckily, you can ask Gentoo to boot the system without starting the graphical environment (leaving you with the command-line login from which you can fix things). Reboot until you get into the GRUB menu. Then press e(dit) on the boot item, e(dit) again on the kernel line, and add "nox" at the end of the line. This option will inform Gentoo not to load X.

Now that you are booted without the graphical environment, you can fix your system.

One reason this might happen is that X has been upgraded but you need to rebuild the various xf86-input-* packages. To get the list of installed xf86-input-* packages, you can use qlist:

# qlist -I xf86-input
x11-drivers/xf86-input-evdev
x11-drivers/xf86-input-keyboard
x11-drivers/xf86-input-mouse
x11-drivers/xf86-input-synaptics

You can reinstall those packages using the following command:

# emerge -1 `qlist -CI xf86-input`

Mind the use of the ` character at both beginning and ending of the qlist stanza.

Exercises

  1. How is it possible that one bootloader is able to boot an operating system through a different bootloader?



[1] There is another command called insmod - this tool is less intelligent than modprobe: it only attempts to load a kernel module given its file name and it doesn't try to load the prerequirement modules (modules can prerequire other modules).