Home / Alt manpages / uname(1)

  • uname(1)
  • User command
  • linux

Read the Kernel and Machine Identity with uname

uname gives you a fast way to identify the running kernel, hostname and machine architecture, plus checks for exactly the fields you need. The examples use GNU uname from coreutils 9.4, installed here as package version 9.4-3ubuntu6.3.

Allow about ten minutes. You need a shell and the coreutils package, which is normally already present. Every command here only reads system identity: no elevated privileges are needed, and nothing on the host changes.

1. Check the installed command

Confirm which executable your shell will run, then check its version:

$ command -v uname
/usr/bin/uname
$ uname --version
uname (GNU coreutils) 9.4
...

The copyright and licence text in the remaining lines can vary, but the first line should identify GNU coreutils 9.4 on the system described here. If command -v points somewhere unexpected, inspect that file before comparing output against this guide: a wrapper or non-GNU implementation may support a different set of options.

Checkpoint

Run uname --help if you need to confirm the options your current PATH actually provides.

2. Get the default kernel name

Run uname with no option:

$ uname
Linux

With no option, this GNU command behaves as uname -s: it prints the kernel name, which on a Linux machine is usually just Linux. Do not read this as a complete operating-system description. It tells you nothing about distribution, release number, architecture, or whether you are inside a container.

The long form spells out intent for anyone reading a script later:

$ uname --kernel-name
Linux

3. Select the fields you need

Use one option for one focused answer. These are the portable, useful fields in the installed manpage:

OptionReportsExample shape
-sKernel nameLinux
-nNetwork node hostnameserver.example
-rKernel release6.8.0-139-generic
-vKernel version string#139-Ubuntu SMP ...
-mMachine hardware namex86_64
-oOperating systemGNU/Linux

For a compact diagnostic, request several fields in the documented order:

$ uname -s -n -r -m -o
Linux server.example.com 6.8.0-139-generic x86_64 GNU/Linux

GNU uname prints one line with fields separated by spaces. A hostname or kernel version can itself contain spaces, so do not treat this combined line as a reliable data format when another program has to parse each value. Ask for one field at a time when field boundaries matter.

Checkpoint

Compare the release and machine fields against what a service or deployment check expects:

$ printf 'kernel release: %s\n' "$(uname -r)"
kernel release: 6.8.0-139-generic
$ printf 'machine: %s\n' "$(uname -m)"
machine: x86_64

4. Use all available information for a human report

uname -a, or uname --all, prints kernel name, network node hostname, kernel release, kernel version, machine hardware name, processor type, hardware platform, then operating system, in that order. GNU omits the processor and hardware-platform fields when they are unknown:

$ uname -a
Linux server.example.com 6.8.0-139-generic #139-Ubuntu SMP PREEMPT_DYNAMIC Sat Aug 1 03:52:05 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux

Your hostname, release and build date will differ. -a output is convenient for a support note, but it is a poor choice for a long-lived script: the version text can change and the non-portable fields may be omitted entirely. Prefer explicit fields such as uname -r and uname -m for automation.

5. Handle architecture and portability carefully

uname -m reports the machine hardware name. That describes the kernel's view of the machine, not necessarily the instruction set every individual process supports: a 32-bit process can run happily on a 64-bit host. If your decision concerns a compiler, interpreter or package manager, check that tool's own target information too.

uname -p and uname -i report processor type and hardware platform, but the installed manpage marks both non-portable. They can come back unknown even when uname -m works fine:

$ uname -p
unknown
$ uname -i
unknown

Do not turn unknown into a guessed CPU model, and do not treat these two fields as universal feature tests. Handy for a human inventory is not the same thing as a stable interface for deployment logic.

6. Capture a result in a shell check

Quote command substitutions and compare exact values. This example records the kernel release and stops if the command fails:

release=$(uname -r) || {
    printf '%s\n' 'Could not read the kernel release' >&2
    exit 1
}
printf 'running kernel: %s\n' "$release"

For a diagnostic that must run on Linux, check the kernel name before making a Linux-specific assumption:

kernel=$(uname -s) || exit 1
if [ "$kernel" != Linux ]; then
    printf 'Unsupported kernel: %s\n' "$kernel" >&2
    exit 1
fi
printf '%s\n' 'Linux kernel detected'

This is a guard, not a security boundary. Output from uname is system metadata, not proof that a kernel is patched, a distribution is supported, or a requested capability is actually available. Check the real capability before enabling a feature that depends on it.

7. Troubleshoot the usual mistakes

  • Wrong command. type -a uname shows aliases, functions and every matching executable. Remove an accidental alias or use the intended absolute path when reproducing a report.
  • Confusing kernel and distribution. uname -r is a kernel release, not the Ubuntu, Debian or other distribution release. Use the distribution's own release metadata for that question instead.
  • Parsing -a badly. Fields can be omitted or contain spaces. Use separate invocations for anything machine-readable.
  • Expecting root-only data. uname never needs sudo. Adding it only adds noise and can hide the fact that the plain, read-only command was already enough.

There is no recovery step here because none of this alters state. If a value looks wrong, save the output of command -v uname, uname --version and the relevant explicit field, then investigate the executable and host context rather than touching kernel settings.

Done means

  • Identified the implementation. You know the installed uname build and coreutils version.
  • Pulled single fields. You can retrieve kernel name, release, hostname and machine name separately.
  • Understood -a's limits. You know why it suits a human report but not stable parsing.
  • Guarded your script. Your shell check quotes the result and tests the command status.
  • Kept the distinction straight. You have not mistaken kernel metadata for distribution identity or a capability check.