Systemd/man/bootup.xml

318 lines
17 KiB
XML
Raw Normal View History

2012-06-22 23:14:19 +02:00
<?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>System bootup process</refpurpose>
2012-06-22 23:14:19 +02:00
</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
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
2012-06-22 23:14:19 +02:00
executes an initial RAM disk image (initrd) such as
<citerefentry><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>
which looks for the root file system (possibly using
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
for this). After the root file system is found and
mounted the initrd hands over control to the host's
system manager (such as
2012-06-22 23:14:19 +02:00
<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 is powered down.</para>
2012-06-22 23:14:19 +02:00
<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 following chart is a structural overview of
2012-06-22 23:14:19 +02:00
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 | v v
(various (various | (various rescue.service
timers...) paths...) | sockets...) |
| | | | v
v v | v <emphasis>rescue.target</emphasis>
timers.target paths.target | sockets.target
| | | |
\__________________|_________________ | ___________________/
\|/
2012-06-22 23:14:19 +02:00
v
basic.target
|
____________________________________/| emergency.service
/ | | |
| | | v
v v v <emphasis>emergency.target</emphasis>
display- (various system (various system
manager.service services services)
| required for |
| graphical UIs) v
| | <emphasis>multi-user.target</emphasis>
| | |
\_________________ | _________________/
\|/
2012-06-22 23:14:19 +02:00
v
<emphasis>graphical.target</emphasis></programlisting>
2012-06-22 23:14:19 +02:00
<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>Bootup in the Initial RAM Disk (initrd)</title>
<para>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.</para>
<para>The default target in the initrd is
<filename>initrd.target</filename>. The bootup process
begins identical to the system manager bootup (see
above) until it reaches
<filename>basic.target</filename>. From there, systemd
approaches the special target
<filename>initrd.target</filename>. If the root device
can be mounted at <filename>/sysroot</filename>, the
<filename>sysroot.mount</filename> unit becomes active
and <filename>initrd-root-fs.target</filename> is
reached. The service
<filename>initrd-parse-etc.service</filename> scans
<filename>/sysroot/etc/fstab</filename> for a possible
<filename>/usr</filename> mount point and additional
entries marked with the
<emphasis>x-initrd.mount</emphasis> option. All
entries found are mounted below
<filename>/sysroot</filename>, and
<filename>initrd-fs.target</filename> is reached. The
service <filename>initrd-cleanup.service</filename>
isolates to the
<filename>initrd-switch-root.target</filename>, where
cleanup services can run. As the very last step, the
<filename>initrd-switch-root.service</filename> is
activated, which will cause the system to switch its
root to <filename>/sysroot</filename>.
</para>
<programlisting> : (beginning identical to above)
:
v
basic.target
| emergency.service
______________________/| |
/ | v
| sysroot.mount <emphasis>emergency.target</emphasis>
| |
| 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</programlisting>
</refsect1>
2012-06-22 23:14:19 +02:00
<refsect1>
<title>System Manager Shutdown</title>
<para>System shutdown with systemd also consists of
various target units with some minimal ordering
structure applied:</para>
2012-06-22 23:14:19 +02:00
<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
systemd-reboot.service systemd-poweroff.service systemd-halt.service systemd-kexec.service
| | | |
v v v v
<emphasis>reboot.target</emphasis> <emphasis>poweroff.target</emphasis> <emphasis>halt.target</emphasis> <emphasis>kexec.target</emphasis></programlisting>
2012-06-22 23:14:19 +02:00
<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>,
2013-01-31 21:52:13 +01:00
<citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<citerefentry><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>
2012-06-22 23:14:19 +02:00
</para>
</refsect1>
</refentry>