4.3.5 Kernel versioning and updates

Understanding Kernel Version Numbers

Linux kernel versions follow a structured format that encodes both technical and stability information. For administrative work you must be able to read these numbers and understand what they imply about features, stability, and support.

On most systems you can see the currently running kernel with:

uname -r

The output usually looks like:

6.6.12-300.fc39.x86_64

The important part for versioning is the numeric core, such as 6.6.12. This usually follows the pattern:

$$\text{major}.\text{minor}.\text{patch}$$

For example, in 6.6.12:

• 6 is the major version.
• 6 is the minor version.
• 12 is the patch level.

Other examples:

• 5.15.0 represents major 5, minor 15, patch 0.
• 4.19.289 represents major 4, minor 19, patch 289.

The numbers outside this core, often added by distributions, encode distribution specific information. For instance, in 6.6.12-300.fc39.x86_64:

• -300 is a distribution build or release number.
• fc39 indicates Fedora 39.
• x86_64 indicates the architecture.

Some distributions compress this extra information differently, but all follow the idea that the part before the first - is the upstream kernel version, and the part after is distribution specific.

Stable, Long Term, and Distribution Kernels

Although the version format looks similar, not all kernels have the same support model.

Upstream kernels, maintained by the mainline Linux project, are roughly divided into:

• Mainline kernels. These are the newest development releases. They receive rapid updates and are useful for testing and new hardware, but distributions rarely ship them as default for production servers.
• Stable kernels. When a mainline series stabilizes, it may receive bug fix only releases as a stable branch. For example, 6.6.12 is a stable release in the 6.6 series.
• Long Term Support (LTS) kernels. Certain versions are selected for extended maintenance, often for several years. For example, 5.15 and 6.1 have been long term support lines. Within an LTS line, the minor number is fixed and only the patch level increases.

Distributions then choose how to consume these upstream releases. Some key patterns are:

• Enterprise and server focused distributions often track a specific upstream LTS line and backport fixes heavily. The visible version may be close to upstream, but the code often contains additional patches. For example, a 5.14.0 kernel in an enterprise system may carry backported features and security fixes that are newer than the apparent version suggests.
• Desktop focused or short cycle distributions may track more recent upstream lines and update to new minor versions within a release cycle.
• Rolling release distributions update kernel versions frequently and usually follow recent stable branches.

Because of these differences, you cannot always infer support duration from the version alone. You must also consider the distribution policy.

Kernel Version and Compatibility

Kernel version affects several aspects of system compatibility.

Hardware support is directly linked to kernel versions. New drivers and device support are added in new kernels, so very new hardware may only work properly with newer kernel releases. Conversely, very old proprietary drivers may only support older kernel versions.

Userspace compatibility is typically maintained across kernel updates. The kernel is designed to keep interfaces for user programs stable, so normal applications continue to work across many versions. The more sensitive area is out of tree kernel modules and kernel dependent tools.

Kernel modules that are not part of the distribution package set, such as vendor provided modules or proprietary graphics drivers, often depend closely on specific kernel interfaces. When the kernel version changes, these modules may need to be rebuilt or updated. This is one principal reason why some systems delay kernel updates on critical machines or test them first.

Kernel Application Binary Interface stability is a matter of policy only within a given distribution. Upstream makes no guarantee for third party binary modules. Distributions often provide tools that rebuild modules automatically when the kernel updates, but this only works if appropriate source code and build systems are available.

Discovering Kernel Information on Your System

The running kernel version and related information can be obtained from several commands. The current kernel is reported by uname:

uname -r
uname -a

The first prints the release string, while the second adds build time and other details. On many systems you can list installed kernel packages through the distribution package manager.

For example, on a Debian based system:

dpkg -l | grep linux-image

On an RPM based system:

rpm -qa | grep '^kernel'

On an Arch based system you may inspect:

pacman -Q linux

These commands expose both the installed packages and often multiple kernel versions present on disk, even if only one is currently running.

General Approaches to Kernel Updates

Kernel updates are typically delivered through the distribution package management system. While the exact commands differ, the process follows similar principles.

A kernel update normally consists of installing a new kernel package, not overwriting the existing one. The bootloader configuration is updated so that the new kernel appears as the default entry. When you reboot the system, the new kernel is loaded.

Most distributions keep at least one older kernel installed alongside the latest one. This allows you to choose an older kernel from the bootloader menu if the new one fails to boot or shows regressions.

The update process usually includes:

1. Downloading the updated kernel package and associated modules.
2. Installing the package and placing the kernel image and initramfs into /boot.
3. Regenerating the bootloader configuration.
4. Leaving the current running session untouched until the next reboot.

Because the kernel is central to system operation, updating it without planning can affect uptime and service availability.

Distribution Specific Kernel Updating Patterns

While you will use distribution specific tools elsewhere in the course, kernel updates have a few peculiarities that are worth noting here at a high level.

In systems that use APT, such as Debian or Ubuntu, kernel updates arrive as standard package upgrades, usually with package names like linux-image-<version> and linux-headers-<version>. Meta packages such as linux-image-generic ensure that you automatically receive the latest supported kernel for your release. If you install a kernel by exact version, you may stop getting automatic major updates and only receive security fixes for the branch you selected.

In RPM based systems such as Fedora, CentOS Stream, or RHEL, kernels are packages simply called kernel or similar variants. Updates generally install new kernel packages side by side and mark the new one as default. There is often a limit on how many old kernels are retained, controlled by configuration.

In Arch Linux and similar rolling environments, the kernel is usually tracked as a single package name like linux. Updates replace the old version with the new one, but the previous kernel is typically not kept installed separately. Because of the rolling nature, arch based systems may receive kernel version changes more frequently.

In all cases, the key practice is to understand whether your distribution keeps old kernels and how many, and where the bootloader configuration is stored. This affects your ability to recover if a new kernel is faulty.

Handling Multiple Installed Kernels

It is common for a system to have several kernel versions installed. Each one has its own kernel image and modules directory. The running kernel is not automatically removed when a new one is installed.

The bootloader, commonly GRUB, presents entries for each installed kernel. The default entry is chosen according to its configuration. You can usually interrupt the boot process and choose an older kernel if you suspect a regression.

Over time, many old kernels can accumulate on disk. On systems with small /boot partitions, this may cause space exhaustion and prevent new kernel installations. Distributions therefore provide ways to limit the number of kernels kept.

For example, configuration options may state that only the last two or three kernels should be kept, older ones being removed during package cleanup. If this is not configured, you may need to manually remove obsolete kernel packages through the package manager, always leaving at least one known good kernel in addition to the current one.

Deciding When to Update the Kernel

Kernel updates include several types of changes. Security fixes and serious bug fixes are the most critical. Feature updates and new hardware support are less urgent on stable production machines but can be attractive on desktops or test systems.

In practice, systems follow different kernel update strategies:

• Security oriented updates only, where administrators apply new kernels primarily in response to security advisories.
• Regular scheduled updates, where kernels are updated together with other system packages at planned intervals.
• Aggressive tracking of new versions, common on development machines or on rolling release distributions.

Each strategy carries tradeoffs between stability and immediate access to new features. On long lived servers the usual approach is to trust the distribution maintainers to backport important fixes to a stable kernel line and apply those updates according to security policy.

In contrast, if you need new hardware support or specific new kernel capabilities, you might deliberately move to a newer kernel line, or use an additional repository that provides such kernels.

Special Kernel Builds and Alternate Branches

Besides the default kernel provided by a distribution, there are often additional branches with special properties. Examples include low latency kernels, real time kernels, and kernels optimized for specific hardware roles.

These special kernels are usually packaged separately, often with package names that reflect their purpose. For example, a low latency kernel may have a suffix like -lowlatency or -rt. The versioning scheme inside these packages still follows the same major.minor.patch pattern, but you must pay attention to their maintenance and support status.

Using alternate kernels can provide benefits for certain workloads, but they may also lag in updates or have stricter compatibility requirements for drivers and modules. Consider support windows and update habits before deploying them in critical environments.

Rolling Back to an Older Kernel

If a kernel update causes a problem, one of the most important recovery skills is to revert to an older kernel.

Rollback usually involves two steps:

1. At boot time, manually choose an older kernel from the bootloader menu. This lets you confirm that the system still operates correctly with a previously working version.
2. Once booted into the known good kernel, adjust your package selection or kernel packages so that the problematic kernel is no longer used as default. This may involve removing the new kernel package or changing which meta packages are installed.

Some high availability setups or advanced boot managers support more complex rollback mechanisms, but at the basic level, kernel rollback depends on having multiple versions installed and being able to select one at boot.

Summary of Key Versioning Concepts

Kernel version numbers encode both upstream development state and distribution integration. The upstream sequence follows a regular major.minor.patch format, and certain versions are maintained as long term support branches. Distributions package these kernels with additional suffixes and policies for update cadence and backports.

Understanding which upstream series your system tracks, how your distribution manages multiple installed kernels, and how third party modules relate to specific versions are central skills when dealing with kernel versioning and updates.