Building Your Own Linux Kernel

The kernel is just a program

The Linux kernel is a single open codebase published at kernel.org. Arch, Debian, Fedora, Ubuntu and Gentoo all ship builds of that same source. Nothing about compiling it is Gentoo-only — what differs between distributions is only how each one packages, installs and boots the result. Once you understand the build, you can run a custom kernel anywhere.

You can run a custom kernel on any distro

The compile step is identical everywhere. Only the install conventions change.

Why build your own kernel?

There are real benefits — and an honest counterpoint.

Gentoo gives you three paths

All are legitimate. This presentation follows the manual path — where the real learning happens.

Install the sources & set the symlink

gentoo-sources unpacks into /usr/src. The /usr/src/linux symlink tells every build tool which tree is 'current'.

# 1. Install the kernel source tree
emerge --ask sys-kernel/gentoo-sources
 
# 2. List installed kernel sources (the * marks the active symlink)
eselect kernel list
#   [1]   linux-6.12.x-gentoo
#   [2]   linux-6.16.x-gentoo *
 
# 3. Point /usr/src/linux at the version you want to build
eselect kernel set 2
 
# 4. This is now where all build commands run:
cd /usr/src/linux

Why: Why the symlink matters: tools like 'make', module builds and external drivers (e.g. NVIDIA) all look at /usr/src/linux. Repoint it whenever you switch kernel versions.

A distro .config enables everything

Copying an ArchISO / generic .config gives you a working but enormous starting point.

lsmod already knows your hardware

When Linux boots, udev loads a driver for each device it detects (matched by PCI/USB IDs). The output of lsmod is therefore a precise list of what THIS machine needs. 'make localmodconfig' reads that list and switches off every module that is not currently loaded — turning a giant config into a tailored one automatically.

Running localmodconfig

Run it inside /usr/src/linux. It reads lsmod from the running system (or a saved file) and rewrites .config.

# Simplest form: trim based on THIS running system's loaded modules
cd /usr/src/linux
make localmodconfig
 
# It uses an existing .config as the base. Seed one first if needed:
zcat /proc/config.gz > .config       # config of the currently running kernel
# (requires CONFIG_IKCONFIG_PROC=y in the running kernel)
 
# Cross-machine: capture lsmod on machine A, trim on machine B
lsmod > /tmp/mylsmod                  # on the target machine
make LSMOD=/tmp/mylsmod localmodconfig # on the build machine

Why: localmodconfig never invents a config from nothing — it always trims an existing .config down. Always start from a base that already boots.

It only sees hardware active right now

This is the one trap. Anything not loaded at scan time gets disabled — and then its driver is missing.

Why localmodconfig prompts you

After trimming, the tool may still ask you about individual options. Here is why — it bridges directly into the next section.

• Your base .config and the kernel you are building are rarely the same version.
• A newer kernel introduces NEW config symbols that your old .config never answered.
• When a symbol has no recorded answer and no safe default, the tool must ask you.
• So you will see a stream of [Y/n/m/?] prompts — these are not errors, they are genuine choices.
• The next section decodes the prompts you are most likely to meet.

Never panic — the '?' always helps

Each letter is a possible answer. The UPPERCASE letter is the default (just press Enter to accept it). Y = build into the kernel, n = leave it out, m = build as a loadable module, ? = print the help text for this exact option. When you don't recognize a symbol, press ? first — it explains what the option does before you commit.

Built-in (Y) vs Module (M) vs Off (N)

This single choice, repeated for every driver, is the heart of kernel configuration.

When you NEED an initramfs

An initramfs (initrd) is a tiny temporary root that loads modules needed to reach the real root.

Kernel compression type

CONFIG_KERNEL_* — how the kernel image (and often the initramfs) is compressed. The kernel self-decompresses at boot.

Note: Recommendation for newcomers: ZSTD. Great compression with fast decompression. If unsure, GZIP is always safe.

RCU_BOOST

RCU = Read-Copy-Update, a lock-free mechanism that lets readers run without blocking writers. RCU_BOOST temporarily raises the priority of tasks holding up RCU on preemptible kernels.

SHA-3 (CONFIG_CRYPTO_SHA3)

A cryptographic hash algorithm exposed through the kernel's crypto API — alongside SHA-256, SHA-512 and others.

SLUB_CPU_PARTIAL

A tuning option for SLUB, the kernel's default memory (slab) allocator. It keeps per-CPU lists of partially-used memory slabs.

DNET (CONFIG_DNET)

A driver for the 'Dave DNET' Ethernet controller — an obscure chip found in a few embedded boards.

NETERION — and the vendor-menu pattern

CONFIG_NET_VENDOR_NETERION gates the Neterion / Exar 10-Gigabit server NIC drivers (s2io, vxge).

I2C (CONFIG_I2C)

I²C is a low-speed bus connecting small on-board chips: sensors, EEPROMs, HDMI/DisplayPort DDC, and some touchpads.

How to answer ANY unknown prompt

You will meet options this deck never named. This four-step decision handles all of them.

Other common surprise prompts

A quick reference so unfamiliar questions don't stop you. Press ? on any of these for detail.

Driving the menuconfig interface

A curses (text) UI over the same .config. Learn six keys and you can move anywhere instantly.

cd /usr/src/linux
make menuconfig
 
#  ↑ ↓        move between options
#  Enter     enter a submenu  (entries ending in --->)
#  Esc Esc   go back up one level
#  /         SEARCH for a symbol  <- your superpower
#  ?         help for the highlighted option
#
#  Toggling an option:
#    [ ] / [*]    bool   : off / built-in            (space cycles)
#    < > / <M>    tristate: off / module / built-in   (y, m, n)
#    { }          a module forced by something selecting it

Why: The '/' search is the fastest tool here: type a symbol name (e.g. NVME), and it shows the exact menu path, dependencies, and what selects it.

Why your menu may look different

Don't worry if your screen doesn't match a tutorial exactly. The tree is conditional.

• Architecture changes the menu: x86-64, ARM and others expose different entries.
• Enabling EXPERT (in General setup) reveals extra low-level options that are normally hidden.
• Dependencies hide things: an option only appears once whatever it requires is enabled.
• Kernel version matters: new releases add, rename and reorganize symbols — this deck targets modern kernels (6.x and the upcoming 7.x line).
• Use '/' to find anything by name rather than hunting visually.

General setup

Broad kernel-wide behavior and identity. The first menu, and one of the most important.

Processor type and features

Tell the kernel exactly what CPU it will run on — a major source of real-world speedups.

Bus options (PCI etc.)

Support for the physical buses that connect devices to the CPU.

Binary Emulations + Firmware Drivers

Two smaller menus, grouped: running other-format binaries, and talking to platform firmware.

Power management and ACPI options

Sleep states, thermal control, CPU frequency scaling, and battery handling.

General architecture-dependent options

Cross-cutting low-level knobs that depend on your CPU architecture.

Enable loadable module support

The master switch that makes 'M' possible at all.

Enable the block layer

The subsystem that handles block devices — anything you store data on in blocks.

Memory Management options

How the kernel manages RAM, paging, and swap behavior.

Executable file formats

Which program binary formats the kernel can load and run.

Networking support — core

The entire network stack lives here, starting with the protocols themselves.

Networking support — Netfilter

The firewall and packet-manipulation framework — the kernel side of nftables/iptables.

Device Drivers

This is where the kernel meets your actual hardware — hundreds of submenus covering storage, graphics, networking devices, USB, input, sound and more. It dwarfs every other top-level entry combined. Because it is so large, we break it across the next four slides by category. This is also where localmodconfig saves you the most: it disables the thousands of device drivers you'll never touch.

Device Drivers — storage (root-critical)

The drivers that let the kernel see the disk your system lives on. Get these wrong and it will not boot.

Device Drivers — Graphics (DRM)

Under 'Graphics support'. The DRM (Direct Rendering Manager) subsystem drives your display.

Device Drivers — network, USB, HID, I²C

The everyday peripheral drivers — this is what localmodconfig trims most aggressively.

File systems

Which filesystems the kernel can mount — including, critically, the one your root lives on.

Security options

Access-control frameworks and integrity features layered on top of standard Unix permissions.

Cryptographic API

The kernel's library of ciphers and hashes — used by disk encryption, module signing, and the network stack.

The remaining menus

Smaller top-level entries, grouped. Most newcomers leave these at defaults.

What MUST be right or it won't boot

Across the whole menu, four things decide whether your kernel boots. (1) The driver for the disk holding root (e.g. NVMe). (2) The root filesystem driver (e.g. XFS). (3) If encrypted, the crypto + dm-crypt support (LUKS). (4) An initramfs if any of those is a module instead of built-in. Get these four right and the rest is optimization.

make — building the kernel

Compilation is parallelizable. The -j flag sets how many jobs run at once.

cd /usr/src/linux
 
# Build using one job per CPU thread (nproc reports the count)
make -j$(nproc)
 
#  -j N   run N compile jobs in parallel
#  nproc  prints your number of CPU threads, e.g. 16
#
# Expect anywhere from a couple of minutes (lean config, fast CPU)
# to much longer (a fat distro-style config). This is exactly why
# we trimmed with localmodconfig first.

Why: If the build fails, the error usually names a missing tool or an unmet config dependency — read the last few lines; they are specific.

make modules_install

Installs every module you built (the M choices) into the standard location, where the kernel finds them at runtime.

make modules_install
 
# Installs to:
#   /lib/modules/<kernel-version>/
#
# This must run BEFORE you rely on any modular driver, and the
# version directory must match the kernel image you boot. An
# initramfs (built next) pulls the early-boot modules from here.

Why: Order matters: install modules before generating an initramfs, so the initramfs can copy the modules it needs from /lib/modules.

Copying the kernel image to /boot

The compiled kernel for x86 is called bzImage. You can let 'make install' place it, or copy it manually to understand the layout.

# Make sure /boot is mounted first (often a separate partition!)
mount /boot      # if it isn't already
 
# The freshly built image lives here on x86/x86-64:
#   arch/x86/boot/bzImage
 
# Manual copy with a versioned name (recommended for clarity):
cp arch/x86/boot/bzImage  /boot/vmlinuz-6.16.0-gentoo
cp System.map             /boot/System.map-6.16.0-gentoo
cp .config                /boot/config-6.16.0-gentoo
 
# ...or let the kernel's installer do it for you:
make install

Why: Versioned names let multiple kernels coexist in /boot, so you always keep a known-good fallback to boot if the new one misbehaves.

Generating an initramfs (when needed)

Recall Section 3: if a root-critical driver is a module, you need an initramfs to load it early. dracut is the common tool.

# Install dracut once
emerge --ask sys-kernel/dracut
 
# Generate an initramfs for a specific kernel version
dracut --kver=6.16.0-gentoo
 
# This produces, e.g.:
#   /boot/initramfs-6.16.0-gentoo.img
#
# dracut auto-detects what's needed to reach root (NVMe, XFS,
# dm-crypt/LUKS, LVM...) and bundles those modules from
# /lib/modules. That's why modules_install runs first.

Why: If you built every root-critical driver in (Y), you may be able to skip the initramfs entirely — but one is required for LUKS, LVM or RAID roots.

Updating GRUB — the easy way

GRUB can scan /boot and write boot entries automatically, detecting your kernels and matching initramfs images.

# Regenerate the GRUB config (detects kernels + initramfs in /boot)
grub-mkconfig -o /boot/grub/grub.cfg
 
# Expected output mentions each kernel it found, e.g.:
#   Found linux image: /boot/vmlinuz-6.16.0-gentoo
#   Found initrd image: /boot/initramfs-6.16.0-gentoo.img
#
# Reboot and pick the new entry from the GRUB menu.

Why: Always keep your previous working kernel as an entry. If the new kernel won't boot, pick the old one and fix the config — no reinstall needed.

A manual GRUB entry, explained

Understanding the entry helps when auto-detection misses something. Each line has a clear job.

menuentry 'Gentoo 6.16.0 (custom)' {
    # which disk/partition GRUB reads the kernel from
    set root=(hd0,gpt2)
 
    # the kernel image + parameters passed to it
    linux /vmlinuz-6.16.0-gentoo root=/dev/nvme0n1p3 rootfstype=xfs rw
 
    # the initramfs to load alongside the kernel
    initrd /initramfs-6.16.0-gentoo.img
}
 
#  root=         which device holds the real root filesystem
#  rootfstype=   filesystem type of that root (helps early mount)
#  rw            mount root read-write at boot

Why: For an encrypted root you'd add a parameter like rd.luks.uuid=... so the initramfs knows which LUKS device to unlock before mounting root.

The complete workflow

Every step from bare sources to a booted custom kernel.

Common boot failures & fixes

Almost every failed custom kernel comes down to one of these.

Going further

Resources and gentler paths once you've done it the manual way.

You can build a kernel anywhere now

The manual Gentoo path teaches the real mechanics: trimming with localmodconfig, decoding each prompt, walking menuconfig, and installing the result. That knowledge transfers to every Linux distribution — because under all of them is the same kernel, waiting for you to build it.