- bookworm 252.31-1~deb12u1
- bookworm-backports 254.16-1~bpo12+1
- testing 256.7-3
- unstable 257~rc2-3
OS-RELEASE(5) | os-release | OS-RELEASE(5) |
NAME¶
os-release, initrd-release, extension-release - Operating system identification
SYNOPSIS¶
/etc/os-release
/usr/lib/os-release
/etc/initrd-release
/usr/lib/extension-release.d/extension-release.IMAGE
DESCRIPTION¶
The /etc/os-release and /usr/lib/os-release files contain operating system identification data.
The format of os-release is a newline-separated list of environment-like shell-compatible variable assignments. It is possible to source the configuration from Bourne shell scripts, however, beyond mere variable assignments, no shell features are supported (this means variable expansion is explicitly not supported), allowing applications to read the file without implementing a shell compatible execution engine. Variable assignment values must be enclosed in double or single quotes if they include spaces, semicolons or other special characters outside of A–Z, a–z, 0–9. (Assignments that do not include these special characters may be enclosed in quotes too, but this is optional.) Shell special characters ("$", quotes, backslash, backtick) must be escaped with backslashes, following shell style. All strings should be in UTF-8 encoding, and non-printable characters should not be used. Concatenation of multiple individually quoted strings is not supported. Lines beginning with "#" are treated as comments. Blank lines are permitted and ignored.
The file /etc/os-release takes precedence over /usr/lib/os-release. Applications should check for the former, and exclusively use its data if it exists, and only fall back to /usr/lib/os-release if it is missing. Applications should not read data from both files at the same time. /usr/lib/os-release is the recommended place to store OS release information as part of vendor trees. /etc/os-release should be a relative symlink to /usr/lib/os-release, to provide compatibility with applications only looking at /etc/. A relative symlink instead of an absolute symlink is necessary to avoid breaking the link in a chroot or initrd environment such as dracut.
os-release contains data that is defined by the operating system vendor and should generally not be changed by the administrator.
As this file only encodes names and identifiers it should not be localized.
The /etc/os-release and /usr/lib/os-release files might be symlinks to other files, but it is important that the file is available from earliest boot on, and hence must be located on the root file system.
os-release must not contain repeating keys. Nevertheless, readers should pick the entries later in the file in case of repeats, similarly to how a shell sourcing the file would. A reader may warn about repeating entries.
For a longer rationale for os-release please refer to the Announcement of /etc/os-release[1].
/etc/initrd-release¶
In the initrd[2], /etc/initrd-release plays the same role as os-release in the main system. Additionally, the presence of that file means that the system is in the initrd phase. /etc/os-release should be symlinked to /etc/initrd-release (or vice versa), so programs that only look for /etc/os-release (as described above) work correctly.
The rest of this document that talks about os-release should be understood to apply to initrd-release too.
/usr/lib/extension-release.d/extension-release.IMAGE¶
/usr/lib/extension-release.d/extension-release.IMAGE plays the same role for extension images as os-release for the main system, and follows the syntax and rules as described in the Portable Services Documentation[3]. The purpose of this file is to identify the extension and to allow the operating system to verify that the extension image matches the base OS. This is typically implemented by checking that the ID= options match, and either SYSEXT_LEVEL= exists and matches too, or if it is not present, VERSION_ID= exists and matches. This ensures ABI/API compatibility between the layers and prevents merging of an incompatible image in an overlay.
In order to identify the extension image itself, the same fields defined below can be added to the extension-release file with a SYSEXT_ prefix (to disambiguate from fields used to match on the base image). E.g.: SYSEXT_ID=myext, SYSEXT_VERSION_ID=1.2.3.
In the extension-release.IMAGE filename, the IMAGE part must exactly match the file name of the containing image with the suffix removed. In case it is not possible to guarantee that an image file name is stable and doesn't change between the build and the deployment phases, it is possible to relax this check: if exactly one file whose name matches "extension-release.*" is present in this directory, and the file is tagged with a user.extension-release.strict xattr(7) set to the string "0", it will be used instead.
The rest of this document that talks about os-release should be understood to apply to extension-release too.
OPTIONS¶
The following OS identifications parameters may be set using os-release:
General information identifying the operating system¶
NAME=
Examples: "NAME=Fedora", "NAME="Debian GNU/Linux"".
ID=
Examples: "ID=fedora", "ID=debian".
ID_LIKE=
Examples: for an operating system with "ID=centos", an assignment of "ID_LIKE="rhel fedora"" would be appropriate. For an operating system with "ID=ubuntu", an assignment of "ID_LIKE=debian" is appropriate.
PRETTY_NAME=
Example: "PRETTY_NAME="Fedora 17 (Beefy Miracle)"".
CPE_NAME=
Example: "CPE_NAME="cpe:/o:fedoraproject:fedora:17""
VARIANT=
Examples: "VARIANT="Server Edition"", "VARIANT="Smart Refrigerator Edition"".
Note: this field is for display purposes only. The VARIANT_ID field should be used for making programmatic decisions.
VARIANT_ID=
Examples: "VARIANT_ID=server", "VARIANT_ID=embedded".
Information about the version of the operating system¶
VERSION=
Examples: "VERSION=17", "VERSION="17 (Beefy Miracle)"".
VERSION_ID=
Examples: "VERSION_ID=17", "VERSION_ID=11.04".
VERSION_CODENAME=
Examples: "VERSION_CODENAME=buster", "VERSION_CODENAME=xenial".
BUILD_ID=
Examples: "BUILD_ID="2013-03-20.3"", "BUILD_ID=201303203".
IMAGE_ID=
Examples: "IMAGE_ID=vendorx-cashier-system", "IMAGE_ID=netbook-image".
IMAGE_VERSION=
Examples: "IMAGE_VERSION=33", "IMAGE_VERSION=47.1rc1".
To summarize: if the image updates are built and shipped as comprehensive units, IMAGE_ID+IMAGE_VERSION is the best fit. Otherwise, if updates eventually completely replace previously installed contents, as in a typical binary distribution, VERSION_ID should be used to identify major releases of the operating system. BUILD_ID may be used instead or in addition to VERSION_ID when the original system image version is important.
Presentation information and links¶
HOME_URL=, DOCUMENTATION_URL=, SUPPORT_URL=, BUG_REPORT_URL=, PRIVACY_POLICY_URL=
Examples: "HOME_URL="https://fedoraproject.org/"", "BUG_REPORT_URL="https://bugzilla.redhat.com/"".
SUPPORT_END=
For example, "SUPPORT_END=2001-01-01" means that the system was supported until the end of the last day of the previous millennium.
LOGO=
Examples: "LOGO=fedora-logo", "LOGO=distributor-logo-opensuse"
ANSI_COLOR=
Examples: "ANSI_COLOR="0;31"" for red, "ANSI_COLOR="1;34"" for light blue, or "ANSI_COLOR="0;38;2;60;110;180"" for Fedora blue.
VENDOR_NAME=
This name is intended to be exposed in "About this system" UIs or software update UIs when needed to distinguish the OS vendor from the OS itself. It is intended to be human readable.
Examples: "VENDOR_NAME="Fedora Project"" for Fedora Linux, "VENDOR_NAME="Canonical"" for Ubuntu.
VENDOR_URL=
The value should be in RFC3986 format[5], and should be "http:" or "https:" URLs. Only one URL shall be listed in the setting.
Examples: "VENDOR_URL="https://fedoraproject.org/"", "VENDOR_URL="https://canonical.com/"".
Distribution-level defaults and metadata¶
DEFAULT_HOSTNAME=
See org.freedesktop.hostname1(5) for a description of how systemd-hostnamed.service(8) determines the fallback hostname.
ARCHITECTURE=
SYSEXT_LEVEL=
Examples: "SYSEXT_LEVEL=2", "SYSEXT_LEVEL=15.14".
CONFEXT_LEVEL=
Examples: "CONFEXT_LEVEL=2", "CONFEXT_LEVEL=15.14".
SYSEXT_SCOPE=
CONFEXT_SCOPE=
PORTABLE_PREFIXES=
Notes¶
If you are using this file to determine the OS or a specific version of it, use the ID and VERSION_ID fields, possibly with ID_LIKE as fallback for ID. When looking for an OS identification string for presentation to the user use the PRETTY_NAME field.
Note that operating system vendors may choose not to provide version information, for example to accommodate for rolling releases. In this case, VERSION and VERSION_ID may be unset. Applications should not rely on these fields to be set.
Operating system vendors may extend the file format and introduce new fields. It is highly recommended to prefix new fields with an OS specific name in order to avoid name clashes. Applications reading this file must ignore unknown fields.
Example: "DEBIAN_BTS="debbugs://bugs.debian.org/"".
Container and sandbox runtime managers may make the host's identification data available to applications by providing the host's /etc/os-release (if available, otherwise /usr/lib/os-release as a fallback) as /run/host/os-release.
EXAMPLES¶
Example 1. os-release file for Fedora Workstation
NAME=Fedora VERSION="32 (Workstation Edition)" ID=fedora VERSION_ID=32 PRETTY_NAME="Fedora 32 (Workstation Edition)" ANSI_COLOR="0;38;2;60;110;180" LOGO=fedora-logo-icon CPE_NAME="cpe:/o:fedoraproject:fedora:32" HOME_URL="https://fedoraproject.org/" DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f32/system-administrators-guide/" SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help" BUG_REPORT_URL="https://bugzilla.redhat.com/" REDHAT_BUGZILLA_PRODUCT="Fedora" REDHAT_BUGZILLA_PRODUCT_VERSION=32 REDHAT_SUPPORT_PRODUCT="Fedora" REDHAT_SUPPORT_PRODUCT_VERSION=32 PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy" VARIANT="Workstation Edition" VARIANT_ID=workstation
Example 2. extension-release file for an extension for Fedora Workstation 32
ID=fedora VERSION_ID=32
Example 3. Reading os-release in sh(1)
#!/bin/sh -eu # SPDX-License-Identifier: MIT-0 test -e /etc/os-release && os_release='/etc/os-release' || os_release='/usr/lib/os-release' . "${os_release}" echo "Running on ${PRETTY_NAME:-Linux}" if [ "${ID:-linux}" = "debian" ] || [ "${ID_LIKE#*debian*}" != "${ID_LIKE}" ]; then
echo "Looks like Debian!" fi
Example 4. Reading os-release in python(1) (versions >= 3.10)
#!/usr/bin/python # SPDX-License-Identifier: MIT-0 import platform os_release = platform.freedesktop_os_release() pretty_name = os_release.get('PRETTY_NAME', 'Linux') print(f'Running on {pretty_name!r}') if 'fedora' in [os_release.get('ID', 'linux'),
*os_release.get('ID_LIKE', '').split()]:
print('Looks like Fedora!')
See docs for platform.freedesktop_os_release[7] for more details.
Example 5. Reading os-release in python(1) (any version)
#!/usr/bin/python # SPDX-License-Identifier: MIT-0 import ast import re import sys def read_os_release():
try:
filename = '/etc/os-release'
f = open(filename)
except FileNotFoundError:
filename = '/usr/lib/os-release'
f = open(filename)
for line_number, line in enumerate(f, start=1):
line = line.rstrip()
if not line or line.startswith('#'):
continue
m = re.match(r'([A-Z][A-Z_0-9]+)=(.*)', line)
if m:
name, val = m.groups()
if val and val[0] in '"\'':
val = ast.literal_eval(val)
yield name, val
else:
print(f'{filename}:{line_number}: bad line {line!r}',
file=sys.stderr) os_release = dict(read_os_release()) pretty_name = os_release.get('PRETTY_NAME', 'Linux') print(f'Running on {pretty_name!r}') if 'debian' in [os_release.get('ID', 'linux'),
*os_release.get('ID_LIKE', '').split()]:
print('Looks like Debian!')
Note that the above version that uses the built-in implementation is preferred in most cases, and the open-coded version here is provided for reference.
SEE ALSO¶
systemd(1), lsb_release(1), hostname(5), machine-id(5), machine-info(5)
NOTES¶
- 1.
- Announcement of /etc/os-release
- 2.
- initrd
- 3.
- Portable Services Documentation
- 4.
- Common Platform Enumeration Specification
- 5.
- RFC3986 format
- 6.
- freedesktop.org Icon Theme Specification
- 7.
-
platform.freedesktop_os_release
systemd 254 |