X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=man%2Fbootup.xml;h=b92057af294dac764b7ec9e6aaf50a5908e689f4;hb=b44787bd437f4051660272b37bd6f75392f17931;hp=ac6e9f70f7b3a008876bbc8daeaf35b3ec97729b;hpb=5aded369782f28255bc6b494ca905d7acaea7a56;p=elogind.git

diff --git a/man/bootup.xml b/man/bootup.xml
index ac6e9f70f..b92057af2 100644
--- a/man/bootup.xml
+++ b/man/bootup.xml
@@ -1,6 +1,6 @@
 <?xml version='1.0'?> <!--*-nxml-*-->
 <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-        "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
 
 <!--
   This file is part of systemd.
@@ -23,103 +23,92 @@
 
 <refentry id="bootup">
 
-        <refentryinfo>
-                <title>bootup</title>
-                <productname>systemd</productname>
-
-                <authorgroup>
-                        <author>
-                                <contrib>Developer</contrib>
-                                <firstname>Lennart</firstname>
-                                <surname>Poettering</surname>
-                                <email>lennart@poettering.net</email>
-                        </author>
-                </authorgroup>
-        </refentryinfo>
-
-        <refmeta>
-                <refentrytitle>bootup</refentrytitle>
-                <manvolnum>7</manvolnum>
-        </refmeta>
-
-        <refnamediv>
-                <refname>bootup</refname>
-                <refpurpose>System bootup process</refpurpose>
-        </refnamediv>
-
-        <refsect1>
-                <title>Description</title>
-
-                <para>A number of different components are involved in
-                the system boot. Immediately after power-up, the
-                system BIOS will do minimal hardware initialization,
-                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
-                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
-                system manager (such as
-                <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>)
-                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
-                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 a last step, the system is powered down.</para>
-
-                <para>Additional information about the system boot
-                process may be found in
-                <citerefentry project='man-pages'><refentrytitle>boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
-        </refsect1>
-
-        <refsect1>
-                <title>System Manager Bootup</title>
-
-                <para>At boot, the system manager on the OS image is
-                responsible for initializing the required file
-                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
-                steps which are exposed as target units. (See
-                <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>
-                for detailed information about target units.) The
-                boot-up process is highly parallelized so that the
-                order in which specific target units are reached is not
-                deterministic, but still adheres to a limited amount
-                of ordering structure.</para>
-
-                <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,
-                <filename>default.target</filename> is simply an alias
-                of <filename>graphical.target</filename> or
-                <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
-                target units are available, as listed on
-                <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
-
-                <para>The following chart is a structural overview of
-                these well-known units and their position in the
-                boot-up logic. The arrows describe which units are
-                pulled in and ordered before which other units. Units
-                near the top are started before units nearer to the
-                bottom of the chart.</para>
+  <refentryinfo>
+    <title>bootup</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Lennart</firstname>
+        <surname>Poettering</surname>
+        <email>lennart@poettering.net</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>bootup</refentrytitle>
+    <manvolnum>7</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>bootup</refname>
+    <refpurpose>System bootup process</refpurpose>
+  </refnamediv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>A number of different components are involved in the system
+    boot. Immediately after power-up, the system BIOS will do minimal
+    hardware initialization, 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 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 system manager (such as
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>)
+    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 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 a last step, the system is powered down.</para>
+
+    <para>Additional information about the system boot process may be
+    found in
+    <citerefentry project='man-pages'><refentrytitle>boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>System Manager Bootup</title>
+
+    <para>At boot, the system manager on the OS image is responsible
+    for initializing the required file 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 steps which
+    are exposed as target units. (See
+    <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for detailed information about target units.) The boot-up process
+    is highly parallelized so that the order in which specific target
+    units are reached is not deterministic, but still adheres to a
+    limited amount of ordering structure.</para>
+
+    <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, <filename>default.target</filename> is simply an alias of
+    <filename>graphical.target</filename> or
+    <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 target units are available, as listed on
+    <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+
+    <para>The following chart is a structural overview of these
+    well-known units and their position in the boot-up logic. The
+    arrows describe which units are pulled in and ordered before which
+    other units. Units near the top are started before units nearer to
+    the bottom of the chart.</para>
 
 <programlisting>local-fs-pre.target
          |
@@ -145,7 +134,7 @@
          v                  v                  |                    v              <emphasis>rescue.target</emphasis>
    timers.target      paths.target             |             sockets.target
          |                  |                  |                    |
-         \__________________|_________________ | ___________________/
+         v                  \_________________ | ___________________/
                                               \|/
                                                v
                                          basic.target
@@ -165,51 +154,48 @@
                             v
                   <emphasis>graphical.target</emphasis></programlisting>
 
-                <para>Target units that are commonly used as boot
-                targets are <emphasis>emphasized</emphasis>. These
-                units are good choices as goal targets, for
-                example by passing them to the
-                <varname>systemd.unit=</varname> kernel command line
-                option (see
-                <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>)
-                or by symlinking <filename>default.target</filename>
-                to them.</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
-                inside the initrd follows the following
-                structure.</para>
-
-                <para>The default target in the initrd is
-                <filename>initrd.target</filename>. The bootup process
-                begins identical to the system manager bootup (see
-                above) until it reaches
-                <filename>basic.target</filename>. From there, systemd
-                approaches the special target
-                <filename>initrd.target</filename>. If the root device
-                can be mounted at <filename>/sysroot</filename>, the
-                <filename>sysroot.mount</filename> unit becomes active
-                and <filename>initrd-root-fs.target</filename> is
-                reached.  The service
-                <filename>initrd-parse-etc.service</filename> scans
-                <filename>/sysroot/etc/fstab</filename> for a possible
-                <filename>/usr</filename> mount point and additional
-                entries marked with the
-                <emphasis>x-initrd.mount</emphasis> option. All
-                entries found are mounted below
-                <filename>/sysroot</filename>, and
-                <filename>initrd-fs.target</filename> is reached. The
-                service <filename>initrd-cleanup.service</filename>
-                isolates to the
-                <filename>initrd-switch-root.target</filename>, where
-                cleanup services can run. As the very last step, the
-                <filename>initrd-switch-root.service</filename> is
-                activated, which will cause the system to switch its
-                root to <filename>/sysroot</filename>.
-                </para>
+    <para>Target units that are commonly used as boot targets are
+    <emphasis>emphasized</emphasis>. These units are good choices as
+    goal targets, for example by passing them to the
+    <varname>systemd.unit=</varname> kernel command line option (see
+    <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 inside the initrd
+    follows the following structure.</para>
+
+    <para>The default target in the initrd is
+    <filename>initrd.target</filename>. The bootup process begins
+    identical to the system manager bootup (see above) until it
+    reaches <filename>basic.target</filename>. From there, systemd
+    approaches the special target <filename>initrd.target</filename>.
+    If the root device can be mounted at
+    <filename>/sysroot</filename>, the
+    <filename>sysroot.mount</filename> unit becomes active and
+    <filename>initrd-root-fs.target</filename> is reached. The service
+    <filename>initrd-parse-etc.service</filename> scans
+    <filename>/sysroot/etc/fstab</filename> for a possible
+    <filename>/usr</filename> mount point and additional entries
+    marked with the <emphasis>x-initrd.mount</emphasis> option. All
+    entries found are mounted below <filename>/sysroot</filename>, and
+    <filename>initrd-fs.target</filename> is reached. The service
+    <filename>initrd-cleanup.service</filename> isolates to the
+    <filename>initrd-switch-root.target</filename>, where cleanup
+    services can run. As the very last step, the
+    <filename>initrd-switch-root.service</filename> is activated,
+    which will cause the system to switch its root to
+    <filename>/sysroot</filename>.
+    </para>
 
 <programlisting>                                               : (beginning identical to above)
                                                :
@@ -261,18 +247,13 @@
                                                |
                                                v
                                      Transition to Host OS</programlisting>
-        </refsect1>
-
-
-        <refsect1>
-                <title>System Manager Shutdown</title>
-
-                <para>System shutdown with systemd also consists of
-                various target units with some minimal ordering
-                structure applied:</para>
-
+  </refsect1>
 
+  <refsect1>
+    <title>System Manager Shutdown</title>
 
+    <para>System shutdown with systemd also consists of various target
+    units with some minimal ordering structure applied:</para>
 
 <programlisting>                                  (conflicts with  (conflicts with
                                     all system     all file system
@@ -301,18 +282,19 @@ systemd-reboot.service   systemd-poweroff.service   systemd-halt.service   syste
            v                         v                        v                      v
     <emphasis>reboot.target</emphasis>             <emphasis>poweroff.target</emphasis>            <emphasis>halt.target</emphasis>           <emphasis>kexec.target</emphasis></programlisting>
 
-                <para>Commonly used system shutdown targets are <emphasis>emphasized</emphasis>.</para>
-        </refsect1>
-
-        <refsect1>
-                <title>See Also</title>
-                <para>
-                        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</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 project='die-net'><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>
-                </para>
-        </refsect1>
+    <para>Commonly used system shutdown targets are
+    <emphasis>emphasized</emphasis>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</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 project='die-net'><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
 
 </refentry>