lsb_release

What it does

lsb_release prints Linux Standard Base and distribution-specific information, including the distributor name (e.g. Ubuntu, Debian), the release version number, and the release codename (e.g. jammy, bookworm). It's the quickest way to answer "which distro and version am I actually running?" — something uname deliberately does not tell you, since uname only reports kernel details.

Beginner examples

• lsb_release -a — print distributor ID, description, release, and codename
• lsb_release -d — print just the friendly description, e.g. Ubuntu 24.04.1 LTS
• lsb_release -r — print just the release number, e.g. 24.04
• lsb_release -c — print just the codename, e.g. noble

lsb_release -a

Advanced examples

• Get script-friendly output without field labels: lsb_release -s
• Combine flags for a compact one-liner: lsb_release -sir → Ubuntu 24.04
• Use the codename to add the right APT repository line: lsb_release -sc
• Fall back gracefully in scripts when the command is missing: command -v lsb_release >/dev/null && lsb_release -d || cat /etc/os-release
• Check distributor ID before branching install logic in a provisioning script: [ "$(lsb_release -si)" = "Ubuntu" ] && apt install ...

lsb_release -sir

Common mistakes

• Assuming lsb_release is preinstalled everywhere — it's frequently missing on minimal images, containers, and Arch-based systems, causing "command not found" errors in scripts that assume it exists.
• Parsing lsb_release -a's labeled output with fragile string splitting instead of using -s for clean, label-free values meant for scripting.
• Confusing "release" (the version number) with "codename" — automation that adds APT repositories usually needs the codename (-c), not the release number (-r).
• Forgetting that on Debian, lsb_release -a can be slow the first time it runs because it queries dpkg — subsequent runs are cached and fast.

Tips

• Use lsb_release -sc when generating APT source list entries that reference the distro codename (e.g. deb ... jammy main).
• If lsb_release isn't installed, apt install lsb-release (Debian/Ubuntu) or dnf install redhat-lsb-core (Fedora/RHEL-family) adds it.
• For maximum portability across distros, prefer /etc/os-release in shell scripts; reserve lsb_release for interactive/human use.

Best practices

• In provisioning or CI scripts, don't hard-depend on lsb_release being present — detect it with command -v lsb_release and fall back to /etc/os-release.
• Use the -s flag family (-si, -sr, -sc, -sd) for any output you intend to parse programmatically, since it strips the human-readable labels.
• Document which exact field (ID, release, or codename) your automation depends on — they're easy to conflate and cause subtle bugs in repository configuration.

Real-world use cases

• Quickly confirming which Ubuntu/Debian release a server is running before applying an OS-specific fix or patch.
• Generating the correct APT repository line for third-party software that ships per-codename packages (e.g. Docker's official install script).
• Including distro name/version in bug reports or support tickets alongside uname -a.
• Branching provisioning scripts (Ansible, shell) based on distributor ID or codename.

Common interview questions

• How is lsb_release different from uname? uname reports kernel-level facts (kernel name, release, architecture); lsb_release reports distribution-level facts (distributor name, distro version, codename) — the two answer different questions.
• What would you do if lsb_release isn't installed on a server? Read /etc/os-release instead, which is present on essentially all modern distros without extra packages.
• Why might a script prefer lsb_release -sc over -r? Because many third-party APT repositories are keyed by codename (e.g. bookworm, jammy), not by the numeric release version.