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
<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>
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>
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
<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
<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>.
<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>
<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>
<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>
<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>
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>
* 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
/* 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
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;
/* 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)
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;
* 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
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);
(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.
# 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
projects / thirdparty / systemd.git / commitdiff
