mirror of
https://github.com/systemd/systemd.git
synced 2024-12-30 04:23:33 +08:00
319 lines
17 KiB
XML
319 lines
17 KiB
XML
<?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>
|
|
</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
|
|
executes an initial RAM disk image (initrd), such as
|
|
generated by
|
|
<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
|
|
<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 a last step, the system is 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 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.</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
|
|
| | | |
|
|
\__________________|_________________ | ___________________/
|
|
\|/
|
|
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>
|
|
| | |
|
|
\_________________ | _________________/
|
|
\|/
|
|
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>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>
|
|
|
|
|
|
<refsect1>
|
|
<title>System Manager Shutdown</title>
|
|
|
|
<para>System shutdown with systemd 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
|
|
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>
|
|
|
|
<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>,
|
|
<citerefentry><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
|
</para>
|
|
</refsect1>
|
|
|
|
</refentry>
|