4.3 Kernel Management

Overview

Kernel management covers how you interact with, inspect, update, and customize the Linux kernel on a running system. In this chapter you will:

• Discover what kernel version you are running and what that implies.
• Learn how kernels are packaged and updated by distributions.
• Understand how to select and manage multiple installed kernels.
• Get an overview of kernel configuration and tuning without recompiling.
• See how kernel crashes and regressions are handled from a system administrator’s point of view.

Details about “what the kernel is” and “kernel modules” are handled by their own sections; here we focus on managing kernels as a whole in a real system.

Identifying the Running Kernel

Most kernel management tasks start by determining what you are currently running.

Checking kernel version

The primary tool:

uname -r

Typical output:

6.8.0-47-generic

This string usually includes:

• Version: 6.8.0
• Patch / build: -47
• Flavor: -generic, -rt, -cloud, etc. (distribution‑specific)

Other useful variants:

uname -a        # full kernel + architecture + hostname info
uname -v        # kernel build date and build string

You can also see the kernel version in /proc/version:

cat /proc/version

Mapping version to distribution kernel packages

Distributions ship the kernel as normal packages. Common patterns:

• Debian/Ubuntu: linux-image-6.8.0-47-generic, linux-image-generic
• Fedora/RHEL: kernel, kernel-core, kernel-debug
• Arch: linux, linux-lts, linux-zen, linux-hardened
• openSUSE: kernel-default, kernel-vanilla, kernel-desktop

To find installed kernel packages:

# Debian/Ubuntu
dpkg -l | grep linux-image
# RHEL/Fedora
rpm -qa | grep '^kernel'
# Arch
pacman -Qs '^linux'
# openSUSE
rpm -qa | grep '^kernel'

Kernel Release Types and Flavors

Distributions often provide multiple kernel “tracks” and flavors. Choosing the right one is part of kernel management.

Stable, LTS, and distribution kernels

Upstream kernels (from kernel.org) have:

• Mainline / stable: latest features, frequent releases.
• LTS (Long-Term Support): maintained for years, focuses on stability and security.
• End‑of‑life: no longer maintained.

Distributions usually:

• Track a single major kernel series per release (e.g. Ubuntu 22.04 → 5.15+HWE).
• Backport security fixes instead of following mainline directly.
• Offer LTS kernels (linux-lts in Arch, kernel-lts in some SUSE products).

Kernel flavors

You may see multiple flavors on the same distribution:

• generic, default, desktop: general purpose.
• server: tuned for server workloads.
• lowlatency, rt: low‑latency or real‑time for audio/telecom.
• cloud: optimized for virtualized/cloud environments.
• hardened: additional security hardening (often with performance cost).

Choosing flavors:

• Use generic/default unless you have a specific workload.
• Consider LTS for stability‑critical production servers.
• Use hardened or rt only when you understand the trade‑offs.

Kernel Updates and Package Management

Kernels are updated through your distribution’s package manager, not by overwriting files manually.

How kernel updates are delivered

On most systems, regular system updates also pull in kernel updates:

# Debian/Ubuntu
sudo apt update
sudo apt full-upgrade
# Fedora
sudo dnf upgrade
# Arch
sudo pacman -Syu

What happens during a kernel update:

• New kernel image and modules installed (usually alongside older versions).
• Bootloader (GRUB or other) configuration regenerated.
• The currently running kernel does not change until you reboot.
• Old kernels may be pruned automatically or kept for fallback.

You can see both current and installed kernels:

uname -r            # currently running
# and then:
dpkg -l | grep linux-image   # or rpm/pacman as above

Security updates and reboot planning

Security advisories often include kernel vulnerabilities. Kernel management therefore includes:

• Tracking updates: via distro tools (unattended-upgrades, dnf-automatic, etc.) or mailing lists.
• Planning reboots: especially in servers and production environments.

For desktops you usually:

• Accept kernel updates during routine system updates.
• Reboot at a convenient time.

For servers you might:

• Schedule maintenance windows for reboots.
• Use live patching solutions when available (see below).

Live patching (no‑reboot kernel security updates)

Some distributions and vendors provide live patching:

• Ubuntu: canonical-livepatch
• RHEL / derivatives: kpatch, ksplice (Oracle)
• SUSE: kgraft (integrated into kGraft/SUSE Live Patching)

Characteristics:

• Critical security fixes are applied to the running kernel.
• Reduces or defers the need for immediate reboots.
• Usually does not replace normal kernel updates; you still update and reboot occasionally.

Usage is vendor‑specific, but management tasks typically include:

• Enabling the live patching service.
• Monitoring patch status.
• Ensuring compatibility with your kernel version.

Managing Multiple Kernels

Many distributions keep several kernel versions installed so you can fall back if a new kernel breaks something.

Listing installed kernels

Use package manager queries:

# Debian/Ubuntu
dpkg -l | grep linux-image
# Fedora/RHEL
rpm -qa | grep '^kernel'
# Arch
pacman -Q | grep '^linux'

On some systems, kernels are also visible in /boot:

ls /boot/vmlinuz*
ls /boot/initrd*

Selecting a kernel at boot

Kernel selection is typically done by the bootloader.

With GRUB2, you often have:

• A default kernel that boots automatically.
• A GRUB menu where you can manually choose kernels.

To enable the GRUB menu on systems where it’s hidden:

sudo nano /etc/default/grub

Look for:

• GRUB_TIMEOUT_STYLE=hidden or menu
• GRUB_TIMEOUT=0 (immediate boot) vs a positive number

Example to show the menu for 5 seconds:

GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=5

Then regenerate GRUB config:

# Debian/Ubuntu
sudo update-grub
# RHEL/Fedora (BIOS)
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
# RHEL/Fedora (UEFI)
sudo grub2-mkconfig -o /boot/efi/EFI/<distro>/grub.cfg

On the GRUB menu, there is usually an entry like “Advanced options for …” that lists available kernels.

Permanently setting the default kernel

Instead of choosing manually each boot, you can set a persistent default.

Using GRUB’s saved default

1. Enable saved default in /etc/default/grub:

   GRUB_DEFAULT=saved
   GRUB_SAVEDEFAULT=true

2. Regenerate GRUB configuration (see above).
3. After booting with GRUB, use:

   sudo grub-set-default 'Advanced options for Ubuntu>Ubuntu, with Linux 6.8.0-47-generic'

The entry name must match what appears in /boot/grub/grub.cfg. On RHEL/Fedora:

   sudo grub2-set-default 1    # index starting from 0

Using distribution tools

Some distributions provide wrapper tools, e.g.:

• RHEL: sudo grubby --default-kernel
• openSUSE: YaST bootloader module.

These can set default kernels without editing GRUB config manually.

Removing Old Kernels Safely

Kernel management includes cleanup to free disk space (particularly /boot).

When to remove old kernels

Safe practice:

• Always keep at least one known‑good older kernel besides the current one.
• Avoid deleting the kernel you are currently running (uname -r).

Scenarios for cleanup:

• /boot partition is small and full.
• Package manager complains about insufficient space for new kernels.
• You have many obsolete kernel images.

Removing kernels with package manager

# Debian/Ubuntu: removing one specific kernel
sudo apt remove linux-image-6.8.0-25-generic
# RHEL/Fedora
sudo dnf remove kernel-6.7.10-200.fc40.x86_64
# Arch: you normally have only one or few variants (linux, linux-lts)
sudo pacman -R linux          # be careful; ensure another kernel is installed
# openSUSE/RPM-based
sudo zypper remove kernel-default-6.6.0-1.1

Many distributions also have automation:

• Ubuntu: sudo apt autoremove removes old kernels that are no longer the latest.
• Fedora: installonly_limit in /etc/dnf/dnf.conf controls how many kernels to keep, e.g.:

  installonly_limit=3

After removal, regenerate GRUB if required (some tools do this automatically).

Avoiding a broken system

To stay safe:

1. Verify at least two kernels remain installed.
2. Never delete linux-image-generic / kernel-core meta‑packages that track current kernel lines unless you know what you’re doing.
3. Ensure your /boot partition has enough free space for at least:
• One new kernel image.
• Its initramfs / initrd.

Check space:

df -h /boot

Kernel Configuration and Parameters (High-Level View)

Deep details of kernel parameters and boot process are covered in their own chapters; here we focus on how kernel management interacts with them.

Boot-time parameters vs runtime tuning

Kernel behavior can be adjusted by:

• Boot-time parameters: passed via the bootloader (GRUB_CMDLINE_LINUX).
• Runtime interfaces: mainly /proc/sys and /sys, often via sysctl.

Kernel management often includes:

• Ensuring specific parameters are always applied on boot.
• Coordinating changes across multiple kernels.

Boot parameters via GRUB

Edit /etc/default/grub and modify:

GRUB_CMDLINE_LINUX="quiet splash"

Examples of added parameters:

• ipv6.disable=1
• audit=1
• apparmor=1 security=apparmor

Then regenerate GRUB config. These apply to all kernels booted via that configuration.

Runtime settings via sysctl

Use sysctl to set or query:

sysctl -a                        # list all
sysctl net.ipv4.ip_forward       # show specific
sudo sysctl -w net.ipv4.ip_forward=1

Persistent settings go in /etc/sysctl.conf or /etc/sysctl.d/*.conf. Note:

• These settings are applied after boot, regardless of which kernel version you choose.
• Some keys may be present/absent depending on kernel configuration.

Distribution-Specific Kernel Management Tools

Some distributions provide extra tools targeted at kernel management.

Debian/Ubuntu

• linux-image-* packages: specific kernel versions.
• Meta-packages like linux-image-generic, linux-image-lowlatency:
• Ensure you always get updates for that flavor.
• Removing them may stop automatic kernel tracking.

Useful commands:

apt-cache search linux-image
apt policy linux-image-generic

You can “pin” or hold a kernel if necessary:

sudo apt-mark hold linux-image-6.8.0-47-generic

RHEL / Fedora

• kernel, kernel-core, kernel-modules: core packages.
• Tools:
• grubby: manage default kernel and boot entries.
• dracut: regenerate initramfs if needed.

Examples:

# Show current default kernel
sudo grubby --default-kernel
# Set default to currently running kernel
sudo grubby --set-default /boot/vmlinuz-$(uname -r)

Arch Linux

Arch uses a rolling model; kernel updates come frequently:

• Main packages: linux, linux-lts, linux-zen, linux-hardened.
• Always ensure mkinitcpio and bootloader entries are consistent.

Changing from linux to linux-lts:

sudo pacman -S linux-lts
# Then configure bootloader to use linux-lts kernel as default

openSUSE

• Packages: kernel-default, kernel-desktop, etc.
• zypper manages kernels; YaST has a Boot Loader module.

Configuration like number of kernels to keep is often controlled via /etc/zypp/zypp.conf (look for multiversion options).

Handling Kernel Problems and Rollbacks

A core part of kernel management is being prepared for regressions: new kernels that introduce bugs or unwanted changes.

Symptoms of kernel regressions

Typical signs:

• System fails to boot or hangs soon after boot.
• Hardware suddenly unsupported (e.g. Wi‑Fi, GPU, storage).
• Performance drops drastically.
• New kernel panics (crashes) under load.

Basic rollback strategy

1. On boot, in GRUB, select Advanced options and choose an older kernel.
2. If the older kernel is stable:
• Boot into it.
• Remove or downgrade the problematic kernel package.
• Consider pinning/holding the stable version for a while.
3. Optionally, report the regression to your distribution with:
• Precise kernel version.
• Hardware details (lspci, lsusb).
• Logs (journalctl -k).

Collecting diagnostic information

When managing kernels, you should be able to gather kernel logs:

# View messages from the current boot
journalctl -k
# View messages from previous boots
journalctl -k -b -1
journalctl -k -b -2

For crashes:

• Kernel oops / panic messages appear in these logs.
• For frequent issues, consider enabling a serial console or netconsole so you can capture logs even when the system locks.

Note: full crash dump management (kexec/kdump) belongs in more advanced administration topics, but you should know that:

• A configured dump system lets you preserve memory state after a crash.
• It is often required in enterprise environments.

Building and Using Custom Kernels (High-Level)

The dedicated “Compiling a custom kernel” section handles details of building; from a management perspective you should know:

Risks and responsibilities

Using custom kernels means:

• You are responsible for applying security updates to your kernel.
• Distribution vendor support may not cover your kernel.
• Kernel interfaces and ABI for modules may change unexpectedly.

This approach is usually reserved for:

• Specialized hardware or experimental features.
• Kernel development and testing.
• Very specific performance or security requirements.

Coexisting with distribution kernels

A common practice:

• Keep the distribution kernel installed as a fallback.
• Install your custom kernel with a unique name and version string.
• Create a separate GRUB entry.

This way you can:

• Test the custom kernel.
• Always have a stable distro kernel to boot if something fails.

Kernel Versioning and Compatibility Considerations

The detailed semantics of kernel versioning are handled elsewhere, but for management purposes:

Recognizing compatibility issues

When managing kernels, you must watch compatibility with:

• Out‑of‑tree modules (e.g. proprietary GPU drivers).
• Virtualization tools (KVM, Docker/Podman, etc.).
• Security tools (SELinux/AppArmor policies may tie to kernel features).

After a kernel update:

• Rebuild any out‑of‑tree modules (often handled automatically by DKMS).
• Verify that virtualization and containerization setups still work.
• Check logs (journalctl -k) for failures during module loading.

DKMS and automatic module rebuilding

Many distributions use DKMS (Dynamic Kernel Module Support) to rebuild third‑party modules on new kernels:

• DKMS hooks are triggered when new kernels are installed.
• Modules are compiled and placed under /lib/modules/<version>/.

To list DKMS modules:

dkms status

If a module fails to build for a new kernel, you might:

• Stay on a previous kernel until it is fixed.
• Temporarily remove or disable the module.

Summary

Kernel management on Linux involves much more than just knowing the version. In practice you will:

• Track and apply kernel updates through your distribution.
• Manage multiple installed kernels and bootloader configuration.
• Keep at least one fallback kernel available.
• Adjust kernel behavior via boot parameters and runtime settings.
• Plan reboots and, when available, use live patching for critical systems.
• Roll back quickly when regressions appear, and collect useful diagnostics.

These skills let you treat the kernel as a controlled, upgradable component of your system rather than a mysterious black box.