X-Git-Url: http://git.ipfire.org/?a=blobdiff_plain;f=man%2Fbootup.xml;h=386af9e4ded4ef7d59dbe9cc56fed9eff6c5f2ea;hb=3a54a157605bd7d4bf1be05e28201f3d9422cecc;hp=f65abf5452364219e3a36cbbf941102522de82ee;hpb=0a4c519bd3f5cd00c77e022504f38fc899e23c1b;p=thirdparty%2Fsystemd.git
diff --git a/man/bootup.xml b/man/bootup.xml
index f65abf54523..386af9e4ded 100644
--- a/man/bootup.xml
+++ b/man/bootup.xml
@@ -1,123 +1,90 @@
-
+
+
-
+
+ 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 (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 probing all
+ remaining hardware, mounting all necessary file systems and
+ spawning all configured services.
+
+ 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.
+
+ Additional information about the system boot process may be
+ found in
+ boot7.
+
-
- bootup
- systemd
-
-
-
- Developer
- Lennart
- Poettering
- lennart@poettering.net
-
-
-
-
-
- bootup
- 7
-
-
-
- bootup
- System bootup process
-
-
-
- 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
- systemd1)
- 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
- 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.
-
- Additional information about the system boot
- process may be found in
- boot7.
-
-
-
- System Manager Bootup
-
- 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
- systemd1
- 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
- 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.
-
- 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
- default.target is simply an alias
- of graphical.target or
- 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
- target units are available, as listed on
- systemd.special7.
-
- 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.
+
+ System Manager Bootup
+ 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
+ systemd1
+ 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 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.
+
+ 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, default.target is simply an alias of
+ graphical.target or
+ 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 target units are available, as listed on
+ systemd.special7.
+
+ 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.
+
+
local-fs-pre.target
|
v
@@ -132,56 +99,148 @@
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
- units are good choices as goal targets, for
- example by passing them to the
- systemd.unit= kernel command line
- option (see
- systemd1)
- or by symlinking default.target
- to them.
-
+ Target units that are commonly used as boot targets are
+ emphasized. These units are good choices as
+ goal targets, for example by passing them to the
+ systemd.unit= kernel command line option (see
+ systemd1)
+ or by symlinking default.target to them.
+
-
- System Manager Shutdown
+ timers.target is pulled-in by
+ basic.target asynchronously. This allows
+ timers units to depend on services which become only available
+ later in boot.
+
- System shutdown also consists of various target
- units with some minimal ordering structure
- applied:
+
+ 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.
+ Before any file systems are mounted, it must be determined whether
+ the system will resume from hibernation or proceed with normal boot.
+ This is accomplished by systemd-hibernate-resume@.service
+ which must be finished before local-fs-pre.target,
+ so no filesystems can be mounted before the check is complete.
+ When the root device becomes available,
+ initd-root-device.target is reached.
+ 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
+ | initrd-root-device.target emergency.target
+ | |
+ | v
+ | sysroot.mount
+ | |
+ | 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 with systemd also consists of various target
+ units with some minimal ordering structure applied:
(conflicts with (conflicts with
all system all file system
@@ -210,18 +269,30 @@ systemd-reboot.service systemd-poweroff.service systemd-halt.service syste
v v v v
reboot.target poweroff.target halt.target kexec.target
- Commonly used system shutdown targets are emphasized.
-
-
-
- See Also
-
- systemd1,
- boot7,
- systemd.special7,
- systemd.target5,
- dracut8
-
-
+ Commonly used system shutdown targets are emphasized.
+
+ Note that
+ systemd-halt.service8,
+ systemd-reboot.service, systemd-poweroff.service and
+ systemd-kexec.service will transition the system and server manager (PID 1) into the second
+ phase of system shutdown (implemented in the systemd-shutdown binary), which will unmount any
+ remaining file systems, kill any remaining processes and release any other remaining resources, in a simple and
+ robust fashion, without taking any service or unit concept into account anymore. At that point, regular
+ applications and resources are generally terminated and released already, the second phase hence operates only as
+ safety net for everything that couldn't be stopped or released for some reason during the primary, unit-based
+ shutdown phase described above.
+
+
+
+ See Also
+
+ systemd1,
+ boot7,
+ systemd.special7,
+ systemd.target5,
+ systemd-halt.service8,
+ dracut8
+
+