Read the Running Kernel Build from /proc/version

You will inspect the kernel that is running now and understand the complete text returned by /proc/version. The file is read-only: this guide changes no kernel setting, service or boot configuration. Allow about five minutes. You need a shell and permission to read the local proc filesystem, which is normally available to an ordinary user.

1. Read the complete value

Print the file directly:

$ cat /proc/version
Linux version 6.8.0-139-generic (buildd@lcy02-amd64-036) (x86_64-linux-gnu-gcc-13 (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #139-Ubuntu SMP PREEMPT_DYNAMIC Sat Aug  1 03:52:05 UTC 2026

Your line will be different. The installed proc_version(5) manual page describes this string as the identifier for the currently running kernel. It includes the values from /proc/sys/kernel/ostype, /proc/sys/kernel/osrelease and /proc/sys/kernel/version. That makes it useful as a compact diagnostic record, but it is not a list of separate shell fields with a stable machine-readable grammar.

Checkpoint: confirm that the output begins with Linux version and is one line. If cat reports that the file does not exist, check that procfs is mounted before assuming the kernel lacks version information.

2. Identify the release field

The text immediately after Linux version is the kernel release. On this host it is 6.8.0-139-generic. Read that part without trying to split the whole line on spaces:

$ uname -r
6.8.0-139-generic

uname -r is not a replacement for the file. It is a focused query that is easier for a script when the only question is which release is active. Comparing it with the release shown after Linux version is a useful sanity check:

$ test "$(uname -r)" = "$(sed -n 's/^Linux version \([^ ]*\).*$/\1/p' /proc/version)" && echo 'release fields agree'
release fields agree

The command uses a deliberately narrow pattern: it extracts the first non-space value after the fixed prefix. It does not attempt to parse the compiler, builder or timestamp.

3. Inspect the three component files

Read the component values named by the manual page. Use printf labels so you can tell identical-looking output lines apart:

$ printf 'ostype: '; cat /proc/sys/kernel/ostype
ostype: Linux
$ printf 'osrelease: '; cat /proc/sys/kernel/osrelease
osrelease: 6.8.0-139-generic
$ printf 'version: '; cat /proc/sys/kernel/version
version: #139-Ubuntu SMP PREEMPT_DYNAMIC Sat Aug  1 03:52:05 UTC 2026

These files expose the parts used to construct the combined identity. The output on another machine can include a different release, distribution build suffix, build number, compiler detail or build date. Do not treat the timestamp as the time the machine booted; it describes the kernel build recorded in the version string.

Checkpoint: if the first two component values are Linux and the same release returned by uname -r, you have identified the active kernel release. The remaining version text is build metadata, not a command-line option or a setting to edit.

4. Record the value for a support report

For a human support report, capture the complete line together with the date and hostname:

$ printf 'host: '; hostname
host: server.dixon.cx
$ printf 'checked: '; date --iso-8601=seconds
checked: 2026-09-26T12:00:00+01:00
$ printf 'kernel: '; cat /proc/version
kernel: Linux version 6.8.0-139-generic (buildd@lcy02-amd64-036) (x86_64-linux-gnu-gcc-13 (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #139-Ubuntu SMP PREEMPT_DYNAMIC Sat Aug  1 03:52:05 UTC 2026

The date in this example is illustrative. Use the output from your own command. A timestamp matters because a reboot may have selected a different installed kernel after an update, while an old report still describes the kernel that was active when it was collected.

If you need a file, redirect to a new path rather than overwriting an existing report:

$ umask 077
$ { printf 'host: '; hostname; printf 'checked: '; date --iso-8601=seconds; printf 'kernel: '; cat /proc/version; } > /tmp/kernel-report.txt
$ sed -n '1,3p' /tmp/kernel-report.txt

This report can contain builder or compiler information but normally contains no secret credential. Still, review it before sending it outside your organisation. Remove the temporary file when it is no longer needed with rm -- /tmp/kernel-report.txt; that deletion is irreversible, so keep it only if your support process requires it.

5. Avoid misleading checks

Do not use /proc/version to decide whether a reboot is required by comparing only the build timestamp. Compare the running release with the distribution's package and reboot policy. A newer kernel can be installed without becoming active until a reboot, and a version string alone does not tell you whether a security fix is present.

Do not write to any path under /proc for this task. Reading /proc/version and its three named component files needs no sudo on a normal system. Elevated privileges will not make a missing procfs mount become a valid kernel report.

If the output is unexpectedly empty or a component file cannot be opened, inspect the mount without changing it:

$ findmnt /proc
$ test -r /proc/version && echo readable || echo 'not readable'

A container can have a proc filesystem with a view shaped by its runtime, and a restricted environment can deny access. Record the exact environment and error instead of filling in values from the host or from an earlier report.