diff --git a/Makefile.am b/Makefile.am index 276c2265d6..e4fcecbba6 100644 --- a/Makefile.am +++ b/Makefile.am @@ -462,6 +462,7 @@ MANPAGES = \ man/systemd.journal-fields.7 \ man/kernel-command-line.7 \ man/daemon.7 \ + man/bootup.7 \ man/runlevel.8 \ man/telinit.8 \ man/halt.8 \ diff --git a/man/bootup.xml b/man/bootup.xml new file mode 100644 index 0000000000..ae84cff0b7 --- /dev/null +++ b/man/bootup.xml @@ -0,0 +1,226 @@ + + + + + + + + + bootup + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + bootup + 7 + + + + bootup + The 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 persistant + 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 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 follow 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 +(various mounts and (various swap (various cryptsetup + fsck services...) devices...) devices...) (various low-level (various low-level + | | | services: udevd, API VFS mounts: + v v v tmpfiles, random mqueue, configfs, + local-fs.target swap.target cryptsetup.target seed, sysctl, ...) debugfs, ...) + | | | | | + \__________________|_________________ | ___________________|____________________/ + \|/ + v + sysinit.target + | + _________________/|\___________________ + / | \ + | | | + v | v + (various | rescue.service + sockets...) | | + | | v + v | rescue.target + sockets.target | + | | + \_________________ | + \| + v + basic.target + | + _________________/| emergency.service + / | | + | | v + v v emergency.target + (various system (various system + services services) + required for | + graphical UIs) v + | multi-user.target + | | + | _________________/ + |/ + v + 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. + + + + System Manager Shutdown + + System shutdown also consists of various target + units with some minimal ordering structure + applied: + + + + + (conflicts with (conflicts with + all system all file system + services) mounts, swaps, + | cryptsetup + | devices, ...) + | | + v v + shutdown.target umount.target + | | + \_______ ______/ + \ / + v + (various low-level + services) + | + v + final.target + | + __________________________/ \_____________________ + / | | \ + | | | | + v v v v +reboot.service poweroff.service halt.service kexec.service + | | | | + 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 + + + + diff --git a/man/systemd.special.xml b/man/systemd.special.xml index 96befd5f5d..4321f54698 100644 --- a/man/systemd.special.xml +++ b/man/systemd.special.xml @@ -845,7 +845,8 @@ systemd.unit5, systemd.service5, systemd.socket5, - systemd.target5 + systemd.target5, + bootup7 diff --git a/man/systemd.xml b/man/systemd.xml index d3d722a23e..5168049be4 100644 --- a/man/systemd.xml +++ b/man/systemd.xml @@ -1231,7 +1231,8 @@ systemd.unit5, systemd.special5, pkg-config1, - kernel-command-line7 + kernel-command-line7, + bootup7