mirror of
https://github.com/systemd/systemd
synced 2024-07-21 18:24:38 +00:00
Merge pull request #24799 from poettering/initrd-ftw
use "initrd" rather than "initial RAM disk" or "initramfs" to refernce the concept
This commit is contained in:
Luca Boccassi
GitHub
commit
542e6eb38d
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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>.
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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>.
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
12
man/udev.xml
12
man/udev.xml
|
|
@ -647,13 +647,11 @@
|
|||
<varlistentry>
|
||||
<term><option>db_persist</option></term>
|
||||
<listitem>
|
||||
<para>Set the flag (sticky bit) on the udev database entry
|
||||
of the event device. Device properties are then kept in the
|
||||
database even when
|
||||
<command>udevadm info --cleanup-db</command> is called.
|
||||
This option can be useful in certain cases
|
||||
(e.g. Device Mapper devices) for persisting device state
|
||||
on the transition from initramfs.</para>
|
||||
<para>Set the flag (sticky bit) on the udev database entry of the event device. Device
|
||||
properties are then kept in the database even when <command>udevadm info
|
||||
--cleanup-db</command> is called. This option can be useful in certain cases
|
||||
(e.g. Device Mapper devices) for persisting device state on the transition from
|
||||
initrd.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
|
|
|
|||
|
|
@ -149,7 +149,7 @@ This is based on crypttab(5).
|
|||
<varlistentry>
|
||||
<term><option>x-initrd.attach</option></term>
|
||||
|
||||
<listitem><para>Setup this verity protected block device in the initramfs, similarly to
|
||||
<listitem><para>Setup this verity protected 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>
|
||||
|
||||
|
|
@ -160,8 +160,8 @@ This is based on crypttab(5).
|
|||
use. With this option the device will still be detached but later after the root file
|
||||
system is unmounted.</para>
|
||||
|
||||
<para>All other verity protected block devices that contain file systems mounted in the
|
||||
initramfs should use this option.</para>
|
||||
<para>All other verity protected block devices that contain file systems mounted in the initrd should
|
||||
use this option.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
|
|
|||
|
|
@ -281,13 +281,14 @@ static int device_coldplug(Unit *u) {
|
|||
* other units, or (b) generated when uevents are received.
|
||||
*
|
||||
* - On switch-root, the udev database may be cleared, except for devices with sticky bit, i.e.
|
||||
* OPTIONS="db_persist". Hence, almost no devices are enumerated in the step 2. However, in general,
|
||||
* we have several serialized devices. So, DEVICE_FOUND_UDEV bit in the deserialized_found must be
|
||||
* ignored, as udev rules in initramfs and the main system are often different. If the deserialized
|
||||
* state is DEVICE_PLUGGED, we need to downgrade it to DEVICE_TENTATIVE. Unlike the other starting
|
||||
* mode, MANAGER_IS_SWITCHING_ROOT() is true when device_coldplug() and device_catchup() are called.
|
||||
* Hence, let's conditionalize the operations by using the flag. After switch-root, systemd-udevd
|
||||
* will (re-)process all devices, and the Device.found and Device.state will be adjusted.
|
||||
* OPTIONS="db_persist". Hence, almost no devices are enumerated in the step 2. However, in
|
||||
* general, we have several serialized devices. So, DEVICE_FOUND_UDEV bit in the deserialized_found
|
||||
* must be ignored, as udev rules in initrd and the main system are often different. If the
|
||||
* deserialized state is DEVICE_PLUGGED, we need to downgrade it to DEVICE_TENTATIVE. Unlike the
|
||||
* other starting mode, MANAGER_IS_SWITCHING_ROOT() is true when device_coldplug() and
|
||||
* device_catchup() are called. Hence, let's conditionalize the operations by using the
|
||||
* flag. After switch-root, systemd-udevd will (re-)process all devices, and the Device.found and
|
||||
* Device.state will be adjusted.
|
||||
*
|
||||
* - On reload or reexecute, we can trust enumerated_found, deserialized_found, and deserialized_state.
|
||||
* Of course, deserialized parameters may be outdated, but the unit state can be adjusted later by
|
||||
|
|
|
|||
|
|
@ -1660,7 +1660,7 @@ static void initialize_coredump(bool skip_setup) {
|
|||
|
||||
/* But at the same time, turn off the core_pattern logic by default, so that no coredumps are stored
|
||||
* until the systemd-coredump tool is enabled via sysctl. However it can be changed via the kernel
|
||||
* command line later so core dumps can still be generated during early startup and in initramfs. */
|
||||
* command line later so core dumps can still be generated during early startup and in initrd. */
|
||||
if (!skip_setup)
|
||||
disable_coredumps();
|
||||
#endif
|
||||
|
|
@ -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;
|
||||
|
|
|
|||
|
|
@ -114,7 +114,7 @@ static int run(const char *dest, const char *dest_early, const char *dest_late)
|
|||
|
||||
arg_dest = ASSERT_PTR(dest);
|
||||
|
||||
/* Don't even consider resuming outside of initramfs. */
|
||||
/* Don't even consider resuming outside of initrd. */
|
||||
if (!in_initrd()) {
|
||||
log_debug("Not running in an initrd, quitting.");
|
||||
return 0;
|
||||
|
|
|
|||
|
|
@ -706,8 +706,8 @@ static void context_determine_hostname_source(Context *c) {
|
|||
|
||||
/* If the hostname was not set by us, try to figure out where it came from. If we set it to
|
||||
* the default hostname, the file will tell us. We compare the string because it is possible
|
||||
* that the hostname was set by an older version that had a different fallback, in the
|
||||
* initramfs or before we reexecuted. */
|
||||
* that the hostname was set by an older version that had a different fallback, in the initrd
|
||||
* or before we reexecuted. */
|
||||
|
||||
r = read_one_line_file("/run/systemd/default-hostname", &fallback);
|
||||
if (r < 0 && r != -ENOENT)
|
||||
|
|
|
|||
|
|
@ -897,10 +897,8 @@ int device_update_db(sd_device *device) {
|
|||
if (r < 0)
|
||||
return r;
|
||||
|
||||
/*
|
||||
* set 'sticky' bit to indicate that we should not clean the
|
||||
* database when we transition from initramfs to the real root
|
||||
*/
|
||||
/* set 'sticky' bit to indicate that we should not clean the database when we transition from initrd
|
||||
* to the real root */
|
||||
if (fchmod(fileno(f), device->db_persist ? 01644 : 0644) < 0) {
|
||||
r = -errno;
|
||||
goto fail;
|
||||
|
|
|
|||
|
|
@ -1270,10 +1270,9 @@ int setup_pivot_root(const char *directory, const char *pivot_root_new, const ch
|
|||
* This requires a temporary directory, pivot_tmp, which is
|
||||
* not a child of either.
|
||||
*
|
||||
* This is typically used for OSTree-style containers, where
|
||||
* the root partition contains several sysroots which could be
|
||||
* run. Normally, one would be chosen by the bootloader and
|
||||
* pivoted to / by initramfs.
|
||||
* This is typically used for OSTree-style containers, where the root partition contains several
|
||||
* sysroots which could be run. Normally, one would be chosen by the bootloader and pivoted to / by
|
||||
* initrd.
|
||||
*
|
||||
* For example, for an OSTree deployment, pivot_root_new
|
||||
* would be: /ostree/deploy/$os/deploy/$checksum. Note that this
|
||||
|
|
|
|||
|
|
@ -330,11 +330,9 @@ TEST(environment_gathering) {
|
|||
assert_se(chmod(name2, 0755) == 0);
|
||||
assert_se(chmod(name3, 0755) == 0);
|
||||
|
||||
/* When booting in containers or without initramfs there might not be
|
||||
* any PATH in the environment and if there is no PATH /bin/sh built-in
|
||||
* PATH may leak and override systemd's DEFAULT_PATH which is not
|
||||
* good. Force our own PATH in environment, to prevent expansion of sh
|
||||
* built-in $PATH */
|
||||
/* When booting in containers or without initrd there might not be any PATH in the environment and if
|
||||
* there is no PATH /bin/sh built-in PATH may leak and override systemd's DEFAULT_PATH which is not
|
||||
* good. Force our own PATH in environment, to prevent expansion of sh built-in $PATH */
|
||||
old = getenv("PATH");
|
||||
r = setenv("PATH", "no-sh-built-in-path", 1);
|
||||
assert_se(r >= 0);
|
||||
|
|
|
|||
|
|
@ -98,8 +98,8 @@ INTERACTIVE_DEBUG=1
|
|||
(e.g. by setting a usable default terminal, suppressing the shutdown after
|
||||
the test, etc.)
|
||||
|
||||
The kernel and initramfs can be specified with $KERNEL_BIN and $INITRD.
|
||||
(Fedora's or Debian's default kernel path and initramfs are used by default)
|
||||
The kernel and initrd can be specified with $KERNEL_BIN and $INITRD. (Fedora's
|
||||
or Debian's default kernel path and initrd are used by default)
|
||||
|
||||
A script will try to find your qemu binary. If you want to specify a different
|
||||
one with $QEMU_BIN.
|
||||
|
|
|
|||
|
|
@ -2716,7 +2716,7 @@ inst() {
|
|||
# inst_any -d /bin/foo /bin/bar /bin/baz
|
||||
#
|
||||
# Lets assume that /bin/baz exists, so it will be installed as /bin/foo in
|
||||
# initramfs.
|
||||
# initrd.
|
||||
inst_any() {
|
||||
local dest file
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue