<refnamediv>
<refname>bootup</refname>
- <refpurpose>The System Bootup Process</refpurpose>
+ <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 persistant
- 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
+ <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
+ 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
+ <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>
+ 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
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
+ 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
deterministic, but still adheres to a limited amount
of ordering structure.</para>
- <para>When systemd starts up the system it will
+ <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
+ dependencies). Usually,
<filename>default.target</filename> is simply an alias
of <filename>graphical.target</filename> or
- <filename>multi-user.target</filename> depending on
+ <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
+ 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 follow chart is a structural overview of
+ <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
v
sysinit.target
|
- _________________/|\___________________
- / | \
- | | |
- v | v
- (various | rescue.service
- sockets...) | |
- | | v
- v | <emphasis>rescue.target</emphasis>
- sockets.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 <emphasis>emergency.target</emphasis>
- (various system (various system
- services services)
- required for |
- graphical UIs) v
- | <emphasis>multi-user.target</emphasis>
- | |
- | _________________/
- |/
+ ____________________________________/| 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>
+ <emphasis>graphical.target</emphasis></programlisting>
<para>Target units that are commonly used as boot
targets are <emphasis>emphasized</emphasis>. These
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 also consists of various target
- units with some minimal ordering structure
- applied:</para>
+ <para>System shutdown with systemd also consists of
+ various target units with some minimal ordering
+ structure applied:</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>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>
</para>
</refsect1>
~ianmdlvl / elogind.git / blobdiff