shaba/systemd-stable
1
1
Fork 0
mirror of https://github.com/systemd/systemd-stable.git synced 2025-01-08 21:17:47 +03:00
Code

Merge pull request #24799 from poettering/initrd-ftw

Browse Source 
use "initrd" rather than "initial RAM disk" or "initramfs" to refernce the concept
This commit is contained in:
Luca Boccassi 2022-09-23 20:43:15 +01:00 committed by GitHub
commit 542e6eb38d
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
32 changed files with 123 additions and 138 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
catalog/systemd.catalog.in
View File

@ -144,7 +144,7 @@ might still be busy with completing start-up.
Kernel start-up required @KERNEL_USEC@ microseconds.
Initial RAM disk start-up required @INITRD_USEC@ microseconds.
initrd start-up required @INITRD_USEC@ microseconds.
Userspace start-up required @USERSPACE_USEC@ microseconds.

4
docs/CREDENTIALS.md
View File

@ -282,8 +282,8 @@ services where they are ultimately consumed.
EFI System Partition, which are then picked up by `systemd-stub` and passed
to the kernel and ultimately userspace where systemd receives them. This is
useful to implement secure parameterization of vendor-built and signed
initial RAM disks, as userspace can place credentials next to these EFI
kernels, and be sure they can be accessed securely from initrd context.
initrds, as userspace can place credentials next to these EFI kernels, and
be sure they can be accessed securely from initrd context.
Credentials passed to the system may be enumerated/displayed via `systemd-creds
--system`. They may also be propagated down to services, via the

27
docs/INITRD_INTERFACE.md
View File

@ -8,15 +8,16 @@ SPDX-License-Identifier: LGPL-2.1-or-later
# The initrd Interface of systemd
The Linux initrd mechanism (short for "initial RAM disk") refers to a small
file system archive that is unpacked by the kernel and contains the first
userspace code that runs. It typically finds and transitions into the actual
root file system to use. systemd supports both initrd and initrd-less boots. If
an initrd is used, it is a good idea to pass a few bits of runtime information
from the initrd to systemd in order to avoid duplicate work and to provide
performance data to the administrator. In this page we attempt to roughly
describe the interfaces that exist between the initrd and systemd. These
interfaces are currently used by dracut and the ArchLinux initrds.
The Linux initrd mechanism (short for "initial RAM disk", also known as
"initramfs") refers to a small file system archive that is unpacked by the
kernel and contains the first userspace code that runs. It typically finds and
transitions into the actual root file system to use. systemd supports both
initrd and initrd-less boots. If an initrd is used, it is a good idea to pass a
few bits of runtime information from the initrd to systemd in order to avoid
duplicate work and to provide performance data to the administrator. In this
page we attempt to roughly describe the interfaces that exist between the
initrd and systemd. These interfaces are currently used by dracut and the
ArchLinux initrds.
* The initrd should mount `/run/` as a tmpfs and pass it pre-mounted when
jumping into the main system when executing systemd. The mount options should
@ -57,10 +58,10 @@ It's all already implemented there!
It is also possible and recommended to implement the initrd itself based on
systemd. Here are a few terse notes:
* Provide `/etc/initrd-release` in the initrd image. The idea is that it follows
the same format as the usual `/etc/os-release` but describes the initial RAM
disk implementation rather than the OS. systemd uses the existence of this
file as a flag whether to run in initial RAM disk mode, or not.
* Provide `/etc/initrd-release` in the initrd image. The idea is that it
follows the same format as the usual `/etc/os-release` but describes the
initrd implementation rather than the OS. systemd uses the existence of this
file as a flag whether to run in initrd mode, or not.
* When run in initrd mode, systemd and its components will read a couple of
additional command line arguments, which are generally prefixed with `rd.`

12
docs/RANDOM_SEEDS.md
View File

@ -102,9 +102,9 @@ random bytes will either be delayed, will fail or result in a noisy kernel log
message (see above).
Various other components run during early boot that require random bytes. For
example, initial RAM disks nowadays communicate with encrypted networks or
access encrypted storage which might need random numbers. systemd itself
requires random numbers as well, including for the following uses:
example, initrds nowadays communicate with encrypted networks or access
encrypted storage which might need random numbers. systemd itself requires
random numbers as well, including for the following uses:
* systemd assigns 'invocation' UUIDs to all services it invokes that uniquely
identify each invocation. This is useful retain a global handle on a specific
@ -174,9 +174,9 @@ boot, in order to ensure the entropy pool is filled up quickly.
be enabled by setting the `$SYSTEMD_RANDOM_SEED_CREDIT` environment variable
for the service to `1` (or even `force`, see man page). Note however, that
this service typically runs relatively late during early boot: long after
the initial RAM disk (`initrd`) completed, and after the `/var/` file system
became writable. This is usually too late for many applications, it is hence
not advised to rely exclusively on this functionality to seed the kernel's
the initrd completed, and after the `/var/` file system became
writable. This is usually too late for many applications, it is hence not
advised to rely exclusively on this functionality to seed the kernel's
entropy pool. Also note that this service synchronously waits until the
kernel's entropy pool is initialized before completing start-up. It may thus
be used by other services as synchronization point to order against, if they

20
docs/ROOT_STORAGE_DAEMONS.md
View File

@ -22,16 +22,16 @@ is not.
## A Bit of Background
When complex storage technologies are used as backing for the root file system
this needs to be set up by the initial RAM file system (initrd), i.e. on Fedora
by Dracut. In newer systemd versions tear-down of the root file system backing
is also done by the initrd: after terminating all remaining running processes
and unmounting all file systems it can (which means excluding the root fs)
systemd will jump back into the initrd code allowing it to unmount the final
file systems (and its storage backing) that could not be unmounted as long as
the OS was still running from the main root file system. The initrd' job is to
detach/unmount the root fs, i.e. inverting the exact commands it used to set
them up in the first place. This is not only cleaner, but also allows for the
first time arbitrary complex stacks of storage technology.
this needs to be set up by the initrd, i.e. on Fedora by Dracut. In newer
systemd versions tear-down of the root file system backing is also done by the
initrd: after terminating all remaining running processes and unmounting all
file systems it can (which means excluding the root fs) systemd will jump back
into the initrd code allowing it to unmount the final file systems (and its
storage backing) that could not be unmounted as long as the OS was still
running from the main root file system. The initrd' job is to detach/unmount
the root fs, i.e. inverting the exact commands it used to set them up in the
first place. This is not only cleaner, but also allows for the first time
arbitrary complex stacks of storage technology.
Previous attempts to handle root file system setups with complex storage as
backing usually tried to maintain the root storage with program code stored on

2
docs/UIDS-GIDS.md
View File

@ -73,7 +73,7 @@ Note that systemd requires that system users and groups are resolvable without
networking available — a requirement that is not made for regular users. This
means regular users may be stored in remote LDAP or NIS databases, but system
users may not (except when there's a consistent local cache kept, that is
available during earliest boot, including in the initial RAM disk).
available during earliest boot, including in the initrd).
## Special `systemd` GIDs

14
man/bootup.xml
View File

@ -31,9 +31,9 @@
boot loader will then invoke an OS kernel from disk (or the network). On systems using EFI or other types
of firmware, this firmware may also load the kernel directly.</para>
<para>The kernel (optionally) mounts an in-memory file system, often generated by
<citerefentry project='man-pages'><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
which looks for the root file system. Nowadays this is implemented as an "initramfs" — a compressed CPIO
<para>The kernel (optionally) mounts an in-memory file system, often generated by <citerefentry
project='man-pages'><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>, which
looks for the root file system. Nowadays this is implemented as an "initramfs" — a compressed CPIO
archive that the kernel extracts into a tmpfs. In the past normal file systems using an in-memory block
device (ramdisk) were used, and the name "initrd" is still used to describe both concepts. It's the boot
loader or the firmware that loads both the kernel and initrd/initramfs images into memory, but the kernel
@ -200,10 +200,10 @@ emergency.service | | |
</refsect1>
<refsect1>
<title>Bootup in the Initial RAM Disk (initrd)</title>
<para>The initial RAM disk implementation (initrd) can be set up
using systemd as well. In this case, boot up inside the initrd
follows the following structure.</para>
<title>Bootup in the initrd</title>
<para>The initrd implementation can be set up using systemd as well. In this case, boot up inside the
initrd follows the following structure.</para>
<para>systemd detects that it is run within an initrd by checking
for the file <filename>/etc/initrd-release</filename>.

6
man/crypttab.xml
View File

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

10
man/localectl.xml
View File

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

8
man/systemd-analyze.xml
View File

@ -156,10 +156,10 @@
<title><command>systemd-analyze time</command></title>
<para>This command prints the time spent in the kernel before userspace has been reached, the time
spent in the initial RAM disk (initrd) before normal system userspace has been reached, and the time
normal system userspace took to initialize. Note that these measurements simply measure the time passed
up to the point where all system services have been spawned, but not necessarily until they fully
finished initialization or the disk is idle.</para>
spent in the initrd before normal system userspace has been reached, and the time normal system
userspace took to initialize. Note that these measurements simply measure the time passed up to the
point where all system services have been spawned, but not necessarily until they fully finished
initialization or the disk is idle.</para>
<example>
<title><command>Show how long the boot took</command></title>

4
man/systemd-creds.xml
View File

@ -304,8 +304,8 @@
<para>The <option>-H</option> switch is a shortcut for <option>--with-key=host</option>. Similar,
<option>-T</option> is a shortcut for <option>--with-key=tpm2</option>.</para>
<para>When encrypting credentials that shall be used in the initial RAM disk (initrd) where
<filename>/var/lib/systemd/</filename> is typically not available make sure to use
<para>When encrypting credentials that shall be used in the initrd (where
<filename>/var/lib/systemd/</filename> is typically not available) make sure to use
<option>--with-key=auto-initrd</option> mode, to disable binding against the host secret.</para>
<para>This switch has no effect on the <command>decrypt</command> command, as information on which

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

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

4
man/systemd-measure.xml
View File

@ -35,8 +35,8 @@
<para><command>systemd-measure</command> is a tool that may be used to pre-calculate and sign the
expected TPM2 PCR 11 values that should be seen when a unified Linux kernel image based on
<citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry> is
booted up. It accepts paths to the ELF kernel image file, initial ram disk image file, devicetree file,
kernel command line file,
booted up. It accepts paths to the ELF kernel image file, initrd image file, devicetree file, kernel
command line file,
<citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry> file, boot
splash file, and TPM2 PCR PEM public key file that make up the unified kernel image, and determines the
PCR values expected to be in place after booting the image. Calculation starts with a zero-initialized

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

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

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

@ -51,10 +51,10 @@
<term><varname>systemd.verity=</varname></term>
<term><varname>rd.systemd.verity=</varname></term>
<listitem><para>Takes a boolean argument. Defaults to <literal>yes</literal>. If <literal>no</literal>,
disables the generator entirely. <varname>rd.systemd.verity=</varname> is honored only by the initial RAM disk
(initrd) while <varname>systemd.verity=</varname> is honored by both the host system and the
initrd.</para></listitem>
<listitem><para>Takes a boolean argument. Defaults to <literal>yes</literal>. If
<literal>no</literal>, disables the generator entirely. <varname>rd.systemd.verity=</varname> is
honored only by the initrd while <varname>systemd.verity=</varname> is honored by both the host
system and the initrd.</para></listitem>
</varlistentry>
<varlistentry>

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

@ -37,9 +37,10 @@
stateless systems.</para>
<para>This service is only enabled if full volatile mode is selected, for example by specifying
<literal>systemd.volatile=yes</literal> on the kernel command line. This service runs only in the initial RAM disk
("initrd"), before the system transitions to the host's root directory. Note that this service is not used if
<literal>systemd.volatile=state</literal> is used, as in that mode the root directory is non-volatile.</para>
<literal>systemd.volatile=yes</literal> on the kernel command line. This service runs only in the initrdyes,
before the system transitions to the host's root directory. Note that this service is not used if
<literal>systemd.volatile=state</literal> is used, as in that mode the root directory is
non-volatile.</para>
</refsect1>
<refsect1>

7
man/systemd.generator.xml
View File

@ -148,10 +148,9 @@
<varlistentry>
<term><varname>$SYSTEMD_IN_INITRD</varname></term>
<listitem><para>If the generator is run as part of an initial RAM file system (initrd) this is set to
<literal>1</literal>. If it is run from the regular host (i.e. after the transition from initrd to
host) it is set to <literal>0</literal>. This environment variable is only set for system
generators.</para></listitem>
<listitem><para>If the generator is run as part of an initrd this is set to <literal>1</literal>. If
it is run from the regular host (i.e. after the transition from initrd to host) it is set to
<literal>0</literal>. This environment variable is only set for system generators.</para></listitem>
</varlistentry>
<varlistentry>

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

@ -403,8 +403,8 @@
<listitem><para>A string field that specifies the runtime scope in which the message was logged. If
<literal>initrd</literal>, the log message was processed while the system was running inside the
initial RAM disk (initrd). If <literal>system</literal>, the log message was generated after the
system switched execution to the host root filesystem.</para></listitem>
initrd. If <literal>system</literal>, the log message was generated after the system switched
execution to the host root filesystem.</para></listitem>
</varlistentry>
</variablelist>
</refsect1>

5
man/systemd.mount.xml
View File

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

4
man/systemd.special.xml
View File

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

14
man/systemd.xml
View File

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

6
man/veritytab.xml
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>

15
src/core/device.c
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

6
src/core/main.c
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
@ -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;

2
src/hibernate-resume/hibernate-resume-generator.c
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;

4
src/hostname/hostnamed.c
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)

6
src/libsystemd/sd-device/device-private.c
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;

7
src/nspawn/nspawn-mount.c
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

8
src/test/test-exec-util.c
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);

4
test/README.testsuite
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.

2
test/test-functions
View File

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