Identify the Initrd Phase with initrd-release

You will finish with a safe way to tell whether a process is looking at an initrd, inspect the metadata that identifies that early-boot environment, and check the symlink arrangement expected by systemd. 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 requires elevated privileges and is 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)

Checkpoint: the name is slightly misleading. initrd-release(5) is not a separate file format or a command. It documents the /etc/initrd-release file, which has the same role inside an initrd that /etc/os-release has in the booted operating system.

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 does not need 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: the output in your initrd is controlled by its builder and distribution. If the file is absent, the command fails with a normal read error; return 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"

Do not run . /etc/initrd-release or source /etc/initrd-release merely to read it. The documented syntax is shell-compatible variable assignment, but reading an identity file as shell code gives any unexpected shell input an execution path. A parser that understands the assignment format is safer for programs; for a one-off inspection, sed keeps the operation visibly read-only.

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. The useful result is that one path is a symlink to the other. A relative link is deliberate: it continues to work 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 when 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 according to 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 and is 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 environment 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 the image tooling used by your distribution, 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.

There is no undo step for this guide because every command is read-only. If you have already edited an initrd or release file while investigating, restore it from the image-building source or a known-good backup, then rebuild and verify the resulting image before rebooting.