X-Git-Url: https://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=man%2Fbootup.xml;h=0854b6c3165a7313006580269dfcc5d8aa389d37;hb=2822da4fb7f891e5320f02f1d00f64b72221ced4;hp=4cc4bafab776320c3cf2782023e3863990816159;hpb=f274ece0f76b5709408821e317e87aef76123db6;p=elogind.git
diff --git a/man/bootup.xml b/man/bootup.xml
index 4cc4bafab..0854b6c31 100644
--- a/man/bootup.xml
+++ b/man/bootup.xml
@@ -50,34 +50,37 @@
Description
- 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 now (optionally) extracts and
- executes an initial RAM disk image (initrd) such as
- dracut8
- which looks for the root file system. After the root
- file system is found and mounted the initrd hands over
- control to the system manager (such as
+ 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
+ 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
+ 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.
@@ -88,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
@@ -97,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.
@@ -132,35 +135,35 @@
v
sysinit.target
|
- _________________/|\___________________
- / | \
- | | |
- v | v
- (various | rescue.service
- sockets...) | |
- | | v
- v | rescue.target
- sockets.target |
- | |
- \_________________ |
- \|
+ ____________________________________/|\________________________________________
+ / | | | \
+ | | | | |
+ v v | v v
+ (various (various | (various rescue.service
+ timers...) paths...) | sockets...) |
+ | | | | v
+ v v | v rescue.target
+ timers.target paths.target | sockets.target
+ | | | |
+ v |_________________ | ___________________/
+ \|/
v
basic.target
|
- __________________________________/| emergency.service
- / | | |
- | | | v
- v v v emergency.target
- display- (various system (various system
- manager.service services services)
- | required for |
- | graphical UIs) v
- | | multi-user.target
- | | |
- \_______________ | _________________/
+ ____________________________________/| emergency.service
+ / | | |
+ | | | v
+ v v v emergency.target
+ display- (various system (various system
+ manager.service services services)
+ | required for |
+ | graphical UIs) v
+ | | multi-user.target
+ | | |
+ \_________________ | _________________/
\|/
v
- graphical.target
+ graphical.target
Target units that are commonly used as boot
targets are emphasized. These
@@ -171,14 +174,107 @@
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
+ inside the initrd follows the following
+ structure.
+
+ The default target in the initrd is
+ initrd.target. The bootup process
+ begins identical to the system manager bootup (see
+ above) until it reaches
+ basic.target. From there, systemd
+ approaches the special target
+ initrd.target. If the root device
+ can be mounted at /sysroot, the
+ sysroot.mount unit becomes active
+ and initrd-root-fs.target is
+ reached. The service
+ initrd-parse-etc.service scans
+ /sysroot/etc/fstab for a possible
+ /usr mount point and additional
+ entries marked with the
+ x-initrd.mount option. All
+ entries found are mounted below
+ /sysroot, and
+ initrd-fs.target is reached. The
+ service initrd-cleanup.service
+ isolates to the
+ initrd-switch-root.target, where
+ cleanup services can run. As the very last step, the
+ initrd-switch-root.service is
+ activated, which will cause the system to switch its
+ root to /sysroot.
+
+
+ : (beginning identical to above)
+ :
+ v
+ basic.target
+ | emergency.service
+ ______________________/| |
+ / | v
+ | sysroot.mount emergency.target
+ | |
+ | v
+ | initrd-root-fs.target
+ | |
+ | v
+ v initrd-parse-etc.service
+ (custom initrd |
+ services...) v
+ | (sysroot-usr.mount and
+ | various mounts marked
+ | with fstab option
+ | x-initrd.mount...)
+ | |
+ | v
+ | initrd-fs.target
+ \______________________ |
+ \|
+ v
+ initrd.target
+ |
+ v
+ initrd-cleanup.service
+ isolates to
+ initrd-switch-root.target
+ |
+ v
+ ______________________/|
+ / v
+ | initrd-udevadm-cleanup-db.service
+ v |
+ (custom initrd |
+ services...) |
+ \______________________ |
+ \|
+ v
+ initrd-switch-root.target
+ |
+ v
+ initrd-switch-root.service
+ |
+ v
+ Transition to Host OS
+
System Manager Shutdown
- System shutdown also consists of various target
- units with some minimal ordering structure
- applied:
+ System shutdown with systemd also consists of
+ various target units with some minimal ordering
+ structure applied:
@@ -217,9 +313,10 @@ systemd-reboot.service systemd-poweroff.service systemd-halt.service syste
See Also
systemd1,
- boot7,
+ boot7,
systemd.special7,
- systemd.target5
+ systemd.target5,
+ dracut8