X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=man%2Fbootup.xml;h=0854b6c3165a7313006580269dfcc5d8aa389d37;hb=78ad7cf1b9d0379f1ccc516f2555cb1476ca60bd;hp=a596e85b70aaa567cb6522bdde6063793ab996f5;hpb=e3d84721dc9bcf9008f72dae03ff0f7842d0bb4b;p=elogind.git
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
- dracut8
+ Linux case, this kernel (optionally) extracts and
+ executes an initial RAM disk image (initrd), such as
+ generated by
+ dracut8,
which looks for the root file system (possibly using
systemd1
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
systemd1)
- 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.
- On shutdown the system manager stops all
+ 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.
+ it resides on. As a last step, the system is powered down.
Additional information about the system boot
process may be found in
- boot7.
+ boot7.
@@ -90,7 +91,7 @@
systems, services and drivers that are necessary for
operation of the system. On
systemd1
- 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
systemd.target5
for detailed information about target units.) The
@@ -99,17 +100,17 @@
deterministic, but still adheres to a limited amount
of ordering structure.
- When systemd starts up the system it will
+ When systemd starts up the system, it will
activate all units that are dependencies of
default.target (as well as
recursively all dependencies of these
- dependencies). Usually
+ dependencies). Usually,
default.target is simply an alias
of graphical.target or
- multi-user.target depending on
+ multi-user.target, 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
systemd.special7.
@@ -144,7 +145,7 @@
v v | v rescue.target
timers.target paths.target | sockets.target
| | | |
- \__________________|_________________ | ___________________/
+ v |_________________ | ___________________/
\|/
v
basic.target
@@ -173,12 +174,17 @@
systemd1)
or by symlinking default.target
to them.
+
+ timers.target is pulled-in
+ by basic.target asynchronously.
+ This allows timers units to depend on services which
+ become only available later in boot.
Bootup in the Initial RAM Disk (initrd)
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.
@@ -307,10 +313,10 @@ systemd-reboot.service systemd-poweroff.service systemd-halt.service syste
See Also
systemd1,
- boot7,
+ boot7,
systemd.special7,
systemd.target5,
- dracut8
+ dracut8