Kernel versions, releases, and lifecycle · Linux

The Linux kernel version is one of the most important pieces of information about a production host. It determines which features are available, which CVEs have been patched, and what the next update will look like.

The version string

Read-only / Safeuname -r— uname -r shows the running kernel version. The format is major.minor.patch[-extra]. Major is rarely incremented; minor increments roughly every 2-3 months for stable; patch for each release.

$ uname -r

6.6.31-linuxkit

Illustrative output

Field	Meaning
`6`	Major version — rarely changes
`6`	Minor version — increments every few weeks
`31`	Patch level — increments per release
`-linuxkit`	Vendor or distribution suffix

Vendor suffixes are common: -aws on AWS-optimised kernels, -azure on Azure, -linuxkit on Docker Desktop, -generic on Ubuntu.

Read-only / Safeuname -a, /proc/version— uname -a shows kernel version, hostname, architecture, build timestamp. /proc/version shows the build details: which compiler, which options, who built it. Useful for confirming the running kernel matches the installed package.

$ uname -a; cat /proc/version

Linux host 6.6.31-linuxkit #1 SMP PREEMPT_DYNAMIC ... x86_64 GNU/Linux
Linux version 6.6.31-linuxkit (root@build) ...

Illustrative output

Stable, LTS, and vendor kernels

Track	Cadence	Support	Audience
stable	Every 2-3 months	Until the next stable	Hobbyists, bleeding edge
longterm (LTS)	Major versions selected for long support	2-6 years	Production
linux-next	Daily	Not for production	Kernel developers

LTS versions are designated by Greg Kroah-Hartman and supported for years. Current LTS releases include:

6.6 LTS — supported through Dec 2026
6.1 LTS — supported through Dec 2026
5.15 LTS — supported through Dec 2026
5.10 LTS — supported through Dec 2026
5.4 LTS — supported through Dec 2025

Read-only / Safekernel build— The version string itself does not tell you whether it is an LTS. Check the distribution's package metadata or the kernel.org changelog to confirm.

$ cat /proc/version_signature 2>/dev/null || cat /proc/version

...

Illustrative output

Vendor kernels

Most distributions ship their own kernels with distribution- specific patches:

Distribution	Kernel	Source
Ubuntu 24.04	6.6 HWE	kernel.org + Ubuntu patches
Debian 12	6.1 LTS	kernel.org + Debian patches
RHEL 9	5.14	RHEL-maintained; backports from upstream LTS
Rocky/Alma 9	5.14	RHEL rebuild
AWS	6.6 aws	kernel.org + AWS-specific (Xen, ENA, NVMe)

Vendor kernels include drivers and fixes that the upstream kernel does not (cloud hypervisor drivers, hardware enablement patches, distribution bug fixes).

Read-only / Safeinstalled kernels— List the installed kernels. Production hosts typically keep at least one previous version for fallback; some keep two. The list shows the version, the install date, and the package status.

$ dpkg -l linux-image-* 2>/dev/null | head; rpm -q kernel

...

Illustrative output

Planning kernel updates

The production cadence for kernel updates depends on:

Security urgency: a kernel CVE that affects the host’s workload (e.g., a privilege escalation) demands an immediate patch.
Compatibility: a kernel update is needed for new hardware (e.g., a new CPU generation) or new features (a filesystem with newer on-disk format).
Routine refresh: every 6-12 months for general bug fixes and security backports.

Read the CVE. Understand whether the host is affected and what the impact is
Test on a clone. Boot the new kernel on a clone host; run smoke tests; check for regressions
Stage in dev → canary → production waves. Do not roll out fleet-wide immediately
Plan for rollback. The previous kernel should remain in the GRUB menu; the host can fall back if the new kernel fails to boot
Schedule a maintenance window for non-emergency updates
Capture pre- and post-boot evidence. Journal of the previous boot, kernel messages, GRUB configuration

The version string

Stable, LTS, and vendor kernels

Vendor kernels

Planning kernel updates

Knowledge check