]> git.ipfire.org Git - thirdparty/systemd.git/blobdiff - man/systemd.special.xml
Merge pull request #14338 from keszybz/functional-test-rework
[thirdparty/systemd.git] / man / systemd.special.xml
index 248fb924dba4935a383af512162aeb64dbe314ca..d54a5de8715b53d63fcd6cd8bea6d40c60e56a2a 100644 (file)
@@ -26,6 +26,7 @@
     <filename>cryptsetup-pre.target</filename>,
     <filename>cryptsetup.target</filename>,
     <filename>ctrl-alt-del.target</filename>,
+    <filename>blockdev@.target</filename>,
     <filename>boot-complete.target</filename>,
     <filename>default.target</filename>,
     <filename>emergency.target</filename>,
@@ -38,6 +39,7 @@
     <filename>hibernate.target</filename>,
     <filename>hybrid-sleep.target</filename>,
     <filename>suspend-then-hibernate.target</filename>,
+    <filename>initrd.target</filename>,
     <filename>initrd-fs.target</filename>,
     <filename>initrd-root-device.target</filename>,
     <filename>initrd-root-fs.target</filename>,
         <varlistentry>
           <term><filename>default.target</filename></term>
           <listitem>
-            <para>The default unit systemd starts at bootup. Usually,
-            this should be aliased (symlinked) to
-            <filename>multi-user.target</filename> or
-            <filename>graphical.target</filename>.</para>
+            <para>The default unit systemd starts at bootup. Usually, this should be aliased (symlinked) to
+            <filename>multi-user.target</filename> or <filename>graphical.target</filename>. See
+            <citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+            more discussion.</para>
 
-            <para>The default unit systemd starts at bootup can be
-            overridden with the <varname>systemd.unit=</varname> kernel
-            command line option.</para>
+            <para>The default unit systemd starts at bootup can be overridden with the
+            <varname>systemd.unit=</varname> kernel command line option, or more conveniently, with the short
+            names like <varname>single</varname>, <varname>rescue</varname>, <varname>1</varname>,
+            <varname>3</varname>, <varname>5</varname>, …; see
+            <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
           </listitem>
         </varlistentry>
         <varlistentry>
             is active as long as the system is running.</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
+            <citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+            more discussion.</para>
+          </listitem>
+        </varlistentry>
         <varlistentry>
           <term><filename>initrd-fs.target</filename></term>
           <listitem>
       not useful as only unit within a transaction.</para>
 
       <variablelist>
+        <varlistentry>
+          <term><filename>blockdev@.target</filename></term>
+          <listitem><para>This template unit is used to order mount units and other consumers of block
+          devices after services that synthesize these block devices. In particular, this is intended to be
+          used with storage services (such as
+          <citerefentry><refentrytitle>systemd-cryptsetup@.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>)
+          that allocate and manage a virtual block device. Storage services are ordered before an instance of
+          <filename>blockdev@.target</filename>, and the consumer units after it. The ordering is
+          particularly relevant during shutdown, as it ensures that the mount is deactivated first and the
+          service backing the mount later. The <filename>blockdev@.target</filename> instance should be
+          pulled in via a <option>Wants=</option> dependency of the storage daemon and thus generally not be
+          part of any transaction unless a storage daemon is used. The instance name for instances of this
+          template unit must be a properly escaped block device node path, e.g.
+          <filename>blockdev@dev-mapper-foobar.target</filename> for the storage device
+          <filename>/dev/mapper/foobar</filename>.</para></listitem>
+        </varlistentry>
         <varlistentry>
           <term><filename>cryptsetup-pre.target</filename></term>
           <listitem>