Kernel compilation howto

Prerequisites

For the compilation itself, you may need several packages. Historically I seem to recall packages such as:

gcc
make (gmake, GNU make)
binutils
bc
kernel-headers (perhaps not necessary)
bison
byacc
flex
ncurses-dev
libssl-dev
libelf-dev
bzip2 (perhaps not necessary)
dwarves

Get a copy of the kernel source

Download and unpack a kernel tarball from kernel.org. Feel free to use a browser to select a version that suits you.

cd /usr/src
wget --no-check-certificate https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.0.13.tar.xz
tar xvf linux-5.0.13.tar.xz
cd linux-5.0.13

Alternatively, you can install the kernel source for your distro kernel from RPM/DEB depending on distribution... (using RPM, YUM, APT, whatever)

Configure your kernel before compilation

Tell the newly unpacked kernel sources to get comfortable in your system:

make mrproper

Configure the kernel, using one of the following:

make oldconfig

cp /boot/config-<your_choice> ./.config
make menuconfig

The point is that the kernel config is stored in a text file called .config, that needs to be created in the kernel source tree root directory (root of the tarball just unpacked). The pristine kernel tarball does not contain one. If it does, such .config probably doesn't match your distro/hardware. How you arrive at a plausible .config, that's your choice.

You can either use the traditional "make oldconfig", which will try to find a backup of the running kernel's config somewhere in the system.
Or, you can find the backed-up copy in the /boot directory of your distro. The backup copy is not mandatory for a proper boot of the distro, it's there merely for your convenience.
If you copy the .config from a backup by hand, and the kernel version is not a precise match (likely it is not), menuconfig can sort that out - it'll drop options it doesn't know for the kernel version being configured. The .config that you save on exit from menuconfig will be valid.

You can also create a new .config from scratch, by running make menuconfig in a pristine kernel source tree.

Generic pitfalls in the kernel config

Beware, the new kernel may add options (and defaults for them) that were not present in the old .config. Such as, recent kernels seem to add:

 EXPERT : General setup -> Configure standard kernel features (expert users)
 DEBUG_KERNEL : Kernel hacking -> Kernel debugging
 SECURITY_LOCKDOWN_LSM : Security options -> Basic module for enforcing kernel lockdown
 MODULE_SIG : Enable loadable module support -> Module signature verification

make -j 6 INSTALL_MOD_STRIP=1 modules_install && make install

Beware of kernel module versioning. Depending on how advanced you are, it may help you avoid goofed-up kernel reinstalls, or it may present a hassle if you DO NOT want to recompile+reinstall the modules every time your main monolithic binary is recompiled. For least hassle, turn off kernel module versioning *and signing*. That's in menuconfig

  Enable loadable module support -> Module versioning support
  Enable loadable module support -> Module signature verification

Compile and link

Next, you need to produce a kernel binary, and a set of modules. Modules will be created for components, that you tagged with "M" in menuconfig. (Note that you can skip these two commands, make install and make modules_install will call these automatically if omitted.)

make bzImage
make modules

The resulting bootable kernel binary will be left at
./arch/x86/boot/bzImage
The modules will be interspersed with source files throughout the whole source tree.

Performance hint: in a modern PC, you likely have multiple CPU cores. Especially the compilation and linking phase are bounded by CPU horsepower, and the individual translation units can be handled in parallel. The "make" program can handle this parallelization automagically. All you need to do is tell it, how many parallel processes to start. You can even count on SMT/HT to squeeze the last bit of juice out of your CPU (feel free to benchmark and compare).
The sweet parameter here is -j <number> . Meaning the number of threads desired. I typically put that number equal to the number of my CPU cores, but other people recommend N+1, perhaps to keep the machine busy even during periods while the system is waiting idle for the start of a new thread or something.
Example:

make -j 4 bzImage
make -j4 modules

What do I do with the binaries

Beware: "make install" may end up updating your initrd and grub configuration!
See the following two chapters and maybe prepare their config for that eagerness on part of "make install". That said, don't panic, either - you will have a chance to change the config of initrd and grub after "make install".
Such as, if this kernel is newer than your current default entry, "update-grub" will try to boot your new kernel by default. What a pesky side-effect.

You can copy the monolithic kernel by hand from arch/i386/boot/bzImage to wherever you want it, probably /boot/SOME_NICE_NAME.

Or you can call "make install" to have your distro select a predictable name for your new kernel and do the copy to /boot.

You definitely want to perform "make modules_install", which will collect the resulting binary modules (*.ko) into /lib/modules/kernel_version/, which is where you want to leave them (unless you're going to copy them to another bootable disk / image, and obviously you know what you're doing)

make modules_install
make install

This has put the monolithic binary and the modules into place, automagically.

Let's take a look into the boot directory.

cd /boot
ls
ls -l

Create a new initrd

Most modern distro's are using a temporary "initial ramdisk", for various reasons. It used to be required for loading hardware-specific disk controller drivers as modules, nowadays there are further dependencies (LVM, udev, ...).

You can often get the distro to boot with a monolithic kernel, but it takes time to pick the right options that need to be made monolithic.

It's usually a safe bet to do something like "make oldconfig" and then build your own initial ramdisk with all the modules. The distro usually contains a script called something like mkinitrd, which requires a kernel version / path to the modules to be copied to the ramdisk image.

A particular initrd image typically only contains modules for a single kernel version = to support multiple kernel versions, you need a dedicated initrd file for each kernel version. (Lest some modules fail to load at initrd startup.) That's why, in /boot/, you can see a corresponding versioned initrd for every kernel image in there.

Debian/Ubuntu:

update /etc/initramfs-tools/initramfs.conf (for a smaller size, specify MODULES=dep)

update /etc/initramfs-tools/modules - you may wish to add some of:

raid1
sd_mod
crc16
crc32c_intel
crc32c_generic

Auto-update or manually create from scratch an initial ramdisk for your new kernel:

update-initramfs -u -k <kernel_version>     # = this is a higher level automagical tool

mkinitramfs [kernel_version]   # a lower level tool

If this kernel version is new on your system, skip the -u option to update-initramfs (or it will complain that there's nothing to update) and instead use the -c option (= create a new initrd for this kernel).

Configure and update Grub; reboot

Check /etc/default/grub , you may want to add the following at the kernel cmdline:

To disable any Spectre/Meltdown safeguards that eat CPU horsepower:

 The old way:
  pti=off nospectre_v1 spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrier noretpoline

 The new way (since Kernel 5.2):
  mitigations=off

If you want to let hwmon (lm_sensors) to access the SuperIO HW monitor chip:

acpi_enforce_resources=lax

To force a particular video mode (e.g. if a KVM switch is giving you trouble):

video=1280x1024@60

To work around some bugs in Intel ATOM BayTrail/Braswell IGP power saving, that cause freezes when running X-Windows with or even without video playback, try the following curse:

intel_idle.max_cstate=1

Return to the good old Ethernet netdevice names such as eth0, eth1 etc.:

net.ifnames=0

To make the system more talkative at boot time, try removing "quiet" and "splash".

Note that you can test the individual kernel cmdline curses at runtime, without clobbering your grub.conf forever - choose "extended options" in the Grub menu and pres "e" to edit the entry. Whatever options you add or erase, they won't get stored into grub.conf .

Still in /etc/default/grub, you may want to change the "default" entry. If you've just compiled a very new kernel, chances are that it's newer than your current running kernel, and update-grub will default to moving this new kernel to the formost position in the boot menu. The "default" in /etc/default/grub is a zero-based ordinal number, referring to the entries in /boot/grub/grub.cfg (menu.lst in the old days).

NOTE THAT SO FAR, YOU HAVEN'T SPOILED YOUR BOOT CONFIGURATION.
YOU HAVE MERELY COPIED A FEW NEW FILES SOMEPLACE HARMLESS.

ON TO THE HARMFUL STUFF.

Then finally, tell grub to update its config:

update-grub

Now the harm has been done, potentially :-)

reboot

Side notes on the build process

Further updates to the compiled and installed kernel:

At the compilation stage, if you want to erase any previously compiled object files (binary snippets comprising the final monolith), just call 'make clean' before, after or without 'make menuconfig'. Note that 'make mrproper' does an even more thorough cleanup, specifically it deletes any existing .config .

make clean
make menuconfig
make bzImage
make modules

If you turn off kernel module versioning (often a good thing), but you still want to keep a few different boot profiles with different kernel configurations, you need to have a few different module subdirs under /lib/modules, for the same kernel version. Some global configuration options can change your monolith and modules to the point that they're incompatible with a different configuration of the same version kernel source tree. So, to achieve the multiple copies of the module set under your /lib/modules subdir, consider explicitly modifying the top-level Makefile in the kernel source tree, the appropriate line is called

EXTRAVERSION

VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 21
EXTRAVERSION = .7-HACKED-v001

The following invocation of "make modules_install" will automatically create a separate directory under /lib/modules, named accordingly.

At the very least, you can use a custom extraversion to distinguish your own cut of the modules from the distro-default modules (if you're recompiling the distro's default kernel version from source).

In general, use a different extraversion if:

• you want to keep a default boot profile with the distro-original kernel+modules, and add your custom kernel as a new profile, while the custom kernel is the same version as the default kernel
• you want to have multiple custom kernels (custom configs of the same version) in the bootloader, e.g. for different CPU's

You need to recompile and reinstall from scratch (start with "make clean") and maybe modify the EXTRAVERSION if:

• you have modified some key features in the config (CPU subtype, with/w.o. SMP, some other global optimization stuff) Actually this case is noticed consistently and handled automatically with the more modern Kbuild versions (kernel versions).
• you have hacked some global header files even just a little bit (the automatic dependency checking may not notice - though lately it does get noticed reliably too)

OTOH, you can avoid "make clean" if:

• you only modified an isolated .c file (or several .c files) in the tree, which is a change that doesn't affect other translation units other than the file modified. "Make" will notice the change of file creation date and update the object files automatically.
  All you need to do next is reinstall the affected kernel binaries (the monolith or the respective moodule).

If you're building some modules out of tree (which appears to be turning into a no-no recently) you need to have "modversions.h" already created in the tree you're building against.
I.e., your tree already needs to be past "make modules" (if not past "make modules-install").
There used to be an officially supported way (Makefile structure etc) for compiling your own drivers out of tree.
That said, it's sadly true that modern kernels tend to punish you for compiling things "out of tree", by tainting the kernel on insmod of such a module. The morale is: learn to implant your source code straight into the source tree :-(

Make a debian package