1 <?xml version='
1.0'
?> <!--*-nxml-*-->
2 <!DOCTYPE refentry PUBLIC
"-//OASIS//DTD DocBook XML V4.5//EN"
3 "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
4 <!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
10 <productname>systemd
</productname>
14 <refentrytitle>bootup
</refentrytitle>
15 <manvolnum>7</manvolnum>
19 <refname>bootup
</refname>
20 <refpurpose>System bootup process
</refpurpose>
24 <title>Description
</title>
26 <para>A number of different components are involved in the boot of a Linux system. Immediately after
27 power-up, the system firmware will do minimal hardware initialization, and hand control over to a boot
29 <citerefentry><refentrytitle>systemd-boot
</refentrytitle><manvolnum>7</manvolnum></citerefentry> or
30 <ulink url=
"https://www.gnu.org/software/grub/">GRUB
</ulink>) stored on a persistent storage device. This
31 boot loader will then invoke an OS kernel from disk (or the network). On systems using EFI or other types
32 of firmware, this firmware may also load the kernel directly.
</para>
34 <para>The kernel (optionally) mounts an in-memory file system, which looks for the root file system.
35 Nowadays this is implemented as an
"initramfs" — a compressed CPIO archive that the kernel extracts into
36 a tmpfs. In the past normal file systems using an in-memory block device (ramdisk) were used, and the
37 name
"initrd" is still used to describe both concepts. It's the boot loader or the firmware that loads
38 both the kernel and initrd/initramfs images into memory, but the kernel which interprets it as a file
40 <citerefentry><refentrytitle>systemd
</refentrytitle><manvolnum>1</manvolnum></citerefentry> may be used
41 to manage services in the initrd, similarly to the real system.
</para>
43 <para>After the root file system is found and mounted, the initrd hands over control to the host's system
45 <citerefentry><refentrytitle>systemd
</refentrytitle><manvolnum>1</manvolnum></citerefentry>) stored in
46 the root file system, which is then responsible for probing all remaining hardware, mounting all
47 necessary file systems and spawning all configured services.
</para>
49 <para>On shutdown, the system manager stops all services, unmounts
50 all file systems (detaching the storage technologies backing
51 them), and then (optionally) jumps back into the initrd code which
52 unmounts/detaches the root file system and the storage it resides
53 on. As a last step, the system is powered down.
</para>
55 <para>Additional information about the system boot process may be
57 <citerefentry project='man-pages'
><refentrytitle>boot
</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
</para>
61 <title>System Manager Bootup
</title>
63 <para>At boot, the system manager on the OS image is responsible
64 for initializing the required file systems, services and drivers
65 that are necessary for operation of the system. On
66 <citerefentry><refentrytitle>systemd
</refentrytitle><manvolnum>1</manvolnum></citerefentry>
67 systems, this process is split up in various discrete steps which
68 are exposed as target units. (See
69 <citerefentry><refentrytitle>systemd.target
</refentrytitle><manvolnum>5</manvolnum></citerefentry>
70 for detailed information about target units.) The boot-up process
71 is highly parallelized so that the order in which specific target
72 units are reached is not deterministic, but still adheres to a
73 limited amount of ordering structure.
</para>
75 <para>When systemd starts up the system, it will activate all
76 units that are dependencies of
<filename>default.target
</filename>
77 (as well as recursively all dependencies of these dependencies).
78 Usually,
<filename>default.target
</filename> is simply an alias of
79 <filename>graphical.target
</filename> or
80 <filename>multi-user.target
</filename>, depending on whether the
81 system is configured for a graphical UI or only for a text
82 console. To enforce minimal ordering between the units pulled in,
83 a number of well-known target units are available, as listed on
84 <citerefentry><refentrytitle>systemd.special
</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
</para>
86 <para>The following chart is a structural overview of these
87 well-known units and their position in the boot-up logic. The
88 arrows describe which units are pulled in and ordered before which
89 other units. Units near the top are started before units nearer to
90 the bottom of the chart.
</para>
92 <!-- note: do not use unicode ellipsis here, because docbook will replace that
93 with three dots anyway, messing up alignment -->
94 <programlisting> cryptsetup-pre.target veritysetup-pre.target
97 API VFS mounts: (various cryptsetup/veritysetup devices...)
100 | cryptsetup.target |
101 | (various swap | | remote-fs-pre.target
102 | devices...) | | | |
104 | v local-fs-pre.target | | | (network file systems)
105 | swap.target | | v v |
106 | | v | remote-cryptsetup.target |
107 | | (various low-level (various mounts and | remote-veritysetup.target |
108 | | services: udevd, fsck services...) | | |
109 | | tmpfiles, random | | | remote-fs.target
110 | | seed, sysctl, ...) v | | |
111 | | | local-fs.target | | _____________/
113 \____|______|_______________ ______|___________/ |
118 ______________________/|\_____________________ |
122 (various (various | (various | |
123 timers...) paths...) | sockets...) | |
126 timers.target paths.target | sockets.target | |
128 v \_______ | _____/ rescue.service |
131 basic.target
<emphasis>rescue.target
</emphasis> |
133 ________v____________________ |
137 display- (various system (various system |
138 manager.service services services) |
141 | |
<emphasis>multi-user.target
</emphasis>
142 emergency.service | | |
143 | \_____________ | _____________/
145 <emphasis>emergency.target
</emphasis> v
146 <emphasis>graphical.target
</emphasis></programlisting>
148 <para>Target units that are commonly used as boot targets are
149 <emphasis>emphasized
</emphasis>. These units are good choices as
150 goal targets, for example by passing them to the
151 <varname>systemd.unit=
</varname> kernel command line option (see
152 <citerefentry><refentrytitle>systemd
</refentrytitle><manvolnum>1</manvolnum></citerefentry>)
153 or by symlinking
<filename>default.target
</filename> to them.
156 <para><filename>timers.target
</filename> is pulled-in by
157 <filename>basic.target
</filename> asynchronously. This allows
158 timers units to depend on services which become only available
159 later in boot.
</para>
163 <title>User manager startup
</title>
165 <para>The system manager starts the
<filename>user@
<replaceable>uid
</replaceable>.service
</filename> unit
166 for each user, which launches a separate unprivileged instance of
<command>systemd
</command> for each
167 user — the user manager. Similarly to the system manager, the user manager starts units which are pulled
168 in by
<filename>default.target
</filename>. The following chart is a structural overview of the well-known
169 user units. For non-graphical sessions,
<filename>default.target
</filename> is used. Whenever the user
170 logs into a graphical session, the login manager will start the
171 <filename>graphical-session.target
</filename> target that is used to pull in units required for the
172 graphical session. A number of targets (shown on the right side) are started when specific hardware is
173 available to the user.
</para>
176 (various (various (various
177 timers...) paths...) sockets...) (sound devices)
180 timers.target paths.target sockets.target sound.target
182 \______________ _|_________________/ (bluetooth devices)
185 basic.target bluetooth.target
187 __________/ \_______ (smartcard devices)
191 v graphical-session-pre.target
192 (various user services) | (printers)
194 | (services for the graphical session) v
197 <emphasis>default.target
</emphasis> graphical-session.target
</programlisting>
202 <title>Bootup in the initrd
</title>
204 <para>Systemd can be used in the initrd as well. It detects the initrd environment by checking for the
205 <filename>/etc/initrd-release
</filename> file. The default target in the initrd is
206 <filename>initrd.target
</filename>. The bootup process is identical to the system manager bootup until
207 the target
<filename>basic.target
</filename>. After that, systemd executes the special target
208 <filename>initrd.target
</filename>.
210 Before any file systems are mounted, the manager will determine whether the system shall resume from
211 hibernation or proceed with normal boot. This is accomplished by
212 <filename>systemd-hibernate-resume.service
</filename> which must be finished before
213 <filename>local-fs-pre.target
</filename>, so no filesystems can be mounted before the check is complete.
215 When the root device becomes available,
216 <filename>initrd-root-device.target
</filename> is reached.
217 If the root device can be mounted at
218 <filename>/sysroot
</filename>, the
219 <filename>sysroot.mount
</filename> unit becomes active and
220 <filename>initrd-root-fs.target
</filename> is reached. The service
221 <filename>initrd-parse-etc.service
</filename> scans
222 <filename>/sysroot/etc/fstab
</filename> for a possible
223 <filename>/usr/
</filename> mount point and additional entries
224 marked with the
<emphasis>x-initrd.mount
</emphasis> option. All
225 entries found are mounted below
<filename>/sysroot
</filename>, and
226 <filename>initrd-fs.target
</filename> is reached. The service
227 <filename>initrd-cleanup.service
</filename> isolates to the
228 <filename>initrd-switch-root.target
</filename>, where cleanup
229 services can run. As the very last step, the
230 <filename>initrd-switch-root.service
</filename> is activated,
231 which will cause the system to switch its root to
232 <filename>/sysroot
</filename>.
235 <programlisting> : (beginning identical to above)
240 ______________________/| |
242 | initrd-root-device.target
<emphasis>emergency.target
</emphasis>
248 | initrd-root-fs.target
251 v initrd-parse-etc.service
254 | (sysroot-usr.mount and
255 | various mounts marked
261 \______________________ |
267 initrd-cleanup.service
269 initrd-switch-root.target
272 ______________________/|
274 | initrd-udevadm-cleanup-db.service
278 \______________________ |
281 initrd-switch-root.target
284 initrd-switch-root.service
287 Transition to Host OS
</programlisting>
291 <title>System Manager Shutdown
</title>
293 <para>System shutdown with systemd also consists of various target
294 units with some minimal ordering structure applied:
</para>
296 <programlisting> (conflicts with (conflicts with
297 all system all file system
298 services) mounts, swaps,
304 shutdown.target umount.target
315 ___________________________/ \_________________
319 systemd-reboot.service | | |
321 | systemd-poweroff.service | |
323 <emphasis>reboot.target
</emphasis> | systemd-halt.service |
325 <emphasis>poweroff.target
</emphasis> | systemd-kexec.service
327 <emphasis>halt.target
</emphasis> |
329 <emphasis>kexec.target
</emphasis></programlisting>
331 <para>Commonly used system shutdown targets are
<emphasis>emphasized
</emphasis>.
</para>
334 <citerefentry><refentrytitle>systemd-halt.service
</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
335 <filename>systemd-reboot.service
</filename>,
<filename>systemd-poweroff.service
</filename> and
336 <filename>systemd-kexec.service
</filename> will transition the system and server manager (PID
1) into the second
337 phase of system shutdown (implemented in the
<filename>systemd-shutdown
</filename> binary), which will unmount any
338 remaining file systems, kill any remaining processes and release any other remaining resources, in a simple and
339 robust fashion, without taking any service or unit concept into account anymore. At that point, regular
340 applications and resources are generally terminated and released already, the second phase hence operates only as
341 safety net for everything that couldn't be stopped or released for some reason during the primary, unit-based
342 shutdown phase described above.
</para>
346 <title>See Also
</title>
347 <para><simplelist type=
"inline">
348 <member><citerefentry><refentrytitle>systemd
</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
349 <member><citerefentry project='man-pages'
><refentrytitle>boot
</refentrytitle><manvolnum>7</manvolnum></citerefentry></member>
350 <member><citerefentry><refentrytitle>systemd.special
</refentrytitle><manvolnum>7</manvolnum></citerefentry></member>
351 <member><citerefentry><refentrytitle>systemd.target
</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
352 <member><citerefentry><refentrytitle>systemd-halt.service
</refentrytitle><manvolnum>8</manvolnum></citerefentry></member>