mirror of
https://git.proxmox.com/git/systemd
synced 2025-07-16 12:23:48 +00:00
223 lines
16 KiB
HTML
223 lines
16 KiB
HTML
<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>bootup</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><style>
|
|
a.headerlink {
|
|
color: #c60f0f;
|
|
font-size: 0.8em;
|
|
padding: 0 4px 0 4px;
|
|
text-decoration: none;
|
|
visibility: hidden;
|
|
}
|
|
|
|
a.headerlink:hover {
|
|
background-color: #c60f0f;
|
|
color: white;
|
|
}
|
|
|
|
h1:hover > a.headerlink, h2:hover > a.headerlink, h3:hover > a.headerlink, dt:hover > a.headerlink {
|
|
visibility: visible;
|
|
}
|
|
</style><a href="index.html">Index </a>·
|
|
<a href="systemd.directives.html">Directives </a>·
|
|
<a href="../python-systemd/index.html">Python </a>·
|
|
<a href="../libudev/index.html">libudev </a>·
|
|
<a href="../libudev/index.html">gudev </a><span style="float:right">systemd 219</span><hr><div class="refentry"><a name="bootup"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>bootup — System bootup process</p></div><div class="refsect1"><a name="idm140621163247792"></a><h2 id="Description">Description<a class="headerlink" title="Permalink to this headline" href="#Description">¶</a></h2><p>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
|
|
<a href="http://linux.die.net/man/8/dracut"><span class="citerefentry"><span class="refentrytitle">dracut</span>(8)</span></a>,
|
|
which looks for the root file system (possibly using
|
|
<a href="systemd.html"><span class="citerefentry"><span class="refentrytitle">systemd</span>(1)</span></a>
|
|
for this). After the root file system is found and mounted, the
|
|
initrd hands over control to the host's system manager (such as
|
|
<a href="systemd.html"><span class="citerefentry"><span class="refentrytitle">systemd</span>(1)</span></a>)
|
|
stored on the OS image, which is then responsible for probing all
|
|
remaining hardware, mounting all necessary file systems and
|
|
spawning all configured services.</p><p>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.</p><p>Additional information about the system boot process may be
|
|
found in
|
|
<a href="http://man7.org/linux/man-pages/man7/boot.7.html"><span class="citerefentry"><span class="refentrytitle">boot</span>(7)</span></a>.</p></div><div class="refsect1"><a name="idm140621163241104"></a><h2 id="System Manager Bootup">System Manager Bootup<a class="headerlink" title="Permalink to this headline" href="#System%20Manager%20Bootup">¶</a></h2><p>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
|
|
<a href="systemd.html"><span class="citerefentry"><span class="refentrytitle">systemd</span>(1)</span></a>
|
|
systems, this process is split up in various discrete steps which
|
|
are exposed as target units. (See
|
|
<a href="systemd.target.html"><span class="citerefentry"><span class="refentrytitle">systemd.target</span>(5)</span></a>
|
|
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.</p><p>When systemd starts up the system, it will activate all
|
|
units that are dependencies of <code class="filename">default.target</code>
|
|
(as well as recursively all dependencies of these dependencies).
|
|
Usually, <code class="filename">default.target</code> is simply an alias of
|
|
<code class="filename">graphical.target</code> or
|
|
<code class="filename">multi-user.target</code>, 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
|
|
<a href="systemd.special.html"><span class="citerefentry"><span class="refentrytitle">systemd.special</span>(7)</span></a>.</p><p>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.</p><pre class="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 <span class="emphasis"><em>rescue.target</em></span>
|
|
timers.target paths.target | sockets.target
|
|
| | | |
|
|
v |_________________ | ___________________/
|
|
\|/
|
|
v
|
|
basic.target
|
|
|
|
|
____________________________________/| emergency.service
|
|
/ | | |
|
|
| | | v
|
|
v v v <span class="emphasis"><em>emergency.target</em></span>
|
|
display- (various system (various system
|
|
manager.service services services)
|
|
| required for |
|
|
| graphical UIs) v
|
|
| | <span class="emphasis"><em>multi-user.target</em></span>
|
|
| | |
|
|
\_________________ | _________________/
|
|
\|/
|
|
v
|
|
<span class="emphasis"><em>graphical.target</em></span></pre><p>Target units that are commonly used as boot targets are
|
|
<span class="emphasis"><em>emphasized</em></span>. These units are good choices as
|
|
goal targets, for example by passing them to the
|
|
<code class="varname">systemd.unit=</code> kernel command line option (see
|
|
<a href="systemd.html"><span class="citerefentry"><span class="refentrytitle">systemd</span>(1)</span></a>)
|
|
or by symlinking <code class="filename">default.target</code> to them.
|
|
</p><p><code class="filename">timers.target</code> is pulled-in by
|
|
<code class="filename">basic.target</code> asynchronously. This allows
|
|
timers units to depend on services which become only available
|
|
later in boot.</p></div><div class="refsect1"><a name="idm140621167127680"></a><h2 id="Bootup in the Initial RAM Disk (initrd)">Bootup in the Initial RAM Disk (initrd)<a class="headerlink" title="Permalink to this headline" href="#Bootup%20in%20the%20Initial%20RAM%20Disk%20(initrd)">¶</a></h2><p>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.</p><p>The default target in the initrd is
|
|
<code class="filename">initrd.target</code>. The bootup process begins
|
|
identical to the system manager bootup (see above) until it
|
|
reaches <code class="filename">basic.target</code>. From there, systemd
|
|
approaches the special target <code class="filename">initrd.target</code>.
|
|
If the root device can be mounted at
|
|
<code class="filename">/sysroot</code>, the
|
|
<code class="filename">sysroot.mount</code> unit becomes active and
|
|
<code class="filename">initrd-root-fs.target</code> is reached. The service
|
|
<code class="filename">initrd-parse-etc.service</code> scans
|
|
<code class="filename">/sysroot/etc/fstab</code> for a possible
|
|
<code class="filename">/usr</code> mount point and additional entries
|
|
marked with the <span class="emphasis"><em>x-initrd.mount</em></span> option. All
|
|
entries found are mounted below <code class="filename">/sysroot</code>, and
|
|
<code class="filename">initrd-fs.target</code> is reached. The service
|
|
<code class="filename">initrd-cleanup.service</code> isolates to the
|
|
<code class="filename">initrd-switch-root.target</code>, where cleanup
|
|
services can run. As the very last step, the
|
|
<code class="filename">initrd-switch-root.service</code> is activated,
|
|
which will cause the system to switch its root to
|
|
<code class="filename">/sysroot</code>.
|
|
</p><pre class="programlisting"> : (beginning identical to above)
|
|
:
|
|
v
|
|
basic.target
|
|
| emergency.service
|
|
______________________/| |
|
|
/ | v
|
|
| sysroot.mount <span class="emphasis"><em>emergency.target</em></span>
|
|
| |
|
|
| 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</pre></div><div class="refsect1"><a name="idm140621167101792"></a><h2 id="System Manager Shutdown">System Manager Shutdown<a class="headerlink" title="Permalink to this headline" href="#System%20Manager%20Shutdown">¶</a></h2><p>System shutdown with systemd also consists of various target
|
|
units with some minimal ordering structure applied:</p><pre class="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
|
|
<span class="emphasis"><em>reboot.target</em></span> <span class="emphasis"><em>poweroff.target</em></span> <span class="emphasis"><em>halt.target</em></span> <span class="emphasis"><em>kexec.target</em></span></pre><p>Commonly used system shutdown targets are
|
|
<span class="emphasis"><em>emphasized</em></span>.</p></div><div class="refsect1"><a name="idm140621167095680"></a><h2 id="See Also">See Also<a class="headerlink" title="Permalink to this headline" href="#See%20Also">¶</a></h2><p>
|
|
<a href="systemd.html"><span class="citerefentry"><span class="refentrytitle">systemd</span>(1)</span></a>,
|
|
<a href="http://man7.org/linux/man-pages/man7/boot.7.html"><span class="citerefentry"><span class="refentrytitle">boot</span>(7)</span></a>,
|
|
<a href="systemd.special.html"><span class="citerefentry"><span class="refentrytitle">systemd.special</span>(7)</span></a>,
|
|
<a href="systemd.target.html"><span class="citerefentry"><span class="refentrytitle">systemd.target</span>(5)</span></a>,
|
|
<a href="http://linux.die.net/man/8/dracut"><span class="citerefentry"><span class="refentrytitle">dracut</span>(8)</span></a>
|
|
</p></div></div></body></html>
|