← PREV_LEC

NEXT_LEC →

💡 Tip — Explore make help

Run make help from the kernel source root to see every available target. Targets prefixed with * are the ones built automatically when you run make all. This is the best way to discover what the build system can do without reading through thousands of lines of Makefiles.

💡 Always Keep vmlinux and System.map

Even if you never plan to debug the kernel, store vmlinux and System.map in a safe location after your build. If you hit a kernel oops later, these two files let you decode the crash — without them the stack trace is just raw hex addresses.

💡 No Location Change in Linux 6.x

The bzImage name and path are unchanged across all modern kernels from 5.x through 6.12 LTS. What did change are the toolchain requirements for building it, covered in the prerequisites section below.

💡 Linux 6.x Change — Modules Are Now .ko.zst

Since kernel 5.13, the build system compresses module files with zstd by default. Your compiled module files will carry the .ko.zst extension instead of plain .ko. The kernel loads them transparently — no manual decompression needed. Ensure the zstd package is installed on your build machine before running make.

⚠ Warning — Low RAM Systems

Each parallel compile job spawns a GCC or Clang process that consumes RAM. On a VM with less than 2 GB RAM, using all cores may trigger the OOM (Out of Memory) killer mid-build. If the build crashes silently, reduce the -j value to 2 or 4, or add swap space before building.

💡 When to Use Which Clean Target

Use make clean when you want to force a full recompile without losing your configuration. Use make mrproper only when switching to a completely different kernel version or resetting everything from scratch — it deletes your .config file, so copy it somewhere safe first if you want to keep it.

Q: How long does a Linux 6.x kernel build take?

On a modern 8-core machine with 16 GB RAM using make -j16, a full build typically takes 6 to 10 minutes. On a 2-core VM with 2 GB RAM using make -j4, expect 25 to 40 minutes. The first build is always the slowest. Subsequent incremental builds after small changes take only seconds to a few minutes because kbuild only recompiles changed files.

Q: Can I build the Linux kernel on a Raspberry Pi?

Yes, but it is slow on older models. A Raspberry Pi 5 with 4 GB RAM can build natively in around 30 to 45 minutes. For serious embedded development it is far more practical to cross-compile on your x86_64 development laptop. We cover cross-compilation for ARM in a later lecture in this free Linux kernel development course.

Q: What does the build number in “bzImage is ready (#5)” mean?

The number in parentheses tracks how many times this kernel source tree has been successfully built. It is stored in a counter file inside the build tree and increments with each successful build. It is useful when testing multiple iterations of a change so you can confirm which build is currently running without checking the full version string.

Q1. What is the difference between vmlinux and bzImage?

vmlinux is the raw uncompressed ELF binary of the Linux kernel. It is not bootable but is essential for kernel debugging — tools like gdb and the crash utility need it to resolve function names from raw memory addresses. bzImage is a compressed, self-extracting kernel image. The bootloader (GRUB) loads bzImage into RAM and the kernel decompresses itself before starting. On x86_64, bzImage lives at arch/x86/boot/bzImage.

Q2. What does the -j flag in make do and what value should you choose?

The -j flag enables parallel compilation by specifying the maximum number of simultaneous jobs make can run. Without it, only one file compiles at a time regardless of how many CPU cores your machine has. The recommended value is two times the number of CPU cores. Using make -j$(nproc) automatically detects the core count, though strictly speaking $(nproc) gives the core count and you want twice that — make -j$(($(nproc)*2)) for optimal throughput on HyperThreaded systems.

Q3. What is a kernel module and how does it differ from built-in kernel code?

A kernel module is code compiled as a separate .ko.zst file that can be dynamically loaded into a running kernel and unloaded when no longer needed. Built-in code (config option set to Y) is compiled directly into vmlinux and is always present in memory from boot. Modules allow you to extend kernel functionality without rebooting and reduce memory footprint by only loading drivers for hardware that is actually present and in use.

Q4. What is System.map and what is it used for?

System.map is a text file generated during the kernel build that maps every kernel function and variable to its exact memory address in that specific build. The kernel’s /proc/kallsyms interface uses it for live symbol lookups. Crash analysis tools use it to translate raw hex stack trace addresses into human-readable function names. The addresses in System.map are build-specific — they change every time you compile.

Q5. What new build dependencies does Linux 6.x require that older 5.4 kernels did not?

Two critical additions: dwarves (pahole) — required since 5.18 for generating BTF (BPF Type Format) data. Without it the 6.x build fails completely, not just warns. Second, zstd — required since 5.13 because kernel modules are now stored as .ko.zst (zstd-compressed) files instead of uncompressed .ko files. Additionally, Linux 6.x mandates a modern compiler: GCC 11 or newer, or Clang 14 or newer.

Q6. What is the kbuild system?

kbuild is the Linux kernel’s build infrastructure — a layered system of Makefiles spread across the entire source tree. Every directory that contains compilable source has its own Makefile that lists exactly which files to build. The top-level Makefile coordinates everything. kbuild reads the .config file to decide what to include, handles cross-compilation transparently when you set ARCH and CROSS_COMPILE, and provides clean targets for resetting the build state.

Q7. What happens if you run make without first generating a .config file?

If no .config exists, kbuild cannot determine what to compile. Behaviour varies by kernel version: some versions abort with an explicit error, others may auto-generate a default config. Either way you should never rely on auto-generated defaults — always explicitly run a config step first (make defconfig, make menuconfig, or copy an existing config). A misconfigured build wastes time and may produce a kernel that does not boot on your hardware.