4.3.5 Kernel versioning and updates

Understanding Linux Kernel Version Numbers

Linux kernel versions follow a structured scheme that encodes stability, patch level, and sometimes distribution-specific information.

A modern kernel version string often looks like:

• 6.8.12
• 5.15.149
• 6.1.0-13-amd64
• 6.6.10-arch1-1
• 5.14.0-503.el9.x86_64

Let’s break these apart.

Mainline version triplet: X.Y.Z

The mainline kernel version is:

$$X.Y.Z$$

• X — Major version
• In practice, this changes rarely (e.g. from 5 to 6).
• Indicates big shifts in development lifetime and broad feature sets.
• Y — Minor version
• Increments with each new mainline release.
• 6.8, 6.9, 6.10 etc. are successive mainline versions.
• Z — Patch level
• Increments for stable updates to an already-released branch.
• 6.8.1, 6.8.2, 6.8.12 are successive stable patch releases to 6.8.

In plain terms:

• 6.8 → first stable release for the 6.8 series
• 6.8.12 → the 12th stable bugfix/security patch on top of 6.8

Distribution-specific suffixes

Distributions add their own suffixes to the upstream version:

• 6.1.0-13-amd64 (Debian)
• 6.1.0 → upstream major.minor.patch (Debian often uses 0 here)
• -13 → Debian's kernel package revision
• -amd64 → architecture
• 5.15.0-94-generic (Ubuntu)
• 5.15.0 → upstream base
• -94 → Ubuntu package revision/build
• -generic → flavour/type (e.g. generic, lowlatency, cloud)
• 6.6.10-arch1-1 (Arch Linux)
• 6.6.10 → upstream base
• -arch1 → Arch’s kernel package revision for that upstream release
• -1 → repo/package release number
• 5.14.0-503.el9.x86_64 (RHEL / CentOS / Alma / Rocky)
• 5.14.0 → upstream base
• -503 → Red Hat’s build number for their long-term branch
• .el9 → Enterprise Linux 9
• .x86_64 → architecture

Key point: the first three numbers indicate compatibility with upstream; the rest describe packaging, patches, and build details specific to the distribution.

Long-Term Support (LTS) vs non-LTS kernels

Not all kernel branches are maintained equally long.

• Mainline:
• The current development series (e.g. 6.11-rc1, 6.11-rc2…).
• Not what you usually run in production.
• Stable:
• Each mainline release becomes X.Y.0, then gets bugfixes as X.Y.1, X.Y.2, etc., for a relatively short period.
• Long-Term Support (LTS):
• Some versions are designated LTS (e.g. 5.4, 5.10, 5.15, 6.1).
• They receive bug and security fixes for many years.
• Very common for distributions and long-lived products.

The current and historical LTS kernels are listed on:

• https://www.kernel.org

Your distribution may further extend support for a chosen kernel version (e.g. RHEL backporting many years of fixes to 5.14), so the effective support lifetime can be even longer than upstream LTS.

Checking Your Current Kernel Version

You often need to know:

• Which kernel version you're running now.
• Whether it matches what’s installed.
• Whether a newer kernel is available.

Basic version check

Use:

uname -r

This prints the running kernel release (including distribution suffix).

To see full information:

uname -a

This includes:

• Kernel name (Linux)
• Node (hostname)
• Kernel release (version-string)
• Kernel build date
• Architecture (x86_64, armv7l, etc.)

Listing all installed kernels (distribution-specific)

Different distributions manage kernel packages differently. Commands below are read-only inspections; they don’t change anything.

Debian / Ubuntu and derivatives

dpkg --list | grep -E 'linux-image|linux-headers'

You’ll see lines like:

ii  linux-image-5.15.0-94-generic  ...
ii  linux-image-6.8.0-36-generic   ...

The one from uname -r is the currently running kernel. Others are installed but unused until you boot them.

Fedora / RHEL / CentOS / Alma / Rocky

rpm -qa | grep '^kernel'

Example entries:

kernel-5.14.0-503.el9.x86_64
kernel-5.14.0-427.el9.x86_64

The kernel-core / kernel-modules packages follow similar names.

Arch Linux / Manjaro (pacman-based)

pacman -Qs '^linux[0-9]*'

Or for installed packages:

pacman -Q | grep '^linux'

You may see:

linux 6.6.10.arch1-1
linux-lts 6.1.78-1

Again, the one from uname -r is the running kernel; others may be installed as alternates.

Sources of Kernel Updates

Where updates come from depends on how you maintain your system.

1. Distribution-managed kernel (most common)

This is the normal and recommended approach:

• You install the kernel via your distribution’s package manager.
• Updates arrive as part of the normal system update process.
• The distribution handles:
• Security backports
• Compatibility with drivers and modules
• Integration with the bootloader and initramfs

Different distributions use different update policies:

• Rolling (Arch, openSUSE Tumbleweed): newer mainline-ish kernels quickly.
• Semi-rolling (Fedora): relatively fresh kernels with moderate delay.
• Stable (Debian stable, Ubuntu LTS, RHEL/Alma/Rocky): select a long-term branch and backport fixes.

2. Vendor / hardware-specific kernels

Some vendors maintain their own kernel packages with custom patches, e.g.:

• Cloud provider kernels (AWS, GCP, Azure).
• Hardware OEM kernels (e.g. for particular laptops, embedded systems).
• Real-time (PREEMPT_RT) or low-latency kernels.

These are also usually delivered as packages but from specific repositories or images.

3. Mainline or self-compiled kernels

If you need very new features or particular patch sets, you may:

• Use “mainline” kernels provided by a project (e.g. Ubuntu mainline builds).
• Build your own kernel from source (covered in the “Compiling a custom kernel” chapter).

Using these shifts more responsibility to you for:

• Compatibility
• Security tracking
• Update procedures

Updating the Kernel via Package Manager

The precise commands differ by distribution, but the concepts are similar:

• Install new kernel packages
• Leave old kernels for fallback (until you decide to remove them)
• Ensure bootloader config is updated

Debian / Ubuntu and derivatives

Updating the kernel is usually part of a system-wide upgrade:

sudo apt update
sudo apt full-upgrade

Notes:

• apt upgrade installs updates but typically avoids removing packages.
• apt full-upgrade allows installing new kernel versions and removing old transitional packages when needed.
• The kernel package names are usually meta-packages (e.g. linux-image-generic), which automatically track the latest kernel for that series.

To explicitly see which kernel image packages are available:

apt list --upgradable | grep linux-image

Reboot after the update to start using the new kernel:

sudo reboot

Fedora / RHEL / CentOS / Alma / Rocky

Use:

sudo dnf upgrade

On RHEL-like systems:

• New kernels are usually installed side-by-side.
• Old ones remain in the bootloader menu for fallback.

To see the currently installed kernel packages:

rpm -qa | grep '^kernel'

Reboot to use the new version:

sudo reboot

Arch Linux / Manjaro (pacman-based)

On Arch:

sudo pacman -Syu

This:

• Synchronizes package databases
• Upgrades all packages, including the kernel

On Manjaro, similar commands (or GUI tools) are used, but kernel management can also be done via mhwd-kernel.

Reboot afterward:

sudo reboot

openSUSE (zypper)

sudo zypper refresh
sudo zypper update

or to be explicit:

sudo zypper update kernel-default

Again, reboot to take effect.

Multiple Kernels and Bootloader Selection

Running multiple kernels in parallel is common and often desirable for safety.

Why keep older kernels?

Reasons to keep at least one older kernel:

• The new kernel may have:
• A regression affecting your hardware.
• Compatibility problems with proprietary drivers (e.g. NVIDIA).
• Bugs that break workloads you rely on.

Keeping an old kernel gives you a quick rollback:

• At boot, choose the older kernel from the GRUB (or other bootloader) menu.
• Once you confirm stability, you can decide to remove older kernels.

Choosing a kernel at boot (GRUB example)

If your distribution uses GRUB2:

1. On reboot, at the GRUB menu:
• Press Esc or Shift (depending on distro/firmware) if the menu is hidden.
2. Select “Advanced options for …”.
3. Choose the entry with the kernel version you want to boot.

The exact menu wording varies by distribution, but “Advanced options” or “Previous Linux versions” is typical.

Listing available boot entries

You can inspect GRUB’s generated config:

grep -E "menuentry 'Advanced" -n /boot/grub*/grub.cfg
grep -E "menuentry '.*Linux" -n /boot/grub*/grub.cfg

Don’t edit these autogenerated files manually; use distribution tools to change the default kernel.

Kernel Update Strategies

How aggressively you update your kernel depends on your environment.

Desktop / personal systems

Typical strategies:

• Stay with distribution defaults:
• Run apt full-upgrade, dnf upgrade, or pacman -Syu regularly.
• Accept new kernels as they come.
• Keep at least one older kernel installed:
• Avoid removing the previous kernel until you're sure the new one works well.
• Balance new features vs stability:
• On rolling distros, kernels are fairly fresh. Consider extra caution if you rely on proprietary GPU drivers or unusual hardware.

Servers / production systems

More conservative strategies:

• Stick to LTS or vendor-supported kernels.
• Avoid frequent version jumps unless:
• Security issues demand it, or
• Specific features/fixes are required.
• Test new kernels in:
• A staging environment.
• At least a non-critical instance.
• Schedule kernel updates during maintenance windows with:
• Change plans
• Rollback options (older kernels preserved, backups in place)

Real-time and specialized kernels

Some workloads (low-latency, telecom, certain industrial control) use:

• PREEMPT_RT kernels
• Vendor-patched kernels
• Special hardened kernels

Update strategy there is often:

• Extremely conservative
• Testing-heavy
• Possibly incorporating specific patch sets instead of general upgrades

Safely Removing Old Kernels

Over time, multiple older kernels can accumulate and use disk space, especially in /boot.

General principles:

• Always keep:
• The current running kernel, and
• At least one known-good older kernel.
• Never remove the kernel you are currently running (indicated by uname -r).

Specific commands are distribution-dependent.

Debian / Ubuntu

To see installed image packages:

dpkg --list | grep linux-image

To remove a specific old kernel (example):

sudo apt remove linux-image-5.15.0-94-generic

Or use helper tools (where available):

• sudo apt autoremove can remove unused, older kernels that are no longer depended upon by meta-packages.
• Some derivatives provide tools like purge-old-kernels (in byobu on some systems):

  sudo purge-old-kernels

Use with caution; always ensure at least one fallback remains.

Fedora / RHEL / CentOS / Alma / Rocky

List kernels:

rpm -qa | grep '^kernel'

Remove a specific old version:

sudo dnf remove kernel-5.14.0-427.el9.x86_64

RHEL-based systems may have a configuration option for installonly_limit in /etc/dnf/dnf.conf or /etc/yum.conf which controls how many old kernels to keep automatically.

Example:

installonly_limit=3

Arch Linux

Arch typically keeps only the current kernel for each kernel package you install (linux, linux-lts, etc.), so kernel accumulation is less of an issue. Removing an entire kernel variant:

sudo pacman -Rns linux-lts

Again, don’t remove the kernel package you are currently running unless you have another installed and configured.

Advanced: Tracking Kernel Updates and Security

For security-conscious environments, you need to know when a kernel needs updating, particularly for:

• Critical vulnerabilities (e.g. privilege escalations, remote code execution).
• High-profile flaws (Spectre, Meltdown, L1TF, etc).

Common practices:

• Subscribe to security advisories for your distribution:
• Debian security-announce
• Ubuntu security notices
• Red Hat errata
• Arch Linux security mailing lists or RSS
• Monitor:
• CVEs affecting the kernel.
• Vendor bulletins (cloud providers, hardware vendors).

Many Linux distributions also tag kernel updates clearly as security-related in package changelogs.

Example (Debian/Ubuntu):

apt changelog linux-image-$(uname -r)

This shows what changed between package versions (including security fixes).

When to Consider a Kernel Upgrade vs Full OS Upgrade

You’re sometimes faced with a choice:

• Upgrade just the kernel within your current distribution version.
• Upgrade the entire distribution.

Factors:

• If your distro is still supported:
• Kernel updates via the normal package manager are safest.
• Distribution maintainers backport security fixes, so you stay secure without chasing major kernel versions.
• If your distro is nearing end-of-life:
• You may get stuck on an older kernel with no security patches.
• At that point, a full OS upgrade is usually better than forcing a newer kernel into an old userland.
• If you need a specific hardware feature or bug fix that’s only in newer kernels:
• Check if your distro has:
• “HWE” (Hardware Enablement) kernels (Ubuntu).
• Backported kernels in special repos.
• Only as a last resort, consider a mainline or self-compiled kernel and accept the added maintenance overhead.

Summary

• Kernel versions follow a structured pattern (X.Y.Z plus distribution suffixes).
• LTS kernels receive long-term maintenance; distributions may extend support further.
• Use your distribution’s package manager to install kernel updates; reboot to activate them.
• Keep multiple kernels installed to allow easy rollback via the bootloader.
• Remove old kernels cautiously, ensuring the current and at least one fallback remain.
• Choose an update strategy (aggressive vs conservative) appropriate to your environment, and pay attention to security advisories for critical kernel updates.