Identify the Initrd Phase with initrd-release

A script that behaves differently in early boot than in the running system needs one reliable question answered: am I in an initrd right now? initrd-release documents the file that answers it. You will finish able to tell whether a process is looking at an initrd, read the metadata that identifies that early-boot environment, and check the symlink arrangement systemd expects. The examples match the installed systemd 255.4-1ubuntu8.17 package on this machine.

Allow about fifteen minutes. You need a shell and read access to the filesystem being inspected. Most steps are ordinary, read-only commands. Writing an initrd or changing files under /etc needs elevated privileges and sits outside the safe inspection workflow here.

1. Check the local contract

Read the installed manual page first. This confirms which behaviour your machine documents, rather than relying on a distribution-specific memory:

$ man 5 initrd-release

On this host, the page is provided by systemd 255.4-1ubuntu8.17:

$ dpkg-query -W -f='${Package} ${Version}\n' systemd
systemd 255.4-1ubuntu8.17
$ systemd --version | head -n 1
systemd 255 (255.4-1ubuntu8.17)

2. Detect whether the current root is an initrd

The presence of /etc/initrd-release is the phase marker. Test that path directly, instead of inferring the phase from a kernel command line, a process name or a guessed directory:

$ if [ -e /etc/initrd-release ]; then
>     printf 'initrd phase\n'
> else
>     printf 'main system phase\n'
> fi
main system phase

The output above is expected on the installed host used for this guide, because that host has no /etc/initrd-release. In an initrd, the same check prints initrd phase. This is a read-only test and needs no sudo.

Do not treat a missing file as proof that an initrd was never used. The check describes the filesystem root visible to the process at that moment. After the real root filesystem is mounted and the system switches out of the initrd, the file may no longer be visible at /etc/initrd-release.

3. Read metadata without executing it

The file contains newline-separated variable assignments such as ID=ubuntu and VERSION_ID=24.04. Values may be quoted, comments and blank lines are allowed, and variable expansion is explicitly not part of the format. Inspect it as data:

$ sed -n '1,120p' /etc/initrd-release
PRETTY_NAME="Example Linux initrd"
NAME="Example Linux"
ID=example
VERSION_ID=1.2

The values are illustrative: your initrd's output is controlled by whatever built it. If the file is absent, the command fails with a normal read error; go back to step 2 rather than substituting /etc/os-release from the host.

For a quick, field-specific check, use a text filter rather than sourcing the file:

$ sed -n -E \
>   -e '/^(NAME|ID|VERSION_ID|PRETTY_NAME)=/p' \
>   /etc/initrd-release
NAME="Example Linux"
ID=example
VERSION_ID=1.2
PRETTY_NAME="Example Linux initrd"

4. Check the compatibility symlink

Programs that only look for /etc/os-release must still see the initrd metadata. The systemd contract says that, inside the initrd, /etc/os-release should be symlinked to /etc/initrd-release, or the reverse. Inspect the link without following it:

$ ls -l /etc/os-release /etc/initrd-release
lrwxrwxrwx 1 root root 19 Jan  1 00:00 /etc/os-release -> initrd-release
-rw-r--r-- 1 root root 142 Jan  1 00:00 /etc/initrd-release
$ readlink /etc/os-release
initrd-release

The names, owner, size and timestamp in that output are examples. What matters is that one path is a symlink to the other. A relative link is deliberate: it keeps working when the filesystem is viewed from a chroot or an initrd. An absolute link such as /usr/lib/os-release can point outside the image while the root is being assembled.

On the normal booted host, check the vendor file separately:

$ readlink /etc/os-release
../usr/lib/os-release
$ sed -n '1,20p' /usr/lib/os-release
PRETTY_NAME="Ubuntu 24.04.5 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"

Do not rewrite this link or edit the vendor metadata as a troubleshooting shortcut. Those files are meant to be available from the root filesystem early in boot, and are generally defined by the operating system vendor. If your initrd image has the wrong arrangement, fix the image-building input or generator, then rebuild it through that distribution's documented process.

5. Keep machine decisions on machine-readable fields

Use ID, VERSION_ID, and, where relevant, VARIANT_ID for programmatic decisions. Use NAME and PRETTY_NAME for display. A value such as VARIANT="Rescue Edition" is presentation text, not the stable switch for an automated boot decision.

Do not combine both release files. The documented lookup order is to use /etc/os-release if it exists and fall back to /usr/lib/os-release only when it does not. Reading both and merging keys can produce a hybrid identity. Also avoid duplicate keys: the format forbids them, even though readers are expected to handle later duplicates in a shell-like way.

When you need to compare two environments, run the same checks from each one and record the complete file paths. A host-side /etc/os-release tells you about the host root; it does not automatically describe an initrd stored elsewhere.

6. Recover from a failed or incomplete check

If /etc/initrd-release is missing in an environment that should be an initrd, stop before changing files. Confirm the root you are inspecting:

$ findmnt -no TARGET,FSTYPE,OPTIONS /
/ ext4 rw,relatime
$ test -e /etc/initrd-release; printf 'status: %s\n' "$?"
status: 1

The exact filesystem and mount options vary. The failed test only says that the current root does not contain the marker. Check the initrd image contents with your distribution's own image tooling, or boot into the intended early-boot environment and repeat step 2. Avoid creating an ad hoc marker on the running host: that would falsely identify the host as an initrd and could mislead boot-time programs.