dasharo/systemd
0
0
Fork 0
mirror of https://github.com/Dasharo/systemd.git synced 2026-03-06 15:02:31 -08:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #24799 from poettering/initrd-ftw

Browse Source 
use "initrd" rather than "initial RAM disk" or "initramfs" to refernce the concept
This commit is contained in:
Luca Boccassi
2022-09-23 20:43:15 +01:00
committed by GitHub
parent 354dc913c5 55c041b4e4
commit 542e6eb38d
32 changed files with 123 additions and 138 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
catalog/systemd.catalog.in
View File

@@ -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.

4
docs/CREDENTIALS.md
View File

@@ -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

27
docs/INITRD_INTERFACE.md
View File

@@ -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.`

12
docs/RANDOM_SEEDS.md
View File

@@ -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

20
docs/ROOT_STORAGE_DAEMONS.md
View File

@@ -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

2
docs/UIDS-GIDS.md
View File

@@ -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

14
man/bootup.xml
View File

@@ -31,9 +31,9 @@
boot loader will then invoke an OS kernel from disk (or the network). On systems using EFI or other types
of firmware, this firmware may also load the kernel directly.</para>
<para>The kernel (optionally) mounts an in-memory file system, often generated by
<citerefentry project='man-pages'><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
which looks for the root file system. Nowadays this is implemented as an "initramfs" — a compressed CPIO
<para>The kernel (optionally) mounts an in-memory file system, often generated by <citerefentry
project='man-pages'><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>, which
looks for the root file system. Nowadays this is implemented as an "initramfs" — a compressed CPIO
archive that the kernel extracts into a tmpfs. In the past normal file systems using an in-memory block
device (ramdisk) were used, and the name "initrd" is still used to describe both concepts. It's the boot
loader or the firmware that loads both the kernel and initrd/initramfs images into memory, but the kernel
@@ -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>.

6
man/crypttab.xml
View File

@@ -733,7 +733,7 @@
<varlistentry>
<term><option>x-initrd.attach</option></term>
<listitem><para>Setup this encrypted block device in the initramfs, similarly to
<listitem><para>Setup this encrypted block device in the initrd, similarly to
<citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>
units marked with <option>x-initrd.mount</option>.</para>
@@ -744,8 +744,8 @@
use. With this option the device will still be detached but later after the root file
system is unmounted.</para>
<para>All other encrypted block devices that contain file systems mounted in the initramfs
should use this option.</para>
<para>All other encrypted block devices that contain file systems mounted in the initrd should use
this option.</para>
</listitem>
</varlistentry>

10
man/localectl.xml
View File

@@ -48,11 +48,11 @@
such as the display manager, as well as the default for users
after login.</para>
<para>Note that the changes performed using this tool might require
the initramfs to be rebuilt to take effect during early system boot.
The initramfs is not rebuilt automatically by <filename>localectl</filename>,
this task has to be performed manually, usually using a tool like
<citerefentry project='man-pages'><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
<para>Note that the changes performed using this tool might require the initrd to be rebuilt to take
effect during early system boot. The initrd is not rebuilt automatically by
<filename>localectl</filename>, this task has to be performed manually, usually using a tool like
<citerefentry
project='man-pages'><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
</para>
<para>Note that

8
man/systemd-analyze.xml
View File

@@ -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>

4
man/systemd-creds.xml
View File

@@ -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

15
man/systemd-fsck@.service.xml
View File

@@ -31,15 +31,12 @@
<refsect1>
<title>Description</title>
<para><filename>systemd-fsck@.service</filename> and
<filename>systemd-fsck-root.service</filename> are services
responsible for file system checks. They are instantiated for each
device that is configured for file system checking.
<filename>systemd-fsck-root.service</filename> is responsible for
file system checks on the root file system, but only if the
root filesystem was not checked in the initramfs.
<filename>systemd-fsck@.service</filename> is used for all other
file systems and for the root file system in the initramfs.</para>
<para><filename>systemd-fsck@.service</filename> and <filename>systemd-fsck-root.service</filename> are
services responsible for file system checks. They are instantiated for each device that is configured for
file system checking. <filename>systemd-fsck-root.service</filename> is responsible for file system
checks on the root file system, but only if the root filesystem was not checked in the initrd.
<filename>systemd-fsck@.service</filename> is used for all other file systems and for the root file
system in the initrd.</para>
<para>These services are started at boot if
<option>passno</option> in <filename>/etc/fstab</filename> for the

4
man/systemd-measure.xml
View File

@@ -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

12
man/systemd-networkd.service.xml
View File

@@ -54,13 +54,11 @@
<citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
</para>
<para>When <filename>systemd-networkd</filename> exits, it generally leaves
existing network devices and configuration intact. This makes it possible to
transition from the initramfs and to restart the service without breaking
connectivity. This also means that when configuration is updated and
<filename>systemd-networkd</filename> is restarted, netdev interfaces for
which configuration was removed will not be dropped, and may need to be
cleaned up manually.</para>
<para>When <filename>systemd-networkd</filename> exits, it generally leaves existing network devices and
configuration intact. This makes it possible to transition from the initrd and to restart the service
without breaking connectivity. This also means that when configuration is updated and
<filename>systemd-networkd</filename> is restarted, netdev interfaces for which configuration was removed
will not be dropped, and may need to be cleaned up manually.</para>
<para><command>systemd-networkd</command> may be introspected and controlled at runtime using
<citerefentry><refentrytitle>networkctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.

8
man/systemd-veritysetup-generator.xml
View File

@@ -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>

7
man/systemd-volatile-root.service.xml
View File

@@ -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>

7
man/systemd.generator.xml
View File

@@ -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>

4
man/systemd.journal-fields.xml
View File

@@ -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>

5
man/systemd.mount.xml
View File

@@ -421,9 +421,8 @@
<varlistentry>
<term><option>x-initrd.mount</option></term>
<listitem><para>An additional filesystem to be mounted in the
initramfs. See <filename>initrd-fs.target</filename>
description in
<listitem><para>An additional filesystem to be mounted in the initrd. See
<filename>initrd-fs.target</filename> description in
<citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
</para></listitem>
</varlistentry>

4
man/systemd.special.xml
View File

@@ -372,8 +372,8 @@
<varlistentry>
<term><filename>initrd.target</filename></term>
<listitem>
<para>This is the default target in the initramfs, similar to <filename>default.target</filename>
in the main system. It is used to mount the real root and transition to it. See
<para>This is the default target in the initrd, similar to <filename>default.target</filename> in
the main system. It is used to mount the real root and transition to it. See
<citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
more discussion.</para>
</listitem>

Some files were not shown because too many files have changed in this diff Show More