X-Git-Url: https://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=man%2Fbootup.xml;h=ac6e9f70f7b3a008876bbc8daeaf35b3ec97729b;hb=9700d6980f7c212b10a69399e6430b82a6f45587;hp=6bd22ef476c73743e6a441fc9691f45ddf48451c;hpb=9e5f0f92915b777308797294c6e103e430957b5d;p=elogind.git
diff --git a/man/bootup.xml b/man/bootup.xml
index 6bd22ef47..ac6e9f70f 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
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
@@ -174,24 +177,41 @@
- Systemd in the Initrd
- If the initrd creation tool used the services provided
- by systemd, the default target in the initrd is the
- initrd-fs.target. The process is the same as above until the basic.target is reached.
- Systemd now continues to the initrd.target. If the root device could be mounted
- on /sysroot, the sysroot.mount unit is active and the initrd-root-fs.target is reached.
- initrd-parse-etc.service scans /sysroot/etc/fstab for the /usr mountpoint and for entries
- marked with the x-initrd.mount option set. If these mountpoint are
- mounted in /sysroot, the initrd-fs.target is reached.
- The initrd-cleanup.service isolates to the initrd-switch-root.target,
- where cleanup services can run. At the very last end
- initrd-switch-root.service is activated, which will cause
- the system to switch root to /sysroot.
+ 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.
-
- (same as above)
- :
+ : (beginning identical to above)
:
v
basic.target
@@ -204,17 +224,16 @@
| initrd-root-fs.target
| |
| v
- | initrd-parse-etc.service
- (custom initrd services) |
- | v
+ v initrd-parse-etc.service
+ (custom initrd |
+ services...) v
| (sysroot-usr.mount and
| various mounts marked
| with fstab option
- | x-initrd.mount)
+ | x-initrd.mount...)
| |
| v
| initrd-fs.target
- | |
\______________________ |
\|
v
@@ -227,11 +246,11 @@
|
v
______________________/|
- / |
+ / v
| initrd-udevadm-cleanup-db.service
- | |
- (custom initrd services) |
- | |
+ v |
+ (custom initrd |
+ services...) |
\______________________ |
\|
v
@@ -241,17 +260,16 @@
initrd-switch-root.service
|
v
- switch-root
-
+ 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:
@@ -290,10 +308,10 @@ systemd-reboot.service systemd-poweroff.service systemd-halt.service syste
See Also
systemd1,
- boot7,
+ boot7,
systemd.special7,
systemd.target5,
- dracut8
+ dracut8