<?xml version='1.0'?> <!--*-nxml-*-->
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+<!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+
-
- 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/>.
--->
+<!-- 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>
<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
+ <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 (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>
+ 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
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>local-fs-pre.target
|
v
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
+ <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
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>
+ <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>
<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>
projects / thirdparty / systemd.git / blobdiff