📷 Image Suggestion — Terminal showing make -j$(nproc) running

A screenshot or screen recording of a terminal window running make -j$(nproc) inside a Linux 6.x source tree, showing the compiler output lines scrolling with CC, LD, MODPOST entries. Helps readers know what a healthy build looks like in practice.

⚠ Building on a VM is slower — here is how to help it

A kernel build is one of the most CPU and RAM intensive tasks you can run. Inside a VM your available cores and memory are shared with the host OS. Two things help significantly. Boot the VM into a text-only runlevel (no desktop environment running) before starting the build — this frees RAM. Also allocate as many vCPUs to the VM as your host will allow in the VM settings.

📷 Image Suggestion — File size comparison diagram

A simple visual comparing vmlinux (~500 MB), System.map (~4 MB), and bzImage (~10 MB) as horizontal bars. Helps students immediately grasp why vmlinux is only for debugging and is never placed in /boot on a production system.

💡 The image name changes depending on CPU architecture

On x86 and x86_64 the image is always bzImage at arch/x86/boot/bzImage. On ARM64 it is arch/arm64/boot/Image.gz. On RISC-V it is arch/riscv/boot/Image.gz. When cross-compiling for embedded targets you need to know the correct path. You can always find it with make -s image_name from the kernel source directory.

⚡ Speed tip — Use make localmodconfig

For development and learning, you almost never need to build every possible driver. Run make localmodconfig before building to trim the .config down to only what is running on your current system. The resulting build can be three to five times faster and produces far fewer .ko files. This is the approach most kernel contributors use day-to-day.

💡 Linux 6.x note — Module Compression

In Linux 6.x many distributions and custom builds enable module compression. When active, .ko files are compressed and stored as .ko.xz (xz compression) or .ko.zst (zstd compression). This reduces the space used by /lib/modules/ significantly. Tools like modprobe and insmod handle decompression transparently — you never deal with compressed modules manually. The kernel build selects the compression algorithm based on your .config settings under General Setup → Kernel compression mode.

⚠ Never skip make modules_install before rebooting

A very common beginner mistake is to copy only the bzImage to /boot and reboot into the new kernel. When it boots, it looks for modules in /lib/modules/<new-version>/ and finds nothing there. The result is missing drivers at runtime — no network, no USB, no sound. Always run make modules_install first, then reboot.

Why is the vmlinux file so huge compared to bzImage?

vmlinux is an uncompressed ELF binary that contains every compiled kernel function, variable, and their debug symbols. It can easily be 400 to 600 MB. bzImage is produced by stripping the debug sections, compressing the remaining code and data, and prepending a small decompressor stub. The decompressor runs before the kernel proper starts at boot time, expands the kernel into RAM, and passes control to it. This is why bzImage is only 8 to 15 MB while containing essentially the same kernel code.

Can I run make modules_install and make install without sudo?

No, unless you are using INSTALL_MOD_PATH or INSTALL_PATH to redirect to a directory your user owns. Installing to /lib/modules/ and /boot/ both require root privilege because they are system directories. In embedded development workflows you almost always use INSTALL_MOD_PATH pointing to a staging area you own, which avoids the need for sudo entirely.

What happens when I rebuild the kernel a second time?

kbuild uses timestamps and dependency tracking. On a rebuild, only the files whose source has changed (or whose dependencies changed) are recompiled. This is called an incremental build and is much faster than a full build. The build counter increments from #1 to #2. You then run make modules_install again to update /lib/modules/ with the new .ko files.

What is Module.symvers and when do I need it?

Module.symvers is generated in the kernel source root at the end of the build. It lists every exported symbol from the kernel and all in-tree modules, along with CRC checksums used by module versioning (CONFIG_MODVERSIONS). When you later build an out-of-tree kernel module (an external driver) against your custom kernel, the build system reads Module.symvers to verify that the symbols your module depends on actually exist and have not changed. Without this file, out-of-tree module builds fail with undefined symbol errors.

My build failed with errors. What should I do?

First, read the error message carefully. The most common causes are: a kernel configuration conflict (two options that cannot both be enabled), a toolchain version mismatch (GCC too old or too new for the kernel version), a missing build dependency (a header or library the kernel needs), or a bad patch applied to the source. If you cannot identify the cause, run make mrproper to completely clean the source tree (this deletes your .config too, so back it up first), reconfigure from scratch, and build again.

What does .ko.xz mean in Linux 6.x module directories?

In Linux 6.x, module compression is commonly enabled in the kernel configuration. When active, make modules_install compresses each .ko file using xz compression before writing it to /lib/modules/. The result is .ko.xz files instead of plain .ko files. Zstd compression produces .ko.zst files. Both formats are handled transparently by modprobe, insmod, and depmod. You never need to manually decompress them.

Q1. What does make -j$(nproc) do and why is it preferred over make -j4?

make -j$(nproc) tells the make utility to run as many parallel compilation jobs as there are logical CPU threads on the machine. $(nproc) is evaluated by the shell at runtime and returns the actual thread count. This is better than hardcoding -j4 because it scales automatically to whatever machine you are on. A 16-thread machine uses 16 parallel jobs; a 4-thread VM uses 4. Hardcoding wastes available parallelism on powerful machines and would need to be changed manually every time you switch systems.

Q2. What are vmlinux and bzImage and how do they differ?

vmlinux is the uncompressed kernel image in ELF format. It is very large (400 to 600 MB) because it contains all kernel symbols and full debug information. You use it with GDB and the crash utility for post-mortem debugging. It is not directly bootable. bzImage is the compressed, bootable kernel image. The kbuild system takes vmlinux, strips debug sections, compresses the remaining code, and prepends a boot stub. The result is 8 to 15 MB and is what the bootloader loads from /boot/.

Q3. What is System.map and why must you keep it?

System.map is a plain text file mapping every kernel symbol (function name, variable name, exported interface) to its virtual memory address. During debugging, when a kernel panic prints a raw hex address, you look it up in System.map to find the exact function that was executing. The kernel also reads it at boot for its internal symbol resolution. Always keep the System.map file that was generated alongside the vmlinux it corresponds to. A System.map from a different build is useless because addresses change with every compilation.

Q4. What does the .ko extension mean and where do modules end up after installation?

.ko stands for Kernel Object. It is a relocatable ELF binary implementing a loadable kernel module, corresponding to any feature set to M in menuconfig. After make modules_install runs, all .ko files are copied to /lib/modules/<kernel-version>/kernel/ preserving the source tree subdirectory structure. On Linux 6.x with compression enabled they are stored as .ko.xz or .ko.zst.

Q5. What does depmod do and why does make modules_install run it automatically?

depmod reads every .ko file installed in /lib/modules/<version>/, extracts the symbols each module exports and needs, and builds a dependency graph. It writes the result to modules.dep, modules.alias, and related files. make modules_install runs depmod automatically at the end because without these files, modprobe cannot determine which modules to load first when you request a specific driver. The dependency database is what enables automatic dependency loading.

Q6. What is INSTALL_MOD_PATH and when do embedded engineers use it?

INSTALL_MOD_PATH is a make variable that redirects module installation from the system’s /lib/modules/ to any directory you specify. Usage: make INSTALL_MOD_PATH=/tmp/staging modules_install. Embedded Linux engineers use this when cross-compiling a kernel for a target board. You do not want the ARM modules inside your x86 host’s /lib/modules/. Instead you stage them to a directory, then package that directory into the target’s root filesystem image.

Q7. What is the build counter that appears after a kernel build and what does it track?

The line Kernel: arch/x86/boot/bzImage is ready (#1) at the end of a build contains a build counter. It starts at 1 for the very first build of a given source tree and increments with every rebuild. The counter is stored in a file inside the kernel source tree. When you boot into your custom kernel and run uname -a, this number appears in the version string. During active development where you rebuild multiple times a day, the counter helps you immediately confirm which exact rebuild is currently running.

Q8. What happens if you boot a new kernel but skip make modules_install?

The new kernel boots and looks for its modules in /lib/modules/<new-version>/. Because you skipped the install step, that directory does not exist or contains modules from a different kernel version. Any feature compiled as a module will be completely unavailable. Depending on your configuration this means no network interface (if the NIC driver is a module), no USB, no sound, and possibly no filesystem support. This is one of the most common mistakes beginners make when building their first custom kernel.

Q9. What is Module.symvers and when do out-of-tree module developers need it?

Module.symvers is generated in the kernel source root during the build. It lists every exported symbol from the kernel and all in-tree modules along with CRC checksums used by CONFIG_MODVERSIONS. When you build an out-of-tree kernel module (a third-party driver or your own module being developed outside the kernel tree), the build system reads Module.symvers to verify that every symbol your module depends on actually exists in the target kernel and has not changed its interface. Without this file, out-of-tree module builds fail with undefined symbol errors during the MODPOST step.