X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=elogind.git;a=blobdiff_plain;f=man%2Fbootup.xml;h=0854b6c3165a7313006580269dfcc5d8aa389d37;hp=a596e85b70aaa567cb6522bdde6063793ab996f5;hb=a2e0337875addaf08225fbf9b231435ba12a88b5;hpb=e3d84721dc9bcf9008f72dae03ff0f7842d0bb4b

diff --git a/man/bootup.xml b/man/bootup.xml
index a596e85b7..0854b6c31 100644
--- a/man/bootup.xml
+++ b/man/bootup.xml
@@ -56,30 +56,31 @@
                 and hand control over to a boot loader stored on a
                 persistent storage device. This boot loader will then
                 invoke an OS kernel from disk (or the network). In the
-                Linux case this kernel (optionally) extracts and
-                executes an initial RAM disk image (initrd) such as
-                <citerefentry><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+                Linux case, this kernel (optionally) extracts and
+                executes an initial RAM disk image (initrd), such as
+                generated by
+                <citerefentry project='die-net'><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
                 which looks for the root file system (possibly using
                 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
                 for this). After the root file system is found and
-                mounted the initrd hands over control to the host's
+                mounted, the initrd hands over control to the host's
                 system manager (such as
                 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>)
-                stored on the OS image which is then responsible for
+                stored on the OS image, which is then responsible for
                 probing all remaining hardware, mounting all necessary
                 file systems and spawning all configured
                 services.</para>
 
-                <para>On shutdown the system manager stops all
+                <para>On shutdown, the system manager stops all
                 services, unmounts all file systems (detaching the
                 storage technologies backing them), and then
                 (optionally) jumps back into the initrd code which
                 unmounts/detaches the root file system and the storage
-                it resides on. As last step the system is powered down.</para>
+                it resides on. As a last step, the system is powered down.</para>
 
                 <para>Additional information about the system boot
                 process may be found in
-                <citerefentry><refentrytitle>boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+                <citerefentry project='man-pages'><refentrytitle>boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
         </refsect1>
 
         <refsect1>
@@ -90,7 +91,7 @@
                 systems, services and drivers that are necessary for
                 operation of the system. On
                 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
-                systems this process is split up in various discrete
+                systems, this process is split up in various discrete
                 steps which are exposed as target units. (See
                 <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>
                 for detailed information about target units.) The
@@ -99,17 +100,17 @@
                 deterministic, but still adheres to a limited amount
                 of ordering structure.</para>
 
-                <para>When systemd starts up the system it will
+                <para>When systemd starts up the system, it will
                 activate all units that are dependencies of
                 <filename>default.target</filename> (as well as
                 recursively all dependencies of these
-                dependencies). Usually
+                dependencies). Usually,
                 <filename>default.target</filename> is simply an alias
                 of <filename>graphical.target</filename> or
-                <filename>multi-user.target</filename> depending on
+                <filename>multi-user.target</filename>, depending on
                 whether the system is configured for a graphical UI or
                 only for a text console. To enforce minimal ordering
-                between the units pulled in a number of well-known
+                between the units pulled in, a number of well-known
                 target units are available, as listed on
                 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
 
@@ -144,7 +145,7 @@
          v                  v                  |                    v              <emphasis>rescue.target</emphasis>
    timers.target      paths.target             |             sockets.target
          |                  |                  |                    |
-         \__________________|_________________ | ___________________/
+         v                  |_________________ | ___________________/
                                               \|/
                                                v
                                          basic.target
@@ -173,12 +174,17 @@
                 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>)
                 or by symlinking <filename>default.target</filename>
                 to them.</para>
+
+                <para><filename>timers.target</filename> is pulled-in
+                by <filename>basic.target</filename> asynchronously.
+                This allows timers units to depend on services which
+                become only available later in boot.</para>
         </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
+                be set up using systemd as well. In this case, boot up
                 inside the initrd follows the following
                 structure.</para>
 
@@ -307,10 +313,10 @@ systemd-reboot.service   systemd-poweroff.service   systemd-halt.service   syste
                 <title>See Also</title>
                 <para>
                         <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
-                        <citerefentry><refentrytitle>boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+                        <citerefentry project='man-pages'><refentrytitle>boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
                         <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
                         <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
-                        <citerefentry><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+                        <citerefentry project='die-net'><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>
                 </para>
         </refsect1>