NAME
os-release, initrd-release, extension-release - Operating system identification
SYNOPSIS
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 that is missing. Applications should not combine the data from both files. /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.
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] and exitrd, /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/exitrd 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[3] page. 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 extension ID= option either matches the host ID= option or is included the host ID_LIKE= option, 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 does not 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.strictxattr(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.
Added in version 220.
VARIANT_ID=
Examples: "VARIANT_ID=server", "VARIANT_ID=embedded".
Added in version 220.
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".
Added in version 231.
BUILD_ID=
Examples: "BUILD_ID="2013-03-20.3"", "BUILD_ID=201303203".
Added in version 200.
IMAGE_ID=
Examples: "IMAGE_ID=vendorx-cashier-system", "IMAGE_ID=netbook-image".
Added in version 249.
IMAGE_VERSION=
Examples: "IMAGE_VERSION=33", "IMAGE_VERSION=47.1rc1".
Added in version 249.
RELEASE_TYPE=
If unset, or an unknown value, assume that the release is "stable".
Examples: "RELEASE_TYPE=development", "RELEASE_TYPE=lts".
Added in version 257.
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.
Added in version 252.
LOGO=
Examples: "LOGO=fedora-logo", "LOGO=distributor-logo-opensuse"
Added in version 240.
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.
Added in version 254.
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/"".
Added in version 254.
EXPERIMENT=
This description is intended to be exposed at system installation time, or in "About this system" UIs, to warn the user that they're installing/running an experimental build of the OS. If RELEASE_TYPE is "experiment" but this field is unset, the UI should still warn the user, but it will be unable to explain what exactly is experimental about the current build of the OS.
Examples: "EXPERIMENT="Switch to DNF5"" for an experimental build of Fedora Linux made to test DNF5, "EXPERIMENT="Port to Apple M3 chip"" for experimental builds of Asahi Linux ported to the Apple M3 SoC, "EXPERIMENT="Mutter !1441: Dynamic triple/double buffering (v4)"" for builds of GNOME OS created by Mutter's CI for merge request !1441.
Added in version 257.
EXPERIMENT_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, corresponding to the examples above in EXPERIMENT=: "EXPERIMENT_URL="https://fedoraproject.org/wiki/Changes/SwitchToDnf5"", "EXPERIMENT_URL="https://github.com/AsahiLinux/docs/wiki/M3-Series-Feature-Support"", "EXPERIMENT_URL="https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1441"".
Added in version 257.
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.
Added in version 248.
ARCHITECTURE=
Added in version 252.
SYSEXT_LEVEL=
Examples: "SYSEXT_LEVEL=2", "SYSEXT_LEVEL=15.14".
Added in version 248.
CONFEXT_LEVEL=
Examples: "CONFEXT_LEVEL=2", "CONFEXT_LEVEL=15.14".
Added in version 254.
SYSEXT_SCOPE=
Added in version 250.
CONFEXT_SCOPE=
Added in version 254.
PORTABLE_PREFIXES=
Added in version 250.
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=workstationExample 2. extension-release file for an extension for Fedora Workstation 32
ID=fedora
VERSION_ID=32Example 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
\n
echo "Looks like Debian!"
fiExample 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'),
\n
*os_release.get('ID_LIKE', '').split()]:
\n
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():
\n
try:
\n
filename = '/etc/os-release'
\n
f = open(filename)
\n
except FileNotFoundError:
\n
filename = '/usr/lib/os-release'
\n
f = open(filename)
\n
for line_number, line in enumerate(f, start=1):
\n
line = line.rstrip()
\n
if not line or line.startswith('#'):
\n
continue
\n
m = re.match(r'([A-Z][A-Z_0-9]+)=(.*)', line)
\n
if m:
\n
name, val = m.groups()
\n
if val and val[0] in '"\'':
\n
val = ast.literal_eval(val)
\n
yield name, val
\n
else:
\n
print(f'{filename}:{line_number}: bad line {line!r}',
\n
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'),
\n
*os_release.get('ID_LIKE', '').split()]:
\n
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
- 4.
Common Platform Enumeration Specification
- 5.
RFC3986 format
- 6.
freedesktop.org Icon Theme Specification
- 7.
platform.freedesktop_os_release