Most kernel-version confusion on Ubuntu comes from asking one question and answering a different one. To check the kernel version on Ubuntu, run uname -r. It prints the release string of the kernel the machine actually booted, and nothing else. Reach for uname -a or cat /proc/version when you need build and compiler context for a bug report. List installed kernel packages separately, because what is installed on disk is not what is running in memory.

Last updated: 2026-08-02

How do you check the kernel version on Ubuntu?

Run this first:

uname -r

You get one line back: the release string of the running kernel.

The word "running" is doing real work in that sentence. uname reads from the kernel that is loaded right now, so it cannot lie to you about what booted. If somebody pastes a version from a package listing instead, they are answering a different question. Ask for the uname -r output every time.

Reading the release string before you trust it

An Ubuntu package version string has three parts, and each one comes from a different place. A kernel release string is different: before the first hyphen sits the upstream version. After it comes Ubuntu's own kernel build revision, which climbs on its own schedule and has nothing to do with upstream's pace. The word on the end is the flavour.

Flavour matters more than people expect. generic is what most desktops and servers boot. You will also see lowlatency, plus cloud and board-specific flavours on those images. A module built against one flavour will not load on another, so when a vendor driver refuses to build, check the flavour before you blame the compiler.

Upstream numbering is simpler than it looks. The second component goes up with every release, and the first only moves when the second gets large enough. So a jump from one major line to the next is bookkeeping, not an interface break.

What the rest of uname adds, and when /proc/version wins

Add flags only when you need what they carry:

• uname -v gives the build version string, including when that kernel was built.
• uname -m prints the architecture of the running kernel. Read the output rather than assuming from whichever installer image you downloaded.
• uname -a prints everything at once. Paste this into a bug report, not into a script.

For build and compiler detail, read it from the kernel itself:

cat /proc/version

That file is generated by the running kernel, so it always matches the binary in memory. Here is what happens when two commands seem to disagree: one of them is reading a package database and the other is reading the kernel. /proc/version is the second kind. When I need to prove which toolchain built a kernel, that's where I look.

hostnamectl and the Ubuntu release number answer different questions

hostnamectl prints a tidy block with the operating system, the kernel, and the architecture together. It is convenient for a quick audit and fine for a screenshot. However, it is a summary tool, not the authority on kernel detail, so I still confirm with uname -r before acting on it.

The Ubuntu release number is a separate fact entirely:

lsb_release -a
cat /etc/os-release

Those tell you which Ubuntu you are on. They tell you nothing about which kernel booted. Two machines on the same Ubuntu release can be running different kernels, which is exactly the mismatch that wastes an afternoon when you are matching a driver.

How do you list the kernels installed on the machine?

Query the package database directly:

dpkg -l 'linux-image*'
apt list --installed 'linux-image*'

Read the status codes in the first column of the dpkg output. ii means installed and bootable. rc means the package is gone but its config files are still sitting there, and people misread those as installed kernels all the time.

Compare that list against uname -r and you have both halves of the picture. If the list is long and /boot is filling up, clear out the old images with a proper procedure for removing unused kernel packages rather than deleting files by hand.

Installed and running drift apart for boring reasons

The usual cause is the least dramatic one: you installed a kernel and never rebooted. The new image sits in /boot, the package manager reports it as installed, and the old kernel keeps running until the next boot. Check for a pending reboot:

ls /var/run/reboot-required

Beyond that, three things keep an older kernel in charge. GRUB may be pinned to a specific entry or defaulting to a saved one. A package may be held, so apt-mark showhold is worth a look. Or an update failed halfway and left the initramfs unbuilt.

Unattended upgrades add their own wrinkle. The package lands overnight, nobody reboots, and the fleet reports a patched version while running the old code. If reboot windows are the constraint, weigh live patching against a reboot instead of pretending the gap isn't there.

Prove which kernel booted before you reinstall anything

Do not reinstall the kernel package because the version looks wrong. Get the evidence first:

journalctl -k -b | head -20
cat /proc/cmdline
grep menuentry /boot/grub/grub.cfg

The first command shows the kernel ring buffer from this boot, and its opening lines name the exact kernel and the compiler that built it. /proc/cmdline shows the boot arguments GRUB actually passed, which is how you catch a pinned or hand-edited entry. The grub.cfg listing tells you what the bootloader believes it can offer.

If the kernel you want isn't in that menu, the problem is package or initramfs state, not GRUB's default. Run sudo update-initramfs -u -k all and then sudo update-grub, and read the output instead of scrolling past it. When the newer kernel boots and then breaks, you want a planned kernel rollback, not a panicked purge at 2am.

Which command to use for support, drivers, and debugging

My rule is narrow output for decisions, wide output for reports. A script comparing kernels across a fleet should parse uname -r and nothing else, because uname -a changes shape with hostname length and locale.

Your kernel line matters more than your kernel number

Knowing the number is step one. Knowing whether that line still gets patches is the part that bites. Upstream ships mainline releases every 9 to 10 weeks: a 2-week merge window, then roughly 7 weeks of bugfix work with weekly release candidates, usually ending at rc7 with an occasional rc8 or later.

Long-term lines are the ones you plan around. Upstream lists 6.18 (released November 2025) and 6.12 (released November 2024) with projected end of life in December 2028. Both 6.6 (October 2023) and 6.1 (December 2022) are projected to end in December 2027, while 5.15 (October 2021) and 5.10 (December 2020) are projected to end in December 2026.

Ubuntu maintains its own schedule on top of that, so read the Ubuntu kernel lifecycle for what Canonical supports on your release rather than assuming upstream dates apply. Past end of life, new vulnerabilities in that code stay open on your box. If you keep drifting, schedule the work with automatic kernel upgrades.

FAQ

Can I find the kernel version without opening a terminal?

The GNOME Settings panel under About lists system details, and recent versions include a kernel line there. Older desktops show only the Ubuntu release, which is the wrong fact for driver work. I treat the graphical readout as a convenience and confirm on the command line before I act on it.

Why does the kernel version look strange inside a container or WSL?

Containers share the host kernel, so uname -r inside one reports the host's kernel, not anything from the image. That surprises people who expect the base image's Ubuntu release to imply a matching kernel. WSL behaves the same way against its own kernel, which is why module builds fail there in ways they never do on metal.

Do I need sudo to check the kernel version?

No. Every command in this article except the initramfs and GRUB rebuilds runs fine as a normal user. That makes ssh host uname -r a safe way to sweep a fleet, and it works without granting anyone elevated access.

Why do two machines on the same Ubuntu release run different kernels?

Long-term support releases offer a hardware enablement kernel alongside the original one, so a newer install can land on a newer kernel than an older install of the same Ubuntu version. The Ubuntu release number stays identical either way. Check uname -r on both boxes and compare the actual strings before you conclude anything about compatibility.