1
1
mirror of https://github.com/systemd/systemd-stable.git synced 2024-12-22 13:33:56 +03:00

man: "the initial RAM disk" → "the initrd"

In many places we spelled out the phrase behind "initrd" in full, but this
isn't terribly useful. In fact, no "RAM disk" is used, so emphasizing this
is just confusing to the reader. Let's just say "initrd" everywhere, people
understand what this refers to, and that it's in fact an initramfs image.

Also, s/i.e./e.g./ where appropriate.

Also, don't say "in RAM", when in fact it's virtual memory, whose pages
may or may not be loaded in page frames in RAM, and we have no control over
this.

Also, add <filename></filename> and other minor cleanups.
This commit is contained in:
Zbigniew Jędrzejewski-Szmek 2022-09-15 13:43:59 +01:00
parent 483bf5643a
commit b66a6e1a58
18 changed files with 143 additions and 158 deletions

View File

@ -319,11 +319,11 @@
<term><option>--make-entry-directory=yes|no</option></term> <term><option>--make-entry-directory=yes|no</option></term>
<listitem><para>Controls creation and deletion of the <ulink <listitem><para>Controls creation and deletion of the <ulink
url="https://systemd.io/BOOT_LOADER_SPECIFICATION">Boot Loader Specification</ulink> Type #1 entry url="https://systemd.io/BOOT_LOADER_SPECIFICATION">Boot Loader Specification</ulink> Type #1 entry
directory on the file system containing resources such as kernel images and initial RAM disk images directory on the file system containing resources such as kernel and initrd images during
during <option>install</option> and <option>remove</option>, respectively. The directory is named <option>install</option> and <option>remove</option>, respectively. The directory is named after the
after the entry token, as specified with <option>--entry-token=</option> parameter described below, entry token, as specified with <option>--entry-token=</option> parameter described below, and is
and is placed immediately below the <varname>$BOOT</varname> root directory (i.e. beneath the file placed immediately below the <varname>$BOOT</varname> root directory (i.e. beneath the file system
system returned by the <option>--print-boot-path</option> option, see above). Defaults to returned by the <option>--print-boot-path</option> option, see above). Defaults to
<literal>no</literal>.</para></listitem> <literal>no</literal>.</para></listitem>
</varlistentry> </varlistentry>

View File

@ -33,13 +33,13 @@
<para>The kernel (optionally) mounts an in-memory file system, often generated by <para>The kernel (optionally) mounts an in-memory file system, often generated by
<citerefentry project='man-pages'><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
which looks for the root file system. Nowadays this is usually implemented as an initramfs — a compressed which looks for the root file system. Nowadays this is implemented as an "initramfs" — a compressed CPIO
archive which is extracted when the kernel boots up into a lightweight in-memory file system based on archive that the kernel extracts into a tmpfs. In the past normal file systems using an in-memory block
tmpfs, but in the past normal file systems using an in-memory block device (ramdisk) were used, and the device (ramdisk) were used, and the name "initrd" is still used to describe both concepts. It's the boot
name "initrd" is still used to describe both concepts. It's the boot loader or the firmware that loads loader or the firmware that loads both the kernel and initrd/initramfs images into memory, but the kernel
both the kernel and initrd/initramfs images into memory, but the kernel which interprets it as a file which interprets it as a file system.
system. <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> may <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> may be used
be used to manage services in the initrd, similarly to the real system.</para> to manage services in the initrd, similarly to the real system.</para>
<para>After the root file system is found and mounted, the initrd hands over control to the host's system <para>After the root file system is found and mounted, the initrd hands over control to the host's system
manager (such as manager (such as

View File

@ -27,8 +27,8 @@
<refsect1> <refsect1>
<title>Description</title> <title>Description</title>
<para>The kernel, the initial RAM disk (initrd) and basic userspace functionality may be configured at <para>The kernel, the programs running in the initrd and in the host system may be configured at boot via
boot via kernel command line arguments. In addition, various systemd tools look at the EFI variable kernel command line arguments. In addition, various systemd tools look at the EFI variable
<literal>SystemdOptions</literal> (if available). Both sources are combined, but the kernel command line <literal>SystemdOptions</literal> (if available). Both sources are combined, but the kernel command line
has higher priority. Please note that <emphasis>the EFI variable is only used by systemd tools, and is has higher priority. Please note that <emphasis>the EFI variable is only used by systemd tools, and is
ignored by the kernel and other user space tools</emphasis>, so it is not a replacement for the kernel ignored by the kernel and other user space tools</emphasis>, so it is not a replacement for the kernel
@ -40,8 +40,7 @@
and and
<citerefentry project='man-pages'><refentrytitle>bootparam</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para> <citerefentry project='man-pages'><refentrytitle>bootparam</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
<para>For command line parameters understood by the initial RAM <para>For command line parameters understood by the initrd, see
disk, please see
<citerefentry project='man-pages'><refentrytitle>dracut.cmdline</refentrytitle><manvolnum>7</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>dracut.cmdline</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
or the documentation of the specific initrd implementation of your or the documentation of the specific initrd implementation of your
installation.</para> installation.</para>

View File

@ -18,7 +18,7 @@
<refnamediv> <refnamediv>
<refname>kernel-install</refname> <refname>kernel-install</refname>
<refpurpose>Add and remove kernel and initramfs images to and from /boot</refpurpose> <refpurpose>Add and remove kernel and initrd images to and from /boot</refpurpose>
</refnamediv> </refnamediv>
<refsynopsisdiv> <refsynopsisdiv>
@ -34,10 +34,15 @@
<refsect1> <refsect1>
<title>Description</title> <title>Description</title>
<para><command>kernel-install</command> is used to install and remove kernel and initramfs images to and <para><command>kernel-install</command> is used to install and remove kernel and initrd images
from the boot loader partition, referred to as <varname>$BOOT</varname> here. It will usually be one of <footnote>
<filename>/boot/</filename>, <filename>/efi/</filename>, or <filename>/boot/efi/</filename>, see below. <para>Nowadays actually CPIO archives used as an "initramfs", rather than "initrd". See
</para> <citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry> for an
explanation.</para>
</footnote>
to and from the boot loader partition, referred to as <varname>$BOOT</varname> here. It will usually be
one of <filename>/boot/</filename>, <filename>/efi/</filename>, or <filename>/boot/efi/</filename>, see
below.</para>
<para><command>kernel-install</command> will run the executable files ("plugins") located in the <para><command>kernel-install</command> will run the executable files ("plugins") located in the
directory <filename>/usr/lib/kernel/install.d/</filename> and the local administration directory directory <filename>/usr/lib/kernel/install.d/</filename> and the local administration directory
@ -63,16 +68,16 @@
<varlistentry> <varlistentry>
<term><command>add <replaceable>KERNEL-VERSION</replaceable> <replaceable>KERNEL-IMAGE</replaceable> [<replaceable>INITRD-FILE</replaceable> ...]</command></term> <term><command>add <replaceable>KERNEL-VERSION</replaceable> <replaceable>KERNEL-IMAGE</replaceable> [<replaceable>INITRD-FILE</replaceable> ...]</command></term>
<listitem> <listitem>
<para>This command expects a kernel version string and a path to a kernel image file as <para>This command expects a kernel version string and a path to a kernel image file as arguments.
arguments. Optionally, one or more initial RAM disk images may be specified as well (note that Optionally, one or more initrd images may be specified as well (note that plugins might generate
plugins might generate additional ones). <command>kernel-install</command> calls the executable additional ones). <command>kernel-install</command> calls the executable files from
files from <filename>/usr/lib/kernel/install.d/*.install</filename> and <filename>/usr/lib/kernel/install.d/*.install</filename> and
<filename>/etc/kernel/install.d/*.install</filename> (i.e. the plugins) with the following <filename>/etc/kernel/install.d/*.install</filename> (i.e. the plugins) with the following
arguments:</para> arguments:</para>
<programlisting>add <replaceable>KERNEL-VERSION</replaceable> <filename>$BOOT/<replaceable>ENTRY-TOKEN</replaceable>/<replaceable>KERNEL-VERSION</replaceable>/</filename> <replaceable>KERNEL-IMAGE</replaceable> [<replaceable>INITRD-FILE</replaceable> ...]</programlisting> <programlisting>add <replaceable>KERNEL-VERSION</replaceable> <filename>$BOOT/<replaceable>ENTRY-TOKEN</replaceable>/<replaceable>KERNEL-VERSION</replaceable>/</filename> <replaceable>KERNEL-IMAGE</replaceable> [<replaceable>INITRD-FILE</replaceable> ...]</programlisting>
<para>The third argument directly refers to the path where to place kernel images, initial RAM disk <para>The third argument directly refers to the path where to place kernel images, initrd
images and other resources for <ulink url="https://systemd.io/BOOT_LOADER_SPECIFICATION">Boot images and other resources for <ulink url="https://systemd.io/BOOT_LOADER_SPECIFICATION">Boot
Loader Specification</ulink> Type #1 entries (the "entry directory"). If other boot loader schemes Loader Specification</ulink> Type #1 entries (the "entry directory"). If other boot loader schemes
are used the parameter may be ignored. The <replaceable>ENTRY-TOKEN</replaceable> string is are used the parameter may be ignored. The <replaceable>ENTRY-TOKEN</replaceable> string is

View File

@ -1368,11 +1368,11 @@ node /org/freedesktop/systemd1 {
for more information.</para> for more information.</para>
<para><function>SwitchRoot()</function> may be used to transition to a new root directory. This is <para><function>SwitchRoot()</function> may be used to transition to a new root directory. This is
intended to be used by initial RAM disks. The method takes two arguments: the new root directory (which intended to be used in the initrd, and also to transition from the host system into a shutdown initrd.
needs to be specified) and an init binary path (which may be left empty, in which case it is The method takes two arguments: the new root directory (which needs to be specified) and an init binary
automatically searched for). The state of the system manager will be serialized before the path (which may be left empty, in which case it is automatically searched for). The state of the system
transition. After the transition, the manager binary on the main system is invoked and replaces the old manager will be serialized before the transition. After the transition, the manager binary on the main
PID 1. All state will then be deserialized.</para> system is invoked and replaces the old PID 1. All state will then be deserialized.</para>
<para><function>SetEnvironment()</function> may be used to alter the environment block that is passed <para><function>SetEnvironment()</function> may be used to alter the environment block that is passed
to all spawned processes. It takes a string array of environment variable assignments. Any previously set to all spawned processes. It takes a string array of environment variable assignments. Any previously set

View File

@ -442,11 +442,10 @@
<listitem><para>Takes a space-separated list of one or more of the strings <listitem><para>Takes a space-separated list of one or more of the strings
<literal>system</literal>, <literal>initrd</literal> and <literal>portable</literal>. This field is <literal>system</literal>, <literal>initrd</literal> and <literal>portable</literal>. This field is
only supported in <filename>extension-release.d/</filename> files and indicates what environments only supported in <filename>extension-release.d/</filename> files and indicates what environments
the system extension is applicable to: i.e. to regular systems, to initial RAM filesystems the system extension is applicable to: i.e. to regular systems, to initrds, or to portable service
("initrd") or to portable service images. If unspecified, <literal>SYSEXT_SCOPE=system images. If unspecified, <literal>SYSEXT_SCOPE=system portable</literal> is implied, i.e. any system
portable</literal> is implied, i.e. any system extension without this field is applicable to extension without this field is applicable to regular systems and to portable service environments,
regular systems and to portable service environments, but not to initrd but not to initrd environments.</para></listitem>
environments.</para></listitem>
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>

View File

@ -1527,15 +1527,16 @@ Jan 12 10:46:45 example.com bluetoothd[8900]: gatt-time-server: Input/output err
<term><command>switch-root</command> <replaceable>ROOT</replaceable> <optional><replaceable>INIT</replaceable></optional></term> <term><command>switch-root</command> <replaceable>ROOT</replaceable> <optional><replaceable>INIT</replaceable></optional></term>
<listitem> <listitem>
<para>Switches to a different root directory and executes a new system manager process below it. This is <para>Switches to a different root directory and executes a new system manager process below it.
intended for usage in initial RAM disks ("initrd"), and will transition from the initrd's system manager This is intended for use in the initrd, and will transition from the initrd's system manager
process (a.k.a. "init" process) to the main system manager process which is loaded from the actual host process (a.k.a. "init" process) to the main system manager process which is loaded from the
volume. This call takes two arguments: the directory that is to become the new root directory, and the path actual host root files system. This call takes two arguments: the directory that is to become the
to the new system manager binary below it to execute as PID 1. If the latter is omitted or the empty new root directory, and the path to the new system manager binary below it to execute as PID 1.
string, a systemd binary will automatically be searched for and used as init. If the system manager path is If the latter is omitted or the empty string, a systemd binary will automatically be searched for
omitted, equal to the empty string or identical to the path to the systemd binary, the state of the and used as init. If the system manager path is omitted, equal to the empty string or identical
initrd's system manager process is passed to the main system manager, which allows later introspection of to the path to the systemd binary, the state of the initrd's system manager process is passed to
the state of the services involved in the initrd boot phase.</para> the main system manager, which allows later introspection of the state of the services involved
in the initrd boot phase.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>

View File

@ -444,7 +444,7 @@
stored in the EFI variable <varname>LoaderSystemToken</varname> (see below). During early OS boot the stored in the EFI variable <varname>LoaderSystemToken</varname> (see below). During early OS boot the
system manager reads this variable and passes it to the OS kernel's random pool, crediting the full system manager reads this variable and passes it to the OS kernel's random pool, crediting the full
entropy it contains. This is an efficient way to ensure the system starts up with a fully initialized entropy it contains. This is an efficient way to ensure the system starts up with a fully initialized
kernel random pool — as early as the initial RAM disk phase. <command>systemd-boot</command> reads kernel random pool — as early as the initrd phase. <command>systemd-boot</command> reads
the random seed from the ESP, combines it with the "system token", and both derives a new random seed the random seed from the ESP, combines it with the "system token", and both derives a new random seed
to update in-place the seed stored in the ESP, and the random seed to pass to the OS from it via to update in-place the seed stored in the ESP, and the random seed to pass to the OS from it via
SHA256 hashing in counter mode. This ensures that different physical systems that boot the same SHA256 hashing in counter mode. This ensures that different physical systems that boot the same

View File

@ -129,11 +129,10 @@
</orderedlist> </orderedlist>
<para>Which of the three keys shall be used for encryption may be configured with the <para>Which of the three keys shall be used for encryption may be configured with the
<option>--with-key=</option> switch. Depending on the use-case for the encrypted credential the key to <option>--with-key=</option> switch. Depending on the use-case for the encrypted credential the key
use may differ. For example, for credentials that shall be accessible from the initial RAM disk to use may differ. For example, for credentials that shall be accessible from the initrd, encryption
(initrd) of the system encryption with the host key is not appropriate since access to the host key with the host key is not appropriate, since access to the host key is typically not available from
is typically not available from the initrd. Thus, for such credentials only the TPM2 key should be the initrd. Thus, for such credentials only the TPM2 key should be used.</para>
used.</para>
<para>Encrypted credentials are always encoded in Base64.</para> <para>Encrypted credentials are always encoded in Base64.</para>

View File

@ -296,7 +296,7 @@
<row> <row>
<entry>9</entry> <entry>9</entry>
<entry>The Linux kernel measures all initial RAM file systems it receives into this PCR.</entry> <entry>The Linux kernel measures all initrds it receives into this PCR.</entry>
<!-- Strictly speaking only Linux >= 5.17 using the LOAD_FILE2 protocol, see https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f046fff8bc4c4d8f8a478022e76e40b818f692df --> <!-- Strictly speaking only Linux >= 5.17 using the LOAD_FILE2 protocol, see https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f046fff8bc4c4d8f8a478022e76e40b818f692df -->
</row> </row>
@ -307,7 +307,7 @@
<row> <row>
<entry>11</entry> <entry>11</entry>
<entry><citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry> measures the ELF kernel image, embedded initrd and other payload of the PE image it is placed in into this PCR. Unlike PCR 4 (where the same data should be measured into), this PCR value should be easy to pre-calculate, as this only contains static parts of the PE binary. Use this PCR to bind TPM policies to a specific kernel image, possibly with an embedded initial RAM disk (initrd).</entry> <entry><citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry> measures the ELF kernel image, embedded initrd and other payload of the PE image it is placed in into this PCR. Unlike PCR 4 (where the same data should be measured into), this PCR value should be easy to pre-calculate, as this only contains static parts of the PE binary. Use this PCR to bind TPM policies to a specific kernel image, possibly with an embedded initrd.</entry>
</row> </row>
<row> <row>

View File

@ -49,48 +49,40 @@
<term><varname>luks=</varname></term> <term><varname>luks=</varname></term>
<term><varname>rd.luks=</varname></term> <term><varname>rd.luks=</varname></term>
<listitem><para>Takes a boolean argument. Defaults to <listitem><para>Takes a boolean argument. Defaults to <literal>yes</literal>. If
<literal>yes</literal>. If <literal>no</literal>, disables the <literal>no</literal>, disables the generator entirely. <varname>rd.luks=</varname> is honored only
generator entirely. <varname>rd.luks=</varname> is honored in the initrd while <varname>luks=</varname> is honored by both the main system and in the initrd.
only by initial RAM disk (initrd) while </para></listitem>
<varname>luks=</varname> is honored by both the main system
and the initrd. </para></listitem>
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>
<term><varname>luks.crypttab=</varname></term> <term><varname>luks.crypttab=</varname></term>
<term><varname>rd.luks.crypttab=</varname></term> <term><varname>rd.luks.crypttab=</varname></term>
<listitem><para>Takes a boolean argument. Defaults to <listitem><para>Takes a boolean argument. Defaults to <literal>yes</literal>. If
<literal>yes</literal>. If <literal>no</literal>, causes the <literal>no</literal>, causes the generator to ignore any devices configured in
generator to ignore any devices configured in <filename>/etc/crypttab</filename> (<varname>luks.uuid=</varname> will still work however).
<filename>/etc/crypttab</filename> <varname>rd.luks.crypttab=</varname> is honored only in initrd while
(<varname>luks.uuid=</varname> will still work however). <varname>luks.crypttab=</varname> is honored by both the main system and the initrd.
<varname>rd.luks.crypttab=</varname> is honored only by </para></listitem>
initial RAM disk (initrd) while
<varname>luks.crypttab=</varname> is honored by both the main
system and the initrd. </para></listitem>
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>
<term><varname>luks.uuid=</varname></term> <term><varname>luks.uuid=</varname></term>
<term><varname>rd.luks.uuid=</varname></term> <term><varname>rd.luks.uuid=</varname></term>
<listitem><para>Takes a LUKS superblock UUID as argument. This <listitem><para>Takes a LUKS superblock UUID as argument. This will activate the specified device as
will activate the specified device as part of the boot process part of the boot process as if it was listed in <filename>/etc/crypttab</filename>. This option may
as if it was listed in <filename>/etc/crypttab</filename>. be specified more than once in order to set up multiple devices. <varname>rd.luks.uuid=</varname> is
This option may be specified more than once in order to set up honored only in the initrd, while <varname>luks.uuid=</varname> is honored by both the main system
multiple devices. <varname>rd.luks.uuid=</varname> is honored and the initrd.</para>
only by initial RAM disk (initrd) while
<varname>luks.uuid=</varname> is honored by both the main <para>If <filename>/etc/crypttab</filename> contains entries with the same UUID, then the name,
system and the initrd.</para> keyfile and options specified there will be used. Otherwise, the device will have the name
<para>If /etc/crypttab contains entries with the same UUID,
then the name, keyfile and options specified there will be
used. Otherwise, the device will have the name
<literal>luks-UUID</literal>.</para> <literal>luks-UUID</literal>.</para>
<para>If /etc/crypttab exists, only those UUIDs
specified on the kernel command line <para>If <filename>/etc/crypttab</filename> exists, only those UUIDs specified on the kernel command
will be activated in the initrd or the real root.</para> line will be activated in the initrd or the real root.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -108,9 +100,8 @@
<para>This parameter is the analogue of the first <citerefentry><refentrytitle>crypttab</refentrytitle> <para>This parameter is the analogue of the first <citerefentry><refentrytitle>crypttab</refentrytitle>
<manvolnum>5</manvolnum></citerefentry> field <replaceable>volume-name</replaceable>.</para> <manvolnum>5</manvolnum></citerefentry> field <replaceable>volume-name</replaceable>.</para>
<para><varname>rd.luks.name=</varname> is honored only by <para><varname>rd.luks.name=</varname> is honored only in the initrd, while
initial RAM disk (initrd) while <varname>luks.name=</varname> <varname>luks.name=</varname> is honored by both the main system and the initrd.</para>
is honored by both the main system and the initrd.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -137,8 +128,8 @@
<para>This parameter is the analogue of the second <citerefentry><refentrytitle>crypttab</refentrytitle> <para>This parameter is the analogue of the second <citerefentry><refentrytitle>crypttab</refentrytitle>
<manvolnum>5</manvolnum></citerefentry> field <replaceable>encrypted-device</replaceable>.</para> <manvolnum>5</manvolnum></citerefentry> field <replaceable>encrypted-device</replaceable>.</para>
<para><varname>rd.luks.data=</varname> is honored only by initial RAM disk (initrd) while <para><varname>rd.luks.data=</varname> is honored only in the initrd, while
<varname>luks.data=</varname> is honored by both the main system and the initrd.</para> <varname>luks.data=</varname> is honored by both the main system and in the initrd.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -173,12 +164,8 @@
<para>This parameter is the analogue of the third <citerefentry><refentrytitle>crypttab</refentrytitle> <para>This parameter is the analogue of the third <citerefentry><refentrytitle>crypttab</refentrytitle>
<manvolnum>5</manvolnum></citerefentry> field <replaceable>key-file</replaceable>.</para> <manvolnum>5</manvolnum></citerefentry> field <replaceable>key-file</replaceable>.</para>
<para><varname>rd.luks.key=</varname> <para><varname>rd.luks.key=</varname> is honored only in the initrd, while
is honored only by initial RAM disk <varname>luks.key=</varname> is honored by both the main system and in the initrd.</para>
(initrd) while
<varname>luks.key=</varname> is
honored by both the main system and
the initrd.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>

View File

@ -70,13 +70,10 @@
<term><varname>fstab=</varname></term> <term><varname>fstab=</varname></term>
<term><varname>rd.fstab=</varname></term> <term><varname>rd.fstab=</varname></term>
<listitem><para>Takes a boolean argument. Defaults to <listitem><para>Takes a boolean argument. Defaults to <literal>yes</literal>. If
<literal>yes</literal>. If <literal>no</literal>, causes the <literal>no</literal>, causes the generator to ignore any mounts or swap devices configured in
generator to ignore any mounts or swap devices configured in <filename>/etc/fstab</filename>. <varname>rd.fstab=</varname> is honored only in the initrd, while
<filename>/etc/fstab</filename>. <varname>rd.fstab=</varname> <varname>fstab=</varname> is honored by both the main system and the initrd.</para></listitem>
is honored only by the initial RAM disk (initrd) while
<varname>fstab=</varname> is honored by both the main system
and the initrd.</para></listitem>
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>
@ -194,12 +191,12 @@
<para>If true the generator ensures <para>If true the generator ensures
<citerefentry><refentrytitle>systemd-volatile-root.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> <citerefentry><refentrytitle>systemd-volatile-root.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
is run as part of the initial RAM disk ("initrd"). This service changes the mount table before transitioning to is run in the initrd. This service changes the mount table before transitioning to the host system,
the host system, so that a volatile memory file system (<literal>tmpfs</literal>) is used as root directory, so that a volatile memory file system (<literal>tmpfs</literal>) is used as root directory, with only
with only <filename>/usr/</filename> mounted into it from the configured root file system, in read-only <filename>/usr/</filename> mounted into it from the configured root file system, in read-only mode.
mode. This way the system operates in fully stateless mode, with all configuration and state reset at boot and This way the system operates in fully stateless mode, with all configuration and state reset at boot
lost at shutdown, as <filename>/etc/</filename> and <filename>/var/</filename> will be served from the (initially and lost at shutdown, as <filename>/etc/</filename> and <filename>/var/</filename> will be served
unpopulated) volatile memory file system.</para> from the (initially unpopulated) volatile memory file system.</para>
<para>If set to <option>state</option> the generator will leave the root directory mount point unaltered, <para>If set to <option>state</option> the generator will leave the root directory mount point unaltered,
however will mount a <literal>tmpfs</literal> file system to <filename>/var/</filename>. In this mode the normal however will mount a <literal>tmpfs</literal> file system to <filename>/var/</filename>. In this mode the normal

View File

@ -52,10 +52,8 @@
<term><varname>modules_load=</varname></term> <term><varname>modules_load=</varname></term>
<term><varname>rd.modules_load=</varname></term> <term><varname>rd.modules_load=</varname></term>
<listitem><para>Takes a comma-separated list of kernel modules <listitem><para>Takes a comma-separated list of kernel modules to statically load during early boot.
to statically load during early boot. The option prefixed with The option prefixed with <literal>rd.</literal> is read in the initrd only.</para></listitem>
<literal>rd.</literal> is read by the initial RAM disk
only.</para></listitem>
</varlistentry> </varlistentry>
</variablelist> </variablelist>

View File

@ -443,9 +443,9 @@
in the container's file system namespace.</para> in the container's file system namespace.</para>
<para>This is for containers which have several bootable directories in them; for example, several <para>This is for containers which have several bootable directories in them; for example, several
<ulink url="https://ostree.readthedocs.io/en/latest/">OSTree</ulink> deployments. It emulates the behavior of <ulink url="https://ostree.readthedocs.io/en/latest/">OSTree</ulink> deployments. It emulates the
the boot loader and initial RAM disk which normally select which directory to mount as the root and start the behavior of the boot loader and the initrd which normally select which directory to mount as the root
container's PID 1 in.</para></listitem> and start the container's PID 1 in.</para></listitem>
</varlistentry> </varlistentry>
</variablelist> </variablelist>

View File

@ -33,14 +33,14 @@
into the kernel entropy pool during boot and saves it at shutdown. See into the kernel entropy pool during boot and saves it at shutdown. See
<citerefentry><refentrytitle>random</refentrytitle><manvolnum>4</manvolnum></citerefentry> for <citerefentry><refentrytitle>random</refentrytitle><manvolnum>4</manvolnum></citerefentry> for
details. By default, no entropy is credited when the random seed is written into the kernel entropy pool, details. By default, no entropy is credited when the random seed is written into the kernel entropy pool,
but this may be changed with <varname>$SYSTEMD_RANDOM_SEED_CREDIT</varname>, see below. On disk the random but this may be changed with <varname>$SYSTEMD_RANDOM_SEED_CREDIT</varname>, see below. On disk the random
seed is stored in <filename>/var/lib/systemd/random-seed</filename>.</para> seed is stored in <filename>/var/lib/systemd/random-seed</filename>.</para>
<para>Note that this service runs relatively late during the early boot phase, i.e. generally after the <para>Note that this service runs relatively late during the early boot phase, i.e. generally after the
initial RAM disk (initrd) completed its work, and the <filename>/var/</filename> file system has been initrd phase has finished and the <filename>/var/</filename> file system has been mounted. Many system
mounted writable. Many system services require entropy much earlier than this — this service is hence of services require entropy much earlier than this — this service is hence of limited use for complex
limited use for complex system. It is recommended to use a boot loader that can pass an initial random system. It is recommended to use a boot loader that can pass an initial random seed to the kernel to
seed to the kernel to ensure that entropy is available from earliest boot on, for example ensure that entropy is available from earliest boot on, for example
<citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>, with <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>, with
its <command>bootctl random-seed</command> functionality.</para> its <command>bootctl random-seed</command> functionality.</para>

View File

@ -36,7 +36,7 @@
<citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry> <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
is active) to the root file system, the <filename>/usr/</filename> file system, and the kernel API file is active) to the root file system, the <filename>/usr/</filename> file system, and the kernel API file
systems. This is required so that the mount options of these file systems — which are pre-mounted by the systems. This is required so that the mount options of these file systems — which are pre-mounted by the
kernel, the initial RAM disk, container environments or system manager code — are updated to those kernel, the initrd, container environments or system manager code — are updated to those
configured in <filename>/etc/fstab</filename> and the other sources. This service ignores normal file configured in <filename>/etc/fstab</filename> and the other sources. This service ignores normal file
systems and only changes the root file system (i.e. <filename>/</filename>), <filename>/usr/</filename>, systems and only changes the root file system (i.e. <filename>/</filename>), <filename>/usr/</filename>,
and the virtual kernel API file systems such as <filename>/proc/</filename>, <filename>/sys/</filename> or and the virtual kernel API file systems such as <filename>/proc/</filename>, <filename>/sys/</filename> or

View File

@ -43,14 +43,14 @@
<para>If invoked with no arguments, it operates on the block device backing the root file system <para>If invoked with no arguments, it operates on the block device backing the root file system
partition of the running OS, thus growing and adding partitions of the booted OS image itself. If partition of the running OS, thus growing and adding partitions of the booted OS image itself. If
<varname>--image=</varname> is used it will operate on the specified image file. When called in the <varname>--image=</varname> is used it will operate on the specified image file. When called in the
<literal>initrd</literal> it operates on the block device backing <filename>/sysroot/</filename> instead, initrd it operates on the block device backing <filename>/sysroot/</filename> instead, i.e. on the block
i.e. on the block device the system will soon transition into. The device the system will soon transition into. The <filename>systemd-repart.service</filename> service is
<filename>systemd-repart.service</filename> service is generally run at boot in the initial RAM disk, in generally run at boot in the initrd, in order to augment the partition table of the OS before its
order to augment the partition table of the OS before its partitions are partitions are mounted. <command>systemd-repart</command> (mostly) operates in a purely incremental mode:
mounted. <command>systemd-repart</command> (mostly) operates in a purely incremental mode: it only grows it only grows existing and adds new partitions; it does not shrink, delete or move existing partitions.
existing and adds new partitions; it does not shrink, delete or move existing partitions. The service is The service is intended to be run on every boot, but when it detects that the partition table already
intended to be run on every boot, but when it detects that the partition table already matches the matches the installed <filename>repart.d/*.conf</filename> configuration files, it executes no
installed <filename>repart.d/*.conf</filename> configuration files, it executes no operation.</para> operation.</para>
<para><command>systemd-repart</command> is intended to be used when deploying OS images, to automatically <para><command>systemd-repart</command> is intended to be used when deploying OS images, to automatically
adjust them to the system they are running on, during first boot. This way the deployed image can be adjust them to the system they are running on, during first boot. This way the deployed image can be
@ -89,34 +89,34 @@
<listitem><para>Taking the size constraints and weights declared in the configuration files into <listitem><para>Taking the size constraints and weights declared in the configuration files into
account, all partitions that shall be created are now allocated to the disk, taking up all free space, account, all partitions that shall be created are now allocated to the disk, taking up all free space,
always respecting the size and padding requests. Similar, existing partitions that are determined to always respecting the size and padding requests. Similarly, existing partitions that should be grown
grow are grown. New partitions are always appended to the end of the existing partition table, taking are grown. New partitions are always appended to the end of the partition table, taking the first
the first partition table slot whose index is greater than the indexes of all existing partition table slot whose index is greater than the indexes of all existing partitions. Partition
partitions. Partition table slots are never reordered and thus partition numbers are ensured to remain table slots are never reordered and thus partition numbers are ensured to remain stable. Note that this
stable. Note that this allocation happens in RAM only, the partition table on disk is not updated allocation happens in memory only, the partition table on disk is not updated yet.</para></listitem>
yet.</para></listitem>
<listitem><para>All existing partitions for which configuration files exist and which currently have no <listitem><para>All existing partitions for which configuration files exist and which currently have no
GPT partition label set will be assigned a label, either explicitly configured in the configuration or GPT partition label set will be assigned a label, either explicitly configured in the configuration or
(if that's missing) derived automatically from the partition type. The same is done for all partitions — if that's missing — derived automatically from the partition type. The same is done for all
that are newly created. These assignments are done in RAM only, too, the disk is not updated partitions that are newly created. These assignments are done in memory only, too, the disk is not
yet.</para></listitem> updated yet.</para></listitem>
<listitem><para>Similarly, all existing partitions for which configuration files exist and which <listitem><para>Similarly, all existing partitions for which configuration files exist and which
currently have an all-zero identifying UUID will be assigned a new UUID. This UUID is cryptographically currently have an all-zero identifying UUID will be assigned a new UUID. This UUID is cryptographically
hashed from a common seed value together with the partition type UUID (and a counter in case multiple hashed from a common seed value together with the partition type UUID (and a counter in case multiple
partitions of the same type are defined), see below. The same is done for all partitions that are partitions of the same type are defined), see below. The same is done for all partitions that are
created anew. These assignments are done in RAM only, too, the disk is not updated created anew. These assignments are done in memory only, too, the disk is not updated yet.
yet.</para></listitem> </para></listitem>
<listitem><para>Similarly, if the disk's volume UUID is all zeroes it is also initialized, also <listitem><para>Similarly, if the disk's volume UUID is all zeroes it is also initialized, also
cryptographically hashed from the same common seed value. Also, in RAM only, too.</para></listitem> cryptographically hashed from the same common seed value. This is done in memory only too.
</para></listitem>
<listitem><para>The disk space assigned to new partitions (i.e. what was previously considered free <listitem><para>The disk space assigned to new partitions (i.e. what was previously free space) is now
space but is no longer) is now erased. Specifically, all file system signatures are removed, and if the erased. Specifically, all file system signatures are removed, and if the device supports it, the
device supports it the <constant>BLKDISCARD</constant> I/O control command is issued to inform the <constant>BLKDISCARD</constant> I/O control command is issued to inform the hardware that the space is
hardware that the space is empty now. In addition any "padding" between partitions and at the end of now empty. In addition any "padding" between partitions and at the end of the device is similarly
the device is similarly erased.</para></listitem> erased.</para></listitem>
<listitem><para>The new partition table is finally written to disk. The kernel is asked to reread the <listitem><para>The new partition table is finally written to disk. The kernel is asked to reread the
partition table.</para></listitem> partition table.</para></listitem>
@ -257,9 +257,9 @@
<filename>repart.d/*.conf</filename> files, for the machine ID file to use as seed and for the <filename>repart.d/*.conf</filename> files, for the machine ID file to use as seed and for the
<varname>CopyFiles=</varname> and <varname>CopyBlocks=</varname> source files and directories. By <varname>CopyFiles=</varname> and <varname>CopyBlocks=</varname> source files and directories. By
default when invoked on the regular system this defaults to the host's root file system default when invoked on the regular system this defaults to the host's root file system
<filename>/</filename>. If invoked from the initial RAM disk this defaults to <filename>/</filename>. If invoked from the initrd this defaults to <filename>/sysroot/</filename>,
<filename>/sysroot/</filename>, so that the tool operates on the configuration and machine ID stored so that the tool operates on the configuration and machine ID stored in the root file system later
in the root file system later transitioned into itself.</para></listitem> transitioned into itself.</para></listitem>
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>

View File

@ -57,8 +57,8 @@
<citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry> file of <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry> file of
the OS the kernel belongs to, in the <literal>.osrel</literal> PE section.</para></listitem> the OS the kernel belongs to, in the <literal>.osrel</literal> PE section.</para></listitem>
<listitem><para>The initial RAM disk (initrd) will be looked for in the <literal>.initrd</literal> PE <listitem><para>The initrd will be loaded from the <literal>.initrd</literal> PE section.
section.</para></listitem> </para></listitem>
<listitem><para>A compiled binary DeviceTree will be looked for in the <literal>.dtb</literal> PE <listitem><para>A compiled binary DeviceTree will be looked for in the <literal>.dtb</literal> PE
section.</para></listitem> section.</para></listitem>
@ -290,27 +290,27 @@
<varlistentry> <varlistentry>
<term><varname>StubPcrKernelImage</varname></term> <term><varname>StubPcrKernelImage</varname></term>
<listitem><para>The PCR register index the ELF kernel image/initial RAM disk image/boot <listitem><para>The PCR register index the kernel image, initrd image, boot splash, devicetree
splash/devicetree database/embedded command line are measured into, formatted as decimal ASCII string database, and the embedded command line are measured into, formatted as decimal ASCII string (e.g.
(i.e. <literal>11</literal>). This variable is set if a measurement was successfully completed, and <literal>11</literal>). This variable is set if a measurement was successfully completed, and remains
remains unset otherwise.</para></listitem> unset otherwise.</para></listitem>
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>
<term><varname>StubPcrKernelParameters</varname></term> <term><varname>StubPcrKernelParameters</varname></term>
<listitem><para>The PCR register index the kernel command line and credentials are measured into, <listitem><para>The PCR register index the kernel command line and credentials are measured into,
formatted as decimal ASCII string (i.e. <literal>12</literal>). This variable is set if a measurement formatted as decimal ASCII string (e.g. <literal>12</literal>). This variable is set if a measurement
was successfully completed, and remains unset otherwise.</para></listitem> was successfully completed, and remains unset otherwise.</para></listitem>
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>
<term><varname>StubPcrInitRDSysExts</varname></term> <term><varname>StubPcrInitRDSysExts</varname></term>
<listitem><para>The PCR register index the systemd extensions for the initial RAM disk image, which <listitem><para>The PCR register index the systemd extensions for the initrd, which are picked up
are picked up from the file system the kernel image is located on. Formatted as decimal ASCII string from the file system the kernel image is located on. Formatted as decimal ASCII string (e.g.
(i.e. <literal>13</literal>). This variable is set if a measurement was successfully completed, and <literal>13</literal>). This variable is set if a measurement was successfully completed, and remains
remains unset otherwise.</para></listitem> unset otherwise.</para></listitem>
</varlistentry> </varlistentry>
</variablelist> </variablelist>