| Lesson 1 | Linux Kernel Configuration and Compilation: Introduction |
| Objective | Choose an appropriate kernel-management approach and explain the module's build and verification workflow. |
The Linux kernel manages CPU time, memory, devices, filesystems, and networking. Applications use its services through system calls; desktop environments, shells, and network servers run mainly in user space. A graphical desktop is therefore not a feature that every kernel must contain.
This module explains how to inspect and configure kernel modules, decide whether a custom kernel is justified, and carry a source build through installation and verification. Administration examples use Red Hat Enterprise Linux (RHEL) 10. The source-build exercises describe an upstream Linux kernel in a disposable x86-64 lab; they are not instructions for replacing a supported RHEL kernel on a production server.
A missing capability does not automatically require compilation. Start by identifying the running kernel and checking whether the required feature is already built in, available as a module, or controlled by a documented runtime setting. For a normal RHEL kernel update, use the distribution's signed packages and maintenance procedure. Installing an update and booting it are separate operations.
uname -r
uname -m
cat /etc/os-release
rpm -q kernel-core
Record these results before making changes. The release printed by uname -r identifies the kernel executing now, which may differ from the newest installed kernel. Later lessons use a separate target release when preparing a custom kernel that has not yet booted.
modinfo, lsmod, and modprobe for different administrative questions.A kernel build has four distinct stages: configuration chooses features; compilation creates binaries; installation places artifacts where the system expects them; booting activates the selected kernel. A successful compiler exit does not prove that the machine can find its root filesystem or that its network works.
Use a virtual machine with a snapshot and console access for the lab. Preserve its known-good kernel, modules, and boot entry. Secure Boot and module-signature policy must be considered before installation: a binary can compile successfully and still be refused by the boot chain or running kernel.
The next lesson establishes the distinction between kernel architecture and loadable modules.