<?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/>.
--->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+ "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1+ -->
<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 project='die-net'><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 project='man-pages'><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 |_________________ | ___________________/
- \|/
- 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>
-
- <para><filename>timers.target</filename> is pulled-in
- by <filename>basic.target</filename> asynchronously.
- This allows timers units to depend on services which
- become only available later in boot.</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>
+ <refentryinfo>
+ <title>bootup</title>
+ <productname>systemd</productname>
+ </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 boot of a Linux system. Immediately after
+ power-up, the system firmware will do minimal hardware initialization, and hand control over to a boot
+ loader (e.g.
+ <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry> or
+ <ulink url="https://www.gnu.org/software/grub/">GRUB</ulink>) stored on a persistent storage device. This
+ boot loader will then invoke an OS kernel from disk (or the network). On systems using EFI or other types
+ of firmware, this firmware may also load the kernel directly.</para>
+
+ <para>The kernel (optionally) mounts an in-memory file system, often generated by
+ <citerefentry project='die-net'><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+ which looks for the root file system. Nowadays this is usually implemented as an initramfs — a compressed
+ archive which is extracted when the kernel boots up into a lightweight in-memory file system based on
+ tmpfs, but in the past normal file systems using an in-memory block device (ramdisk) were used, and the
+ name "initrd" is still used to describe both concepts. It's the boot loader or the firmware that loads
+ both the kernel and initrd/initramfs images into memory, but the kernel which interprets it as a file
+ system. <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> may
+ be used to manage services in the initrd, similarly to the real system.</para>
+
+ <para>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 in
+ the root file system, 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 project='man-pages'><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>
+
+ <!-- note: do not use unicode ellipsis here, because docbook will replace that
+ with three dots anyway, messing up alignment -->
+<programlisting> cryptsetup-pre.target
+ |
+(various low-level v
+ API VFS mounts: (various cryptsetup devices...)
+ mqueue, configfs, | |
+ debugfs, ...) v |
+ | cryptsetup.target |
+ | (various swap | | remote-fs-pre.target
+ | devices...) | | | |
+ | | | | | v
+ | v local-fs-pre.target | | | (network file systems)
+ | swap.target | | v v |
+ | | v | remote-cryptsetup.target |
+ | | (various low-level (various mounts and | | |
+ | | services: udevd, fsck services...) | | remote-fs.target
+ | | tmpfiles, random | | | /
+ | | seed, sysctl, ...) v | | /
+ | | | local-fs.target | | /
+ | | | | | | /
+ \____|______|_______________ ______|___________/ | /
+ \ / | /
+ v | /
+ sysinit.target | /
+ | | /
+ ______________________/|\_____________________ | /
+ / | | | \ | /
+ | | | | | | /
+ v v | v | | /
+ (various (various | (various | |/
+ timers...) paths...) | sockets...) | |
+ | | | | | |
+ v v | v | |
+timers.target paths.target | sockets.target | |
+ | | | | v |
+ v \_______ | _____/ rescue.service |
+ \|/ | |
+ v v |
+ basic.target <emphasis>rescue.target</emphasis> |
+ | |
+ ________v____________________ |
+ / | \ |
+ | | | |
+ v v v |
+ display- (various system (various system |
+ manager.service services services) |
+ | required for | |
+ | graphical UIs) v v
+ | | <emphasis>multi-user.target</emphasis>
+emergency.service | | |
+ | \_____________ | _____________/
+ v \|/
+<emphasis>emergency.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>
+
+ <para><filename>timers.target</filename> is pulled-in by
+ <filename>basic.target</filename> asynchronously. This allows
+ timers units to depend on services which become only available
+ later in boot.</para>
+ </refsect1>
+
+ <refsect1>
+ <title>User manager startup</title>
+
+ <para>The system manager starts the <filename>user@<replaceable>uid</replaceable>.service</filename> unit
+ for each user, which launches a separate unprivileged instance of <command>systemd</command> for each
+ user — the user manager. Similarly to the system manager, the user manager starts units which are pulled
+ in by <filename>default.target</filename>. The following chart is a structural overview of the well-known
+ user units. For non-graphical sessions, <filename>default.target</filename> is used. Whenever the user
+ logs into a graphical session, the login manager will start the
+ <filename>graphical-session.target</filename> target that is used to pull in units required for the
+ grahpical session. A number of targets (shown on the right side) are started when specific hardware is
+ available to the user.</para>
+
+<programlisting>
+ (various (various (various
+ timers...) paths...) sockets...) (sound devices)
+ | | | |
+ v v v v
+ timers.target paths.target sockets.target sound.target
+ | | |
+ \______________ _|_________________/ (bluetooth devices)
+ \ / |
+ V v
+ basic.target bluetooth.target
+ |
+ __________/ \_______ (smartcard devices)
+ / \ |
+ | | v
+ | v smartcard.target
+ v graphical-session-pre.target
+ (various user services) | (printers)
+ | v |
+ | (services for the graphical sesion) v
+ | | printer.target
+ v v
+ <emphasis>default.target</emphasis> graphical-session.target</programlisting>
+
+ </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>systemd detects that it is run within an initrd by checking
+ for the file <filename>/etc/initrd-release</filename>.
+ 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>.
+
+ Before any file systems are mounted, it must be determined whether
+ the system will resume from hibernation or proceed with normal boot.
+ This is accomplished by <filename>systemd-hibernate-resume@.service</filename>
+ which must be finished before <filename>local-fs-pre.target</filename>,
+ so no filesystems can be mounted before the check is complete.
+
+ When the root device becomes available,
+ <filename>initd-root-device.target</filename> is reached.
+ 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)
:
| emergency.service
______________________/| |
/ | v
- | sysroot.mount <emphasis>emergency.target</emphasis>
+ | initrd-root-device.target <emphasis>emergency.target</emphasis>
+ | |
+ | v
+ | sysroot.mount
| |
| v
| initrd-root-fs.target
|
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>
-
+ </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
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 project='man-pages'><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 project='die-net'><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>
- </para>
- </refsect1>
+ <para>Commonly used system shutdown targets are <emphasis>emphasized</emphasis>.</para>
+
+ <para>Note that
+ <citerefentry><refentrytitle>systemd-halt.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+ <filename>systemd-reboot.service</filename>, <filename>systemd-poweroff.service</filename> and
+ <filename>systemd-kexec.service</filename> will transition the system and server manager (PID 1) into the second
+ phase of system shutdown (implemented in the <filename>systemd-shutdown</filename> binary), which will unmount any
+ remaining file systems, kill any remaining processes and release any other remaining resources, in a simple and
+ robust fashion, without taking any service or unit concept into account anymore. At that point, regular
+ applications and resources are generally terminated and released already, the second phase hence operates only as
+ safety net for everything that couldn't be stopped or released for some reason during the primary, unit-based
+ shutdown phase described above.</para>
+ </refsect1>
+
+ <refsect1>
+ <title>See Also</title>
+ <para>
+ <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+ <citerefentry project='man-pages'><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>systemd-halt.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+ <citerefentry project='die-net'><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+ </para>
+ </refsect1>
</refentry>
projects / thirdparty / systemd.git / blobdiff