Linucate
~ Linucate_

201.1 Kernel components

All Levels

Introduction

The Linux kernel manages CPU time, memory, devices, filesystems, and networking. Administrators rarely write kernel code, but they must know which kernel image, modules, and configuration belong to a running system.

What you should be able to do after this lesson:

  • Identify the running kernel release and architecture.
  • Distinguish a kernel image from loadable modules.
  • Navigate a kernel source tree and its documentation.
  • Understand stable, long-term support, and distribution kernels.
  • Recognize common kernel image and compression formats.

Big Idea: One Kernel Release Is a Set of Matching Artifacts

A bootable Linux release is more than one file. It normally includes:

kernel image + configuration + symbols + modules + initramfs + boot entry

The release string ties these artifacts together. A kernel may start but fail to reach the root filesystem when its initramfs or module tree belongs to another release. When investigating a custom or upgraded kernel, compare the whole set rather than checking only /boot/vmlinuz-*.

Identify the Running Kernel

uname -r
uname -m
uname -a
cat /proc/version

uname -r is especially important because module directories are normally version-specific under /lib/modules/<release>/.

Kernel Image and Modules

The bootloader loads a kernel image from /boot. Common names include vmlinuz-<release>. Historically, zImage and bzImage describe compressed bootable kernel image formats; bzImage does not mean bzip2 compression.

Loadable modules add drivers or features after the kernel starts:

find /lib/modules/"$(uname -r)" -type f | head
lsmod
modinfo <module>

Built-in features are part of the kernel image and do not appear as removable modules.

Module behavior can also be changed by files under /etc/modprobe.d/. These files can define aliases, options, soft dependencies, or blacklists without changing the module binary.

Source Tree Layout

Kernel source is commonly unpacked under /usr/src/, often with a /usr/src/linux link.

Important locations include:

  • Documentation/ for subsystem documentation
  • drivers/ for device drivers
  • fs/ for filesystem code
  • net/ for networking
  • arch/ for architecture-specific code
  • Makefile for version and build behavior
  • .config for selected build options

Modern distributions may install only headers needed to build external modules rather than a complete source tree.

Release Families

Useful distinctions:

  • mainline: current development release line
  • stable: fixes applied to a released kernel
  • longterm: selected releases maintained for an extended period
  • distribution kernel: upstream code plus packaging and distribution patches

Administrators should use the kernel supported by their distribution unless a tested requirement justifies another build.

Configuration Choices

A kernel feature can be configured as:

  • built in, represented by =y
  • a module, represented by =m
  • disabled, represented by is not set
grep '^CONFIG_EXT4_FS=' /boot/config-"$(uname -r)"

Boot-critical storage and filesystem support must be built into the kernel or available in the initramfs.

Compression and Patches

Kernel source archives and images may use gzip, bzip2, xz, or other compression. A patch records changes between source versions and is commonly applied with patch or managed through version control.

Before changing a production kernel, preserve the old image, modules, initramfs, and boot menu entry so the system remains recoverable.

Guided Practice: Inventory the Running Kernel

Run the following read-only commands:

release="$(uname -r)"
printf 'Running release: %s\n' "$release"
ls -l /boot | grep "$release"
ls -ld "/lib/modules/$release"
test -r "/boot/config-$release" && grep '^CONFIG_EXT4_FS=' "/boot/config-$release"
find "/lib/modules/$release" -type f -name '*.ko*' | head

Then choose one loaded module and trace it:

lsmod | head
modinfo <module>
modinfo -n <module>

Verify that the reported module path sits below the running release directory. In modinfo, identify the license, aliases, dependencies, and accepted parameters. If the feature is built into the kernel instead, explain why it does not appear in lsmod.

Troubleshooting Scenario

After copying a new kernel image into /boot, the system reports that a storage module cannot be found. The running release is 6.x-custom, but only /lib/modules/6.x-old/ exists.

The image and module tree do not match. Boot the known-good entry, install the new release's modules, run depmod, rebuild its initramfs, and verify the boot entry before trying again. Renaming the old module directory would not create compatible modules.

Exam Focus

  • zImage and bzImage are boot image formats; bzImage does not mean bzip2.
  • /usr/src/linux/Documentation/ explains kernel subsystems and parameters.
  • /boot, /lib/modules/<release>, and /usr/src/linux have different roles.
  • Stable, longterm, and distribution kernels describe maintenance models, not configuration options.

Recap

  • The kernel image starts the core operating system; modules extend it at runtime.
  • Kernel release and module directory must match.
  • /usr/src/linux, /boot, and /lib/modules answer different administrative questions.
  • Keep a known-good kernel available whenever testing a new one.
🎯

Test Your Knowledge

Complete the quiz to assess your understanding of this course's concepts.