Linux Determine Operating System: A Practitioner’s Guide

Most production systems carry a plain-text identity file at /etc/os-release. Read it correctly and you get a reliable fingerprint for the distribution you are running. Read it lazily and you hand yourself a false sense of confidence.

Open the file with cat and scan the fields that matter. If you have never worked through how to open and read files in Linux on a headless server, start there, because the command is the same on Ubuntu, Debian, AlmaLinux, and Rocky.

cat /etc/os-release

A typical Ubuntu 22.04 LTS host prints something like this:

PRETTY_NAME="Ubuntu 22.04.3 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"

Each field tells you something different, and they are not interchangeable. PRETTY_NAME is the human-readable label, often the one you paste into a report or a support ticket. ID is the short machine-readable slug, useful for scripting and conditionals. VERSION_ID carries the numeric release, so 22.04 and 24.04 distinguish LTS generations without parsing the pretty name. VERSION_CODENAME gives the codename, which is handy when you need to translate a release into the archive suffix that package managers expect. ID_LIKE signals family relationships, which matters when you are porting instructions from one distro to a sibling that shares the same package conventions.

Here is the trap I see on real hosts. A container or a VM can carry its own /etc/os-release that does not match the kernel underneath it. You run the read inside an Alpine-based container on an AlmaLinux host, and the file tells you about the container image, not the machine that is running the process. That gap is the difference between knowing what the filesystem says and knowing what the kernel is serving. If your script makes scheduling or package decisions based on that file alone, you are deciding on the wrong layer.

Treat detection as layered identity. The file gives you the distro identity the distribution team published. It does not prove the kernel version, the init system, or whether you are sitting inside a chroot, a container, or a VM. Use the file as one signal, then cross-check the layer that affects your work.

When /etc/os-release is missing entirely, you are usually in a stripped environment. Builds that minimize the rootfs sometimes drop it, and some containers ship with only the bare minimum. That is where a fallback chain earns its place. Read the file first. If it is absent, fall back to the package manager, then to the kernel release, then to whatever signaling the runtime leaves behind. Stop only when you have enough to act, not when you have one clean answer.