+++ /dev/null
-<?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 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>
-
-<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 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>
-
-</refentry>
~ianmdlvl / elogind.git / blobdiff