How to check Linux version

In complex Linux estates, most “mystery” outages aren’t really mysteries at all. A 2023 global survey found that nearly two‑thirds of IT system and software‑related outages were caused by configuration or change‑management mistakes, not by the underlying platforms themselves. Misreading a Linux kernel or OS version before a security patch rollout is exactly the kind of small oversight that can snowball into large‑scale downtime.

This happens a lot in IT environments because Linux version detection isn’t as straightforward as checking a single number. Understanding your Linux system’s true version requires checking multiple layers that answer different compatibility questions, and missing any one creates blind spots in your infrastructure management.

Here’s everything you need to know to check your Linux version quick and easy.

» New to Linux? Learn which Linux command sends messages to network interface

Why checking your Linux version is so complex

When validating compatibility and support, you need to separate three distinct layers because they answer fundamentally different questions:

• The kernel version tells you what hardware drivers, security fixes, and low-level capabilities the system actually has. Identical distribution versions with different kernels could have different levels of support, such as Ubuntu 20.04 servers running a 5.4 kernel having limited NIC and input-device support compared to systems on the 5.15 HWE kernel.
• The distribution version defines the vendor’s packaging, defaults, and support lifecycle. Two systems can run the same kernel but behave differently if one is Ubuntu and the other is Rocky Linux.
• The OS release combines the distro version, kernel policy, and support window into a single support contract.

From an operational perspective, kernel checks validate hardware compatibility, distro checks confirm tooling and libraries, and OS release checks determine whether the system is still eligible for updates and vendor support.

» Trying to get rid of the distro? Here’s how to uninstall a WSL distro in Windows 11

How build types alter available version information

Enterprise Linux builds like RHEL, Ubuntu LTS, or SUSE provide rich version information by design because supportability matters. By default, you’ll find /etc/os-release, detailed kernel metadata, vendor tools, and lifecycle identifiers. In enterprise RHEL and Ubuntu fleets, this verbosity is intentional since enterprises need auditable support status and patch lineage.

Minimal builds change that balance. On stripped-down Ubuntu Server or Alpine images, only the kernel version and a basic /etc/os-release file may exist, with utilities like lsb_release removed to reduce footprint. This can mislead admins into thinking a system is “unknown” when it’s simply minimal.

Container-optimized builds abstract OS identity intentionally. In Docker, Bottlerocket, or distroless images, you may only see the kernel version from the host, while the container itself exposes little or no distro metadata.

Step-by-step guide to check Linux version

Checking your Linux version involves a two simple steps to accurately identify all the layers you need. Here’s how:

Step 1: Check the running kernel version and verify boot configuration

The first step is identifying the running kernel, not what’s installed. On any Linux system, the command uname -r reports the exact kernel version actively loaded into memory.

This command shows you the kernel that’s currently running, which differs from installed packages that might include newer versions waiting for a reboot. The output of uname -r provides the kernel release string (for example, 5.15.0-91-generic or 5.14.0-427.22.1.el9.x86_64). This is the label on the engine currently running, not the spare in the trunk.

While this only confirms the kernel version and architecture, it provides a baseline for compatibility and can help infer certain distributions:

• RHEL kernels often include version tags in their naming (e.g., .el9 for RHEL 9)
• Ubuntu kernels frequently end in -generic or -hwe, and these suffixes help identify the distribution family

After you’ve done this, make these confirmations as well:

• To verify installed kernels, use package tools. On Debian-based systems, dpkg --list | grep linux-image shows all kernel packages on disk. On Red Hat-based systems, rpm -qa | grep kernel provides the same information. If the newest isn’t running, you need to reboot.
• To confirm the intended boot configuration, check the bootloader. On GRUB systems, grub2-editenv list or reviewing /boot/grub/grub.cfg shows the default kernel entry. This verifies which kernel the system will load on next boot.
• Finally, ensure the running kernel matches the expected configuration by cross-checking /proc/version and /boot/config-$(uname -r). This full sequence prevents false confidence and catches silent boot mismatches.

Step 2: Determine OS and distribution version using standardized files

The most reliable method for determining OS and distribution version on modern Linux systems is reading /etc/os-release. This file is present on almost all current distributions and provides standardized, structured information.

Inspect the file with cat /etc/os-release or less /etc/os-release. Key fields to interpret include:

• NAME: The distribution name (e.g., Ubuntu, Rocky Linux).
• VERSION: Human-readable release string (e.g., “22.04.2 LTS”).
• ID: Short identifier used in scripts (e.g., ubuntu).
• VERSION_ID: Numeric version for automated checks (e.g., 22.04).
• PRETTY_NAME: Formatted string combining name and version.

Older distributions may also provide /etc/issue or /etc/*-release files, but these are less standardized. For enterprise IT environments, cross-checking with lsb_release -a provides additional fields like Distributor ID and Codename, which are useful for package management and support verification.

Bonus checks

Once you’ve done the checks above (or if they’re not working), there are some other checks you can make to narrow down the Linux version you might have. For example, examining package manager databases often reveals distribution details:

• On Red Hat-based systems, rpm -qa | grep release often lists packages like redhat-release or centos-release. In containerized builds, even if /etc/os-release
  is stripped, package metadata or embedded labels can reveal the distribution name and version.
• On Debian-based systems, dpkg -l | head can reveal base release package versions. The command dpkg-query --showformat='${Package} ${Version}\n' -W base-files shows the base-files package version, which frequently matches the distro release.

Other key filesystem markers to check include:

• /usr/lib/os-release: Alternative location containing the same structured data as /etc/os-release.
• /etc/centos-release, /etc/redhat-release, /etc/rocky-release: Distro-specific files with single-line version strings.
• /var/lib/dpkg/status (Debian/Ubuntu) or /var/lib/rpm/Packages (RPM-based): Package databases where you can grep for base packages.

Automate Linux version checks across IT environments with Atera

In large IT environments, manually checking Linux versions across dozens or hundreds of systems isn’t practical. Administrators need centralized visibility into what’s actually running across the entire fleet to ensure patch compliance, troubleshoot compatibility IT issues, and validate support coverage.

For quick ad-hoc checks across a few systems, SSH provides a simple approach. You can run commands remotely and collect version information:

ssh user@server1 'cat /etc/os-release; uname -r'
ssh user@server2 'cat /etc/os-release; uname -r'
      

This works for spot checks but becomes unwieldy at scale. You’re manually connecting to each system, copying outputs, and compiling results. With so much data to check, you’re prone to human error and wasted time when you’re managing 20, 50, or 100+ Linux servers.

For automated fleet-wide Linux monitoring, Atera’s RMM platform provides automated asset and inventory scanning across your entire infrastructure. Rather than manually SSHing into each system, Atera automatically collects system information through scheduled scans, including:

• Operating system and distribution version
• Kernel versions and patch levels
• Hardware specifications and architecture
• Installed software inventory

This information populates automatically in Atera’s centralized dashboard, giving you up-to-date visibility into every Linux system’s version status. You can quickly identify which systems are running outdated kernels, which need distribution upgrades, or which have fallen out of compliance with your standard configurations.

And if you need to run custom version-check scripts across your fleet, AI Copilot can generate custom scripts from plain-text instructions, no coding required. For example, you could ask “Create a script that checks if the running kernel matches the latest installed kernel package and reports any mismatches,” and Copilot generates the bash script for you. These scripts can then be deployed remotely through Atera’s automation profiles to run on specific systems or your entire fleet on a schedule.

» Interested? Try Atera for free