summaryrefslogtreecommitdiff
path: root/man/bootup.xml
diff options
context:
space:
mode:
Diffstat (limited to 'man/bootup.xml')
-rw-r--r--man/bootup.xml226
1 files changed, 0 insertions, 226 deletions
diff --git a/man/bootup.xml b/man/bootup.xml
deleted file mode 100644
index 4cc4bafab7..0000000000
--- a/man/bootup.xml
+++ /dev/null
@@ -1,226 +0,0 @@
-<?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 now (optionally) extracts and
- executes an initial RAM disk image (initrd) such as
- <citerefentry><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>
- which looks for the root file system. After the root
- file system is found and mounted the initrd hands over
- control to the 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 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
- (various | rescue.service
- sockets...) | |
- | | v
- v | <emphasis>rescue.target</emphasis>
- 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>System Manager Shutdown</title>
-
- <para>System shutdown 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>
- </para>
- </refsect1>
-
-</refentry>