Check Ubuntu Version: The Command, and Why the Number Matters

Run lsb_release -a to check your Ubuntu version, or cat /etc/os-release if lsb_release is not installed - both print the release number, the codename, and the description in a couple of lines. That is the entire answer to the literal question, and it takes five seconds. The part worth your attention is what you do with the number: whether that release still receives security updates, when it stops, and whether the box in front of you is running something the internet stopped patching a while ago. A version number is not trivia. It is an expiry date.

Everyone searching for this gets the command in the first result. Almost nobody gets told what to do with the answer, which is the only reason the answer is interesting.

Table of contents

• The commands
• Reading the number
• Why anyone actually needs this
• Checking end of life, not just the version
• The version you check is not always the version you run
• How this fits the rest of the stack
• FAQ

The commands

Three ways, in the order you should try them.

# The friendliest output.
lsb_release -a

# Always present, no extra package needed.
cat /etc/os-release

# Kernel and architecture, not the distro release.
uname -a

lsb_release -a prints something like this:

Distributor ID: Ubuntu
Description:    Ubuntu 24.04.1 LTS
Release:        24.04
Codename:       noble

On a minimal container image lsb_release often is not installed. cat /etc/os-release always works, needs nothing extra, and is the one to reach for in a Dockerfile or a script.

A word on uname -a: it reports the kernel, not the distribution release. A kernel version tells you about the kernel - useful, but it is not the answer to this question, and people confuse the two constantly.

Reading the number

Ubuntu versions encode the release date. 24.04 shipped in April 2024. 22.04 in April 2022. Releases in April of even-numbered years are LTS releases; everything else is an interim release with a nine-month life.

• LTS releases - April, even years. Five years of standard security support.
• Interim releases - every six months otherwise. Nine months of support, then nothing.
• The codename - noble, jammy, focal. Alphabetical, and what package repositories are keyed on.

So a glance at the number tells you the support story. 22.04 LTS is patched into 2027. A 23.10 box stopped receiving updates in mid-2024 and has been accumulating known vulnerabilities ever since, silently, while continuing to serve traffic perfectly well. That silence is the problem.

Why anyone actually needs this

The reasons you find yourself checking, roughly by frequency:

1. Install instructions branch on it. Vendor docs say do this on 22.04, that on 24.04. Get it wrong and you add a repo for the wrong codename.
2. A package is missing or too old. Distro repos pin package versions per release. The version explains the age.
3. Support is ending. The single most important reason and the one nobody checks proactively.
4. A base image drifted. Your Dockerfile says FROM ubuntu:latest, and latest moved. Now it is a different release than it was.
5. Something broke after an upgrade. Knowing which release you landed on is step one of the diagnosis.

That fourth one deserves emphasis. FROM ubuntu:latest is not a version - it is a moving target that changes under you when a new LTS ships. Pin the release explicitly: FROM ubuntu:24.04. Reproducible builds start with not letting your base image drift.

Checking end of life, not just the version

The version number is the question; the support window is the answer you wanted.

# Shows support status and EOL dates for the installed release.
ubuntu-security-status

# Or check what your release is entitled to.
hwe-support-status --verbose

If those are not available, the mapping is simple enough to remember: LTS gets five years from its April release. 20.04 ended standard support in April 2025. 22.04 runs to April 2027. 24.04 to April 2029.

The practical habit: when you check a version, check the EOL date in the same minute. A version number with no support context is half an answer, and the missing half is the one that matters.

The version you check is not always the version you run

A subtlety that catches people out. If your app runs in a container, lsb_release -a on the host tells you about the host - not about the environment your code actually executes in.

Your container has its own base image with its own Ubuntu version, its own libraries, and its own patch level. A perfectly patched host can run a container built on an image that went end-of-life two years ago, and the host’s clean bill of health tells you nothing about it.

# The host.
cat /etc/os-release

# What your code actually runs on.
docker run --rm myimage cat /etc/os-release

If you are hunting a library version mismatch or a security question, the container’s answer is usually the one that matters.

How this fits the rest of the stack

Knowing your release is free. Being on an unsupported one is not - it is a risk you carry until an upgrade you keep postponing, and upgrades are where teams lose weekends. That is part of why so many teams stop managing the base OS at all: it is undifferentiated work that never makes the product better. If you are weighing that trade, the RunxBuild hosting calculator lays out what the compute, database, storage, and bandwidth actually cost together, so the comparison is against a number rather than a feeling. The RunxBuild dashboard is where the team watches it once it is running.

Useful related references:

• Linux Ubuntu Check Version: lsb_release, /etc/os-release, hostnamectl
• Check IP Address on Ubuntu: The 6 Commands That Always Work
• How to Check Your IP Address in Ubuntu (And Which One You Actually Want)
• Services on RunxBuild

FAQ

How do I check my Ubuntu version from the command line?

Run lsb_release -a for a readable summary with the release number and codename, or cat /etc/os-release if lsb_release is not installed - the latter always works, including on minimal container images. Both take a second. Avoid uname -a for this: it reports the kernel version, not the Ubuntu release, and the two are frequently confused.

What is the difference between lsb_release and /etc/os-release?

lsb_release is a command from a package that may not be installed on minimal images; /etc/os-release is a plain file that is always present. They report the same release information. Use /etc/os-release in scripts and Dockerfiles because it has no dependency, and lsb_release -a interactively because the output is easier to read.

How do I know if my Ubuntu version is still supported?

LTS releases get five years of standard security support from their April release date, so 22.04 runs to April 2027 and 24.04 to April 2029. Interim releases get nine months. Run ubuntu-security-status for the details on the installed system. Check the EOL date at the same time you check the version - the number alone does not tell you whether you are still getting patches.

Does uname -a show the Ubuntu version?

No. uname -a shows the kernel version and architecture, which is a different thing. A machine can run a newer kernel than its distro release suggests, particularly with hardware enablement kernels. For the Ubuntu release, use lsb_release -a or /etc/os-release.

Why does my container show a different Ubuntu version than the host?

Because it is a different operating system image. The container ships its own base image with its own release and libraries, and only shares the host’s kernel. A fully patched host can run a container whose base image is years past end-of-life. If you care about what your code actually runs against, check inside the container, not on the host.