mirror of
https://github.com/systemd/systemd.git
synced 2025-01-18 10:04:04 +03:00
tree-wide: also settle on "initrd" instead of "initial RAM disk"
With this the concept is now called the same way everywhere except where historical info is relevant or where the other names are API.
This commit is contained in:
Lennart Poettering
parent
32e2767080
commit
55c041b4e4
@ -144,7 +144,7 @@ might still be busy with completing start-up.
|
||||
|
||||
Kernel start-up required @KERNEL_USEC@ microseconds.
|
||||
|
||||
Initial RAM disk start-up required @INITRD_USEC@ microseconds.
|
||||
initrd start-up required @INITRD_USEC@ microseconds.
|
||||
|
||||
Userspace start-up required @USERSPACE_USEC@ microseconds.
|
||||
|
||||
|
||||
@ -282,8 +282,8 @@ services where they are ultimately consumed.
|
||||
EFI System Partition, which are then picked up by `systemd-stub` and passed
|
||||
to the kernel and ultimately userspace where systemd receives them. This is
|
||||
useful to implement secure parameterization of vendor-built and signed
|
||||
initial RAM disks, as userspace can place credentials next to these EFI
|
||||
kernels, and be sure they can be accessed securely from initrd context.
|
||||
initrds, as userspace can place credentials next to these EFI kernels, and
|
||||
be sure they can be accessed securely from initrd context.
|
||||
|
||||
Credentials passed to the system may be enumerated/displayed via `systemd-creds
|
||||
--system`. They may also be propagated down to services, via the
|
||||
|
||||
@ -8,15 +8,16 @@ SPDX-License-Identifier: LGPL-2.1-or-later
|
||||
|
||||
# The initrd Interface of systemd
|
||||
|
||||
The Linux initrd mechanism (short for "initial RAM disk") refers to a small
|
||||
file system archive that is unpacked by the kernel and contains the first
|
||||
userspace code that runs. It typically finds and transitions into the actual
|
||||
root file system to use. systemd supports both initrd and initrd-less boots. If
|
||||
an initrd is used, it is a good idea to pass a few bits of runtime information
|
||||
from the initrd to systemd in order to avoid duplicate work and to provide
|
||||
performance data to the administrator. In this page we attempt to roughly
|
||||
describe the interfaces that exist between the initrd and systemd. These
|
||||
interfaces are currently used by dracut and the ArchLinux initrds.
|
||||
The Linux initrd mechanism (short for "initial RAM disk", also known as
|
||||
"initramfs") refers to a small file system archive that is unpacked by the
|
||||
kernel and contains the first userspace code that runs. It typically finds and
|
||||
transitions into the actual root file system to use. systemd supports both
|
||||
initrd and initrd-less boots. If an initrd is used, it is a good idea to pass a
|
||||
few bits of runtime information from the initrd to systemd in order to avoid
|
||||
duplicate work and to provide performance data to the administrator. In this
|
||||
page we attempt to roughly describe the interfaces that exist between the
|
||||
initrd and systemd. These interfaces are currently used by dracut and the
|
||||
ArchLinux initrds.
|
||||
|
||||
* The initrd should mount `/run/` as a tmpfs and pass it pre-mounted when
|
||||
jumping into the main system when executing systemd. The mount options should
|
||||
@ -57,10 +58,10 @@ It's all already implemented there!
|
||||
It is also possible and recommended to implement the initrd itself based on
|
||||
systemd. Here are a few terse notes:
|
||||
|
||||
* Provide `/etc/initrd-release` in the initrd image. The idea is that it follows
|
||||
the same format as the usual `/etc/os-release` but describes the initial RAM
|
||||
disk implementation rather than the OS. systemd uses the existence of this
|
||||
file as a flag whether to run in initial RAM disk mode, or not.
|
||||
* Provide `/etc/initrd-release` in the initrd image. The idea is that it
|
||||
follows the same format as the usual `/etc/os-release` but describes the
|
||||
initrd implementation rather than the OS. systemd uses the existence of this
|
||||
file as a flag whether to run in initrd mode, or not.
|
||||
|
||||
* When run in initrd mode, systemd and its components will read a couple of
|
||||
additional command line arguments, which are generally prefixed with `rd.`
|
||||
|
||||
@ -102,9 +102,9 @@ random bytes will either be delayed, will fail or result in a noisy kernel log
|
||||
message (see above).
|
||||
|
||||
Various other components run during early boot that require random bytes. For
|
||||
example, initial RAM disks nowadays communicate with encrypted networks or
|
||||
access encrypted storage which might need random numbers. systemd itself
|
||||
requires random numbers as well, including for the following uses:
|
||||
example, initrds nowadays communicate with encrypted networks or access
|
||||
encrypted storage which might need random numbers. systemd itself requires
|
||||
random numbers as well, including for the following uses:
|
||||
|
||||
* systemd assigns 'invocation' UUIDs to all services it invokes that uniquely
|
||||
identify each invocation. This is useful retain a global handle on a specific
|
||||
@ -174,9 +174,9 @@ boot, in order to ensure the entropy pool is filled up quickly.
|
||||
be enabled by setting the `$SYSTEMD_RANDOM_SEED_CREDIT` environment variable
|
||||
for the service to `1` (or even `force`, see man page). Note however, that
|
||||
this service typically runs relatively late during early boot: long after
|
||||
the initial RAM disk (`initrd`) completed, and after the `/var/` file system
|
||||
became writable. This is usually too late for many applications, it is hence
|
||||
not advised to rely exclusively on this functionality to seed the kernel's
|
||||
the initrd completed, and after the `/var/` file system became
|
||||
writable. This is usually too late for many applications, it is hence not
|
||||
advised to rely exclusively on this functionality to seed the kernel's
|
||||
entropy pool. Also note that this service synchronously waits until the
|
||||
kernel's entropy pool is initialized before completing start-up. It may thus
|
||||
be used by other services as synchronization point to order against, if they
|
||||
|
||||
@ -22,16 +22,16 @@ is not.
|
||||
## A Bit of Background
|
||||
|
||||
When complex storage technologies are used as backing for the root file system
|
||||
this needs to be set up by the initial RAM file system (initrd), i.e. on Fedora
|
||||
by Dracut. In newer systemd versions tear-down of the root file system backing
|
||||
is also done by the initrd: after terminating all remaining running processes
|
||||
and unmounting all file systems it can (which means excluding the root fs)
|
||||
systemd will jump back into the initrd code allowing it to unmount the final
|
||||
file systems (and its storage backing) that could not be unmounted as long as
|
||||
the OS was still running from the main root file system. The initrd' job is to
|
||||
detach/unmount the root fs, i.e. inverting the exact commands it used to set
|
||||
them up in the first place. This is not only cleaner, but also allows for the
|
||||
first time arbitrary complex stacks of storage technology.
|
||||
this needs to be set up by the initrd, i.e. on Fedora by Dracut. In newer
|
||||
systemd versions tear-down of the root file system backing is also done by the
|
||||
initrd: after terminating all remaining running processes and unmounting all
|
||||
file systems it can (which means excluding the root fs) systemd will jump back
|
||||
into the initrd code allowing it to unmount the final file systems (and its
|
||||
storage backing) that could not be unmounted as long as the OS was still
|
||||
running from the main root file system. The initrd' job is to detach/unmount
|
||||
the root fs, i.e. inverting the exact commands it used to set them up in the
|
||||
first place. This is not only cleaner, but also allows for the first time
|
||||
arbitrary complex stacks of storage technology.
|
||||
|
||||
Previous attempts to handle root file system setups with complex storage as
|
||||
backing usually tried to maintain the root storage with program code stored on
|
||||
|
||||
@ -73,7 +73,7 @@ Note that systemd requires that system users and groups are resolvable without
|
||||
networking available — a requirement that is not made for regular users. This
|
||||
means regular users may be stored in remote LDAP or NIS databases, but system
|
||||
users may not (except when there's a consistent local cache kept, that is
|
||||
available during earliest boot, including in the initial RAM disk).
|
||||
available during earliest boot, including in the initrd).
|
||||
|
||||
## Special `systemd` GIDs
|
||||
|
||||
|
||||
@ -200,10 +200,10 @@ emergency.service | | |
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Bootup in the Initial RAM Disk (initrd)</title>
|
||||
<para>The initial RAM disk implementation (initrd) can be set up
|
||||
using systemd as well. In this case, boot up inside the initrd
|
||||
follows the following structure.</para>
|
||||
<title>Bootup in the initrd</title>
|
||||
|
||||
<para>The initrd implementation can be set up using systemd as well. In this case, boot up inside the
|
||||
initrd follows the following structure.</para>
|
||||
|
||||
<para>systemd detects that it is run within an initrd by checking
|
||||
for the file <filename>/etc/initrd-release</filename>.
|
||||
|
||||
@ -156,10 +156,10 @@
|
||||
<title><command>systemd-analyze time</command></title>
|
||||
|
||||
<para>This command prints the time spent in the kernel before userspace has been reached, the time
|
||||
spent in the initial RAM disk (initrd) before normal system userspace has been reached, and the time
|
||||
normal system userspace took to initialize. Note that these measurements simply measure the time passed
|
||||
up to the point where all system services have been spawned, but not necessarily until they fully
|
||||
finished initialization or the disk is idle.</para>
|
||||
spent in the initrd before normal system userspace has been reached, and the time normal system
|
||||
userspace took to initialize. Note that these measurements simply measure the time passed up to the
|
||||
point where all system services have been spawned, but not necessarily until they fully finished
|
||||
initialization or the disk is idle.</para>
|
||||
|
||||
<example>
|
||||
<title><command>Show how long the boot took</command></title>
|
||||
|
||||
@ -304,8 +304,8 @@
|
||||
<para>The <option>-H</option> switch is a shortcut for <option>--with-key=host</option>. Similar,
|
||||
<option>-T</option> is a shortcut for <option>--with-key=tpm2</option>.</para>
|
||||
|
||||
<para>When encrypting credentials that shall be used in the initial RAM disk (initrd) where
|
||||
<filename>/var/lib/systemd/</filename> is typically not available make sure to use
|
||||
<para>When encrypting credentials that shall be used in the initrd (where
|
||||
<filename>/var/lib/systemd/</filename> is typically not available) make sure to use
|
||||
<option>--with-key=auto-initrd</option> mode, to disable binding against the host secret.</para>
|
||||
|
||||
<para>This switch has no effect on the <command>decrypt</command> command, as information on which
|
||||
|
||||
@ -35,8 +35,8 @@
|
||||
<para><command>systemd-measure</command> is a tool that may be used to pre-calculate and sign the
|
||||
expected TPM2 PCR 11 values that should be seen when a unified Linux kernel image based on
|
||||
<citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry> is
|
||||
booted up. It accepts paths to the ELF kernel image file, initial ram disk image file, devicetree file,
|
||||
kernel command line file,
|
||||
booted up. It accepts paths to the ELF kernel image file, initrd image file, devicetree file, kernel
|
||||
command line file,
|
||||
<citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry> file, boot
|
||||
splash file, and TPM2 PCR PEM public key file that make up the unified kernel image, and determines the
|
||||
PCR values expected to be in place after booting the image. Calculation starts with a zero-initialized
|
||||
|
||||
@ -51,10 +51,10 @@
|
||||
<term><varname>systemd.verity=</varname></term>
|
||||
<term><varname>rd.systemd.verity=</varname></term>
|
||||
|
||||
<listitem><para>Takes a boolean argument. Defaults to <literal>yes</literal>. If <literal>no</literal>,
|
||||
disables the generator entirely. <varname>rd.systemd.verity=</varname> is honored only by the initial RAM disk
|
||||
(initrd) while <varname>systemd.verity=</varname> is honored by both the host system and the
|
||||
initrd.</para></listitem>
|
||||
<listitem><para>Takes a boolean argument. Defaults to <literal>yes</literal>. If
|
||||
<literal>no</literal>, disables the generator entirely. <varname>rd.systemd.verity=</varname> is
|
||||
honored only by the initrd while <varname>systemd.verity=</varname> is honored by both the host
|
||||
system and the initrd.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
|
||||
@ -37,9 +37,10 @@
|
||||
stateless systems.</para>
|
||||
|
||||
<para>This service is only enabled if full volatile mode is selected, for example by specifying
|
||||
<literal>systemd.volatile=yes</literal> on the kernel command line. This service runs only in the initial RAM disk
|
||||
("initrd"), before the system transitions to the host's root directory. Note that this service is not used if
|
||||
<literal>systemd.volatile=state</literal> is used, as in that mode the root directory is non-volatile.</para>
|
||||
<literal>systemd.volatile=yes</literal> on the kernel command line. This service runs only in the initrdyes,
|
||||
before the system transitions to the host's root directory. Note that this service is not used if
|
||||
<literal>systemd.volatile=state</literal> is used, as in that mode the root directory is
|
||||
non-volatile.</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
|
||||
@ -148,10 +148,9 @@
|
||||
<varlistentry>
|
||||
<term><varname>$SYSTEMD_IN_INITRD</varname></term>
|
||||
|
||||
<listitem><para>If the generator is run as part of an initial RAM file system (initrd) this is set to
|
||||
<literal>1</literal>. If it is run from the regular host (i.e. after the transition from initrd to
|
||||
host) it is set to <literal>0</literal>. This environment variable is only set for system
|
||||
generators.</para></listitem>
|
||||
<listitem><para>If the generator is run as part of an initrd this is set to <literal>1</literal>. If
|
||||
it is run from the regular host (i.e. after the transition from initrd to host) it is set to
|
||||
<literal>0</literal>. This environment variable is only set for system generators.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
|
||||
@ -403,8 +403,8 @@
|
||||
|
||||
<listitem><para>A string field that specifies the runtime scope in which the message was logged. If
|
||||
<literal>initrd</literal>, the log message was processed while the system was running inside the
|
||||
initial RAM disk (initrd). If <literal>system</literal>, the log message was generated after the
|
||||
system switched execution to the host root filesystem.</para></listitem>
|
||||
initrd. If <literal>system</literal>, the log message was generated after the system switched
|
||||
execution to the host root filesystem.</para></listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
|
||||
@ -752,16 +752,12 @@
|
||||
<term><varname>systemd.unit=</varname></term>
|
||||
<term><varname>rd.systemd.unit=</varname></term>
|
||||
|
||||
<listitem><para>Overrides the unit to activate on boot.
|
||||
Defaults to <filename>default.target</filename>. This may be
|
||||
used to temporarily boot into a different boot unit, for
|
||||
example <filename>rescue.target</filename> or
|
||||
<filename>emergency.service</filename>. See
|
||||
<listitem><para>Overrides the unit to activate on boot. Defaults to
|
||||
<filename>default.target</filename>. This may be used to temporarily boot into a different boot unit,
|
||||
for example <filename>rescue.target</filename> or <filename>emergency.service</filename>. See
|
||||
<citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
|
||||
for details about these units. The option prefixed with
|
||||
<literal>rd.</literal> is honored only in the initial RAM disk
|
||||
(initrd), while the one that is not prefixed only in the main
|
||||
system.</para></listitem>
|
||||
for details about these units. The option prefixed with <literal>rd.</literal> is honored only in the
|
||||
initrd, while the one that is not prefixed only in the main system.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
|
||||
@ -1858,7 +1858,7 @@ static int do_reexecute(
|
||||
args[i++] = argv[j];
|
||||
assert(i <= args_size);
|
||||
|
||||
/* Re-enable any blocked signals, especially important if we switch from initial ramdisk to init=... */
|
||||
/* Re-enable any blocked signals, especially important if we switch from initrd to init=... */
|
||||
(void) reset_all_signal_handlers();
|
||||
(void) reset_signal_mask();
|
||||
(void) rlimit_nofile_safe();
|
||||
@ -2052,7 +2052,7 @@ static void log_execution_mode(bool *ret_first_boot) {
|
||||
|
||||
if (in_initrd()) {
|
||||
*ret_first_boot = false;
|
||||
log_info("Running in initial RAM disk.");
|
||||
log_info("Running in initrd.");
|
||||
} else {
|
||||
int r;
|
||||
_cleanup_free_ char *id_text = NULL;
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user