What's changed: Initial version (topic 2.01, subtopics 2.01.1–2.01.5)
1.4Compiling the Linux Kernel
Learn the full workflow of building a kernel from source: the .config file and kernel Makefile, configuration make targets (config, xconfig, menuconfig, gconfig, oldconfig) versus build targets (all, bzImage, modules, modules_install), the mrproper cleanup target, packaging targets (rpm-pkg, binrpm-pkg, deb-pkg), the module install location /lib/modules/<kver>/, and how it connects to depmod, DKMS, and Dracut (mkinitrd/mkinitramfs).
Real-world work sometimes calls for building a custom kernel—applying a patch, tuning for specific hardware—beyond the distro-supplied one. Exam 201 tests whether you know the configure → build → install pipeline precisely, target by target.
1.4.1Configuration targets and .config
- The starting point is
/usr/src/linux/.config(one option per line, enabled/disabled) plus the kernel Makefile. Config-time make targets offer different UIs:config(interactive, one question at a time),menuconfig(text menu),xconfig(Qt GUI),gconfig(GTK GUI). - oldconfig carries forward the existing .config and interactively asks only about options newly added in the new kernel version—the standard target when upgrading kernel versions.
- mrproper restores the source tree to a fully pristine state, removing build artifacts and even
.config. Use it for a thorough clean before starting a build over.
1.4.2Build, install, and packaging targets
- Build targets:
make all(the full default set),make bzImage(just the compressed kernel image),make modules(loadable modules). - make modules_install installs the built modules under
/lib/modules/<kver>/. The standard next step is running depmod to rebuild the module dependency index. - Packaging targets:
rpm-pkg/binrpm-pkg(RPM family; the former also builds a source RPM, the latter binary-only) anddeb-pkg(produces Debian-family .deb packages)—bundling the build output into distributable packages. - Automated third-party module management: DKMS (
dkms), which rebuilds out-of-tree modules automatically on every kernel update. For generating the initial RAM disk for the root FS, use Dracut-family tools (mkinitrd/mkinitramfs).
Most-tested mappings: carry forward existing config, ask only new options = oldconfig, return to a fully pristine state = mrproper, module install location = /lib/modules/<kver>/, rebuild dependencies after install = depmod. Also repeatedly tested: bzImage and modules are separate steps—the image itself and the modules are built and installed independently.
Walk the full kernel-upgrade procedure. After unpacking a new kernel source at /usr/src/linux-<newver>/, copy the running kernel's .config over and run make oldconfig. This carries forward existing settings and only asks about features newly added in the new version, so you never start from scratch. To review the config visually, use make menuconfig or make xconfig. Build with make all (or targeted make bzImage modules), then run make modules_install to install modules under /lib/modules/<newver>/, followed by depmod -a to rebuild the module dependency index (modules.dep). If the root filesystem needs a custom driver to be readable at boot, generate an initramfs at this point with a Dracut-family tool (mkinitramfs -o /boot/initramfs-<newver>.img <newver>) and reflect it in the GRUB2 config (grub2-mkconfig, from the previous section). To package the build for internal distribution, use make binrpm-pkg (RPM family) or make deb-pkg (Debian family). For third-party kernel modules (e.g., a specialty storage driver), register them with DKMS so they rebuild automatically on every kernel update instead of by hand. If you want a fresh start or the build breaks, make mrproper wipes everything clean before you begin again.
| make target | Category | Effect |
|---|---|---|
| oldconfig | Configuration | Carries forward .config; asks only new options |
| mrproper | Cleanup | Wipes everything, including .config |
| bzImage / modules | Build | Builds the compressed image / modules separately |
| modules_install | Install | Places modules under /lib/modules/<kver>/ (depmod follows) |
| rpm-pkg / deb-pkg | Packaging | Produces a distributable package |
Trap: "running make modules_install also rebuilds the module dependency index automatically" is wrong—modules_install only places the files; rebuilding the dependency index (modules.dep) requires a separate depmod run. Also wrong: "make bzImage also builds all kernel modules"—bzImage builds only the image itself; make modules is a separate step for building modules.
1.4.3Section summary
- Configure = oldconfig (carries forward existing config), menuconfig etc. (UI), mrproper (full clean)
- Build = bzImage and modules are separate; after install, /lib/modules/<kver>/ + depmod; distribute via rpm-pkg, deb-pkg, etc.
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You want to carry forward the running kernel's configuration and be interactively asked only about options newly added in the new kernel version. Which make target is appropriate?
Q2. Right after installing modules with make modules_install, which command should you run to refresh the module dependency index?
Q3. You want to distribute a custom-built kernel to multiple internal RPM-family servers. Which make target should you use at the final build stage?