1
0
mirror of https://github.com/systemd/systemd.git synced 2025-02-22 09:57:34 +03:00

tree-wide: use the term "initrd" at most places we so far used "initramfs"

In most cases we refernced the concept as "initrd". Let's convert most
remaining uses of "initramfs" to "initrd" too, to stay internally
consistent.

This leaves "initramfs" only where it's relevant to explain historical
concepts or where "initramfs" is part of the API (i.e. in
/run/initramfs).

Follow-up for: b66a6e1a5838b874b789820c090dd6850cf10513
This commit is contained in:
Lennart Poettering 2022-09-23 14:59:02 +02:00
parent addc84ec91
commit 32e2767080
18 changed files with 57 additions and 69 deletions

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

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>

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

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

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

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>

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>

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

@ -2707,7 +2707,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