1. Installing All Required Dependencies First

Most kernel build failures come down to one thing: a missing package. The kernel’s own documentation lists its minimum requirements in Documentation/process/changes.rst inside the kernel source tree. Always check this file for the kernel version you are building, because the requirements change between major versions.

For kernel 6.x on the major distributions, here is what you need before you even start:

# Ubuntu / Debian (kernel 6.x)
sudo apt update
sudo apt install build-essential flex bison \
    libssl-dev libelf-dev libncurses-dev \
    bc dwarves pahole git

# Fedora / RHEL / Rocky Linux (kernel 6.x)
sudo dnf install gcc make flex bison \
    openssl-devel elfutils-libelf-devel ncurses-devel \
    bc dwarves git

# Arch Linux
sudo pacman -S base-devel flex bison openssl \
    libelf ncurses bc pahole git

2. Error: openssl/opensslv.h — No Such File or Directory

This is one of the most commonly encountered kernel build errors, especially on fresh installations. Here is what it looks like:

# Ubuntu / Debian:
sudo apt install libssl-dev

# Fedora / RHEL:
sudo dnf install openssl-devel

# Raspberry Pi OS:
sudo apt install libssl-dev

# After installing, simply re-run your make command
make -j$(nproc)

The reason the development headers are separate from the runtime is a deliberate packaging decision in Linux distributions: end users only need the runtime library to run programs that use SSL. Developers who compile software against OpenSSL need the headers additionally. The kernel build system is a developer tool, so you need both.

3. Error: Kernel Does Not Support PIC Mode / -fPIC

This error appeared more commonly when building older kernels with newer GCC versions, but understanding it is important for any embedded Linux developer.

4. Other Common Build Errors — Quick Reference

# Ubuntu:
sudo apt install flex bison
# Fedora:
sudo dnf install flex bison

# Ubuntu:
sudo apt install dwarves
# Fedora:
sudo dnf install dwarves

scripts/config --disable CONFIG_DEBUG_INFO_BTF
make -j$(nproc)

scripts/config --disable SYSTEM_TRUSTED_KEYS
scripts/config --disable SYSTEM_REVOCATION_KEYS
make -j$(nproc)

5. The Most Reliable Troubleshooting Technique

When you hit a kernel build error that you cannot immediately recognise, there is one technique that works more often than you might expect: copy the exact error message, open a search engine, and search for something like linux kernel 6.x build fails openssl/opensslv.h. Include the kernel version and the key part of the error.

The Linux kernel community is vast and well-documented. Chances are very high that someone else has hit the same error on the same distribution and posted a working fix. The kernel’s own mailing list archives, Stack Overflow, the Arch Linux wiki, and the Ubuntu Ask community are especially good sources.

6. Embedded Linux: Yocto and Buildroot

In professional embedded Linux product development, you rarely build the kernel by hand using the steps described in this series. Instead, you use a Linux builder framework. These are complete build systems that take a hardware description, a list of packages, and a kernel configuration, and produce an entire bootable Linux image — kernel, root filesystem, bootloader, and all.

6.1 What a BSP Team Does

In larger companies, a BSP (Board Support Package) team is responsible for porting Linux to new hardware. Their job includes writing or adapting the bootloader (usually U-Boot), writing the device tree source (DTS) files that describe the hardware to the kernel, and configuring and building the kernel for the specific SoC. If you join an embedded Linux team, understanding the kernel build process deeply — as covered in this series — means you can understand and contribute to BSP work even if a framework like Yocto automates the mechanics.

6.2 Why You Still Need to Understand Manual Builds

Even when Yocto or Buildroot is used in a project, there are situations where manual kernel knowledge is essential:

• Debugging a kernel issue requires reading and understanding kernel config options directly.
• Writing a new device driver means testing it by manually building and loading a kernel module — not running a full Yocto build for every change.
• Kernel configuration tuning for performance or security is done at the make menuconfig level regardless of which framework is used on top.
• Cross-compilation concepts — target architecture, cross-compiler prefix, sysroot — are the same whether you use Buildroot or do it manually.

7. Cross-Compilation Basics

When your development machine is x86-64 but you are building a kernel for an ARM device (like a Raspberry Pi or an i.MX board), you need a cross-compiler — a compiler that runs on x86-64 but produces ARM binaries.

# Install an ARM64 cross-compiler on Ubuntu
sudo apt install gcc-aarch64-linux-gnu

# Set environment variables before building the kernel
export ARCH=arm64
export CROSS_COMPILE=aarch64-linux-gnu-

# Now run make as normal — it will use the cross-compiler
make -j$(nproc)

# For 32-bit ARM (e.g. older Raspberry Pi models):
sudo apt install gcc-arm-linux-gnueabihf
export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabihf-
make -j$(nproc)

8. Verifying a Successful Build

After a successful kernel build, here is how to confirm everything is in order before installing:

# Check the main kernel image was produced
ls -lh arch/x86/boot/bzImage       # x86-64
ls -lh arch/arm64/boot/Image.gz    # ARM64

# Check kernel modules were built
find . -name "*.ko" | wc -l   # Should show hundreds of modules

# Check the kernel version string embedded in the build
strings arch/x86/boot/bzImage | grep "Linux version"

# Check module signing configuration
grep CONFIG_MODULE_SIG .config

# View build configuration summary
make listnewconfig   # Shows new Kconfig options not yet set in .config