--- /dev/null
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+ "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+
+<!--
+ This file is part of systemd.
+
+ Copyright 2012 Lennart Poettering
+
+ systemd is free software; you can redistribute it and/or modify it
+ under the terms of the GNU Lesser General Public License as published by
+ the Free Software Foundation; either version 2.1 of the License, or
+ (at your option) any later version.
+
+ systemd is distributed in the hope that it will be useful, but
+ WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public License
+ along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="bootup">
+
+ <refentryinfo>
+ <title>bootup</title>
+ <productname>systemd</productname>
+
+ <authorgroup>
+ <author>
+ <contrib>Developer</contrib>
+ <firstname>Lennart</firstname>
+ <surname>Poettering</surname>
+ <email>lennart@poettering.net</email>
+ </author>
+ </authorgroup>
+ </refentryinfo>
+
+ <refmeta>
+ <refentrytitle>bootup</refentrytitle>
+ <manvolnum>7</manvolnum>
+ </refmeta>
+
+ <refnamediv>
+ <refname>bootup</refname>
+ <refpurpose>The System Bootup Process</refpurpose>
+ </refnamediv>
+
+ <refsect1>
+ <title>Description</title>
+
+ <para>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
+ <citerefentry><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+ 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
+ <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>)
+ stored on the OS image which is then responsible for
+ probing all remaining hardware, mounting all necessary
+ file systems and spawning all configured
+ services.</para>
+
+ <para>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.</para>
+
+ <para>Additional information about the system boot
+ process may be found in
+ <citerefentry><refentrytitle>boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+ </refsect1>
+
+ <refsect1>
+ <title>System Manager Bootup</title>
+
+ <para>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
+ <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+ systems this process is split up in various discrete
+ steps which are exposed as target units. (See
+ <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ 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.</para>
+
+ <para>When systemd starts up the system it will
+ activate all units that are dependencies of
+ <filename>default.target</filename> (as well as
+ recursively all dependencies of these
+ dependencies). Usually
+ <filename>default.target</filename> is simply an alias
+ of <filename>graphical.target</filename> or
+ <filename>multi-user.target</filename> 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
+ <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+
+ <para>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.</para>
+
+<programlisting>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 | <emphasis>rescue.target</emphasis>
+ sockets.target |
+ | |
+ \_________________ |
+ \|
+ v
+ basic.target
+ |
+ _________________/| emergency.service
+ / | |
+ | | v
+ v v <emphasis>emergency.target</emphasis>
+ (various system (various system
+ services services)
+ required for |
+ graphical UIs) v
+ | <emphasis>multi-user.target</emphasis>
+ | |
+ | _________________/
+ |/
+ v
+ <emphasis>graphical.target</emphasis></programlisting>
+
+ <para>Target units that are commonly used as boot
+ targets are <emphasis>emphasized</emphasis>. These
+ units are good choices as goal targets, for
+ example by passing them to the
+ <varname>systemd.unit=</varname> kernel command line
+ option (see
+ <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>)
+ or by symlinking <filename>default.target</filename>
+ to them.</para>
+ </refsect1>
+
+ <refsect1>
+ <title>System Manager Shutdown</title>
+
+ <para>System shutdown also consists of various target
+ units with some minimal ordering structure
+ applied:</para>
+
+
+
+
+<programlisting> (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
+<emphasis>reboot.target</emphasis> <emphasis>poweroff.target</emphasis> <emphasis>halt.target</emphasis> <emphasis>kexec.target</emphasis></programlisting>
+
+ <para>Commonly used system shutdown targets are <emphasis>emphasized</emphasis>.</para>
+ </refsect1>
+
+ <refsect1>
+ <title>See Also</title>
+ <para>
+ <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ </para>
+ </refsect1>
+
+</refentry>
~ianmdlvl / elogind.git / commitdiff