KERNEL CONFIGURATION GUIDE

Configuring the Linux kernel is arguably the hardest step in the installation process. The kernel is humongous and figuring out what to enable in the seemingly endless option list can be a daunting task.

The most important factor for success is how well one knows their hardware. Spend a little time doing some research prior to configuring the kernel. Knowing what is inside one's system is of immense value in all contexts.

The physical realm however, is only part of the equation. Configuration extends to general features, file-systems, networking protocols, cryptography, security, processor features and more.

This Wiki page will document kernel options, their requirement level (conditional, recommended or mandatory), a brief description and a rationale if necessary. Information about pre-built hardware as a whole will not be covered.

[0.0] Index

[1.0] Getting a config

The first step in this process is creating a .config file in the Linux source tree. It is essentially just a text file containing KEY=value pairs (along with comments), each of which control something in the linux build process.

An important subset of the options control "drivers"; sections of code that give the kernel the capability to interact with filesystems, protocols and hardware components. These options typically have three possible values: "n" to not compile the driver, "y" to compile it into the kernel binary and "m" to compile the driver as a module (.ko files stored in /usr/lib/modules). Modules can be loaded/unloaded dynamically by the kernel as needed.

A fairly generic and compatible base configuration for your architecture can be created by running the following command. This handles a large portion of the work required during the configuration stage.

$ make defconfig

There are countless flows of configuring the Linux kernel, and there are fun things to try scattered all over the internet. Good luck!

[2.0] Modifying a config

There are several ways to modify an existing config file that are more convenient than editing each of them by hand, most of them very well documented. They arrange all of the config options in neat menus and submenus and provide descriptions for each of them, allowing the Linux kernel to be comprehended by mere mortals.

Terminal based configuration tools (requires ncurses)

$ make menuconfig
$ make nconfig

Graphical configuration tools (requires a working Xorg server and QT/GTK)

$ make xconfig  # Requires qt5.
$ make gconfig  # Requires gtk+3.

Another option you may find very useful to easily trim down general (default, distro, etc.) configuration files is:

$ make localyesconfig

This modifies the current .config to only compile whatever drivers are loaded in the host kernel's current state. Running this after connecting all the hardware you will be using is a pretty quick way to come up with a pretty lean configuration.

[3.0] Package compatibility

Various parts of the Linux build system use non-standard options with core utilities, this causes a build failure when using busybox. Thankfully, this non- standard usage depends on unimportant and rarely used kernel features.

When these options are disabled (is the case by default unless 'allyesconfig' is used), the kernel builds just fine.

The following options are mandatory (when using busybox) (=n).

Because gmp, mpc, and mpfr are bundled with our gcc instead of being built as standalone packages, the headers are missing. This results in build failures when building GCC Plugins. Either install gmp & mpc separately from gcc, or disable CONFIG_HAVE_GCC_PLUGINS in the kernel config.

[4.0] Never lose your .config ever again

The kernel can be configured to store its configuration file to later make it accessible via /proc/config.gz. Storing the .config in the kernel ensures that you will never lose your config so long as you have its kernel.

The following options are recommended (=y).

[5.0] Removing the perl requirement

Perl is needed by the build_OID_registry script which will be executed during the compilation process in most systems. This makes perl a mandatory dependency to build the kernel.

A patch can be applied which adds a POSIX shell implementation of the perl script. This fully removes the perl requirement.

@/patches/kernel-no-perl.patch (Written by $/E5ten)