2012-06-23 01:14:19 +04: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: / / w w w . g n u . o r g / l i c e n s e s /> .
-->
<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>
2012-07-16 20:08:25 +04:00
<refpurpose > System bootup process</refpurpose>
2012-06-23 01:14:19 +04:00
</refnamediv>
<refsect1 >
<title > Description</title>
2013-03-26 00:20:08 +04:00
<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-23 01:14:19 +04:00
executes an initial RAM disk image (initrd) such as
<citerefentry > <refentrytitle > dracut</refentrytitle> <manvolnum > 8</manvolnum> </citerefentry>
2013-03-26 00:20:08 +04:00
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-23 01:14:19 +04: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
2012-06-26 01:00:38 +04:00
it resides on. As last step the system is powered down.</para>
2012-06-23 01:14:19 +04: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>
2012-09-04 21:24:16 +04:00
<para > The following chart is a structural overview of
2012-06-23 01:14:19 +04: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
|
2013-03-26 00:20:08 +04:00
____________________________________/|\________________________________________
/ | | | \
| | | | |
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-23 01:14:19 +04:00
v
basic.target
|
2013-03-26 00:20:08 +04:00
____________________________________/| 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-28 00:21:35 +04:00
\|/
2012-06-23 01:14:19 +04:00
v
2013-03-26 00:20:08 +04:00
<emphasis > graphical.target</emphasis> </programlisting>
2012-06-23 01:14:19 +04: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>
2013-03-14 16:12:10 +04:00
<refsect1 >
2013-03-26 00:20:08 +04:00
<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> .
2013-03-14 16:12:10 +04:00
</para>
2013-03-26 00:20:08 +04:00
<programlisting > : (beginning identical to above)
2013-03-14 16:12:10 +04:00
:
v
basic.target
| emergency.service
______________________/| |
/ | v
| sysroot.mount <emphasis > emergency.target</emphasis>
| |
| v
| initrd-root-fs.target
| |
| v
2013-03-26 00:20:08 +04:00
v initrd-parse-etc.service
(custom initrd |
services...) v
2013-03-14 16:12:10 +04:00
| (sysroot-usr.mount and
| various mounts marked
| with fstab option
2013-03-26 00:20:08 +04:00
| x-initrd.mount...)
2013-03-14 16:12:10 +04:00
| |
| v
| initrd-fs.target
\______________________ |
\|
v
initrd.target
|
v
initrd-cleanup.service
isolates to
initrd-switch-root.target
|
v
______________________/|
2013-03-26 00:20:08 +04:00
/ v
2013-03-14 16:12:10 +04:00
| initrd-udevadm-cleanup-db.service
2013-03-26 00:20:08 +04:00
v |
(custom initrd |
services...) |
2013-03-14 16:12:10 +04:00
\______________________ |
\|
v
initrd-switch-root.target
|
v
initrd-switch-root.service
|
v
2013-03-26 00:20:08 +04:00
Transition to Host OS</programlisting>
2013-03-14 16:12:10 +04:00
</refsect1>
2012-06-23 01:14:19 +04:00
<refsect1 >
<title > System Manager Shutdown</title>
2013-03-26 00:20:08 +04:00
<para > System shutdown with systemd also consists of
various target units with some minimal ordering
structure applied:</para>
2012-06-23 01:14:19 +04:00
2012-06-25 16:24:56 +04: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-23 01:14:19 +04: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-02-01 00:52:13 +04:00
<citerefentry > <refentrytitle > systemd.target</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry> ,
<citerefentry > <refentrytitle > dracut</refentrytitle> <manvolnum > 8</manvolnum> </citerefentry>
2012-06-23 01:14:19 +04:00
</para>
</refsect1>
</refentry>
