]> git.ipfire.org Git - thirdparty/systemd.git/blob - man/bootup.xml
Merge pull request #12130 from keszybz/fix-ndebug-builds
[thirdparty/systemd.git] / man / bootup.xml
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.2/docbookx.dtd">
4 <!-- SPDX-License-Identifier: LGPL-2.1+ -->
5
6 <refentry id="bootup">
7
8 <refentryinfo>
9 <title>bootup</title>
10 <productname>systemd</productname>
11 </refentryinfo>
12
13 <refmeta>
14 <refentrytitle>bootup</refentrytitle>
15 <manvolnum>7</manvolnum>
16 </refmeta>
17
18 <refnamediv>
19 <refname>bootup</refname>
20 <refpurpose>System bootup process</refpurpose>
21 </refnamediv>
22
23 <refsect1>
24 <title>Description</title>
25
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
28 loader (e.g.
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>
33
34 <para>The kernel (optionally) mounts an in-memory file system, often generated by
35 <citerefentry project='die-net'><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
36 which looks for the root file system. Nowadays this is usually implemented as an initramfs — a compressed
37 archive which is extracted when the kernel boots up into a lightweight in-memory file system based on
38 tmpfs, but in the past normal file systems using an in-memory block device (ramdisk) were used, and the
39 name "initrd" is still used to describe both concepts. It's the boot loader or the firmware that loads
40 both the kernel and initrd/initramfs images into memory, but the kernel which interprets it as a file
41 system. <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> may
42 be used to manage services in the initrd, similarly to the real system.</para>
43
44 <para>After the root file system is found and mounted, the initrd hands over control to the host's system
45 manager (such as
46 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>) stored in
47 the root file system, which is then responsible for probing all remaining hardware, mounting all
48 necessary file systems and spawning all configured services.</para>
49
50 <para>On shutdown, the system manager stops all services, unmounts
51 all file systems (detaching the storage technologies backing
52 them), and then (optionally) jumps back into the initrd code which
53 unmounts/detaches the root file system and the storage it resides
54 on. As a last step, the system is powered down.</para>
55
56 <para>Additional information about the system boot process may be
57 found in
58 <citerefentry project='man-pages'><refentrytitle>boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
59 </refsect1>
60
61 <refsect1>
62 <title>System Manager Bootup</title>
63
64 <para>At boot, the system manager on the OS image is responsible
65 for initializing the required file systems, services and drivers
66 that are necessary for operation of the system. On
67 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
68 systems, this process is split up in various discrete steps which
69 are exposed as target units. (See
70 <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>
71 for detailed information about target units.) The boot-up process
72 is highly parallelized so that the order in which specific target
73 units are reached is not deterministic, but still adheres to a
74 limited amount of ordering structure.</para>
75
76 <para>When systemd starts up the system, it will activate all
77 units that are dependencies of <filename>default.target</filename>
78 (as well as recursively all dependencies of these dependencies).
79 Usually, <filename>default.target</filename> is simply an alias of
80 <filename>graphical.target</filename> or
81 <filename>multi-user.target</filename>, depending on whether the
82 system is configured for a graphical UI or only for a text
83 console. To enforce minimal ordering between the units pulled in,
84 a number of well-known target units are available, as listed on
85 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
86
87 <para>The following chart is a structural overview of these
88 well-known units and their position in the boot-up logic. The
89 arrows describe which units are pulled in and ordered before which
90 other units. Units near the top are started before units nearer to
91 the bottom of the chart.</para>
92
93 <!-- note: do not use unicode ellipsis here, because docbook will replace that
94 with three dots anyway, messing up alignment -->
95 <programlisting>local-fs-pre.target
96 |
97 v
98 (various mounts and (various swap (various cryptsetup
99 fsck services...) devices...) devices...) (various low-level (various low-level
100 | | | services: udevd, API VFS mounts:
101 v v v tmpfiles, random mqueue, configfs,
102 local-fs.target swap.target cryptsetup.target seed, sysctl, ...) debugfs, ...)
103 | | | | |
104 \__________________|_________________ | ___________________|____________________/
105 \|/
106 v
107 sysinit.target
108 |
109 ____________________________________/|\________________________________________
110 / | | | \
111 | | | | |
112 v v | v v
113 (various (various | (various rescue.service
114 timers...) paths...) | sockets...) |
115 | | | | v
116 v v | v <emphasis>rescue.target</emphasis>
117 timers.target paths.target | sockets.target
118 | | | |
119 v \_________________ | ___________________/
120 \|/
121 v
122 basic.target
123 |
124 ____________________________________/| emergency.service
125 / | | |
126 | | | v
127 v v v <emphasis>emergency.target</emphasis>
128 display- (various system (various system
129 manager.service services services)
130 | required for |
131 | graphical UIs) v
132 | | <emphasis>multi-user.target</emphasis>
133 | | |
134 \_________________ | _________________/
135 \|/
136 v
137 <emphasis>graphical.target</emphasis></programlisting>
138
139 <para>Target units that are commonly used as boot targets are
140 <emphasis>emphasized</emphasis>. These units are good choices as
141 goal targets, for example by passing them to the
142 <varname>systemd.unit=</varname> kernel command line option (see
143 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>)
144 or by symlinking <filename>default.target</filename> to them.
145 </para>
146
147 <para><filename>timers.target</filename> is pulled-in by
148 <filename>basic.target</filename> asynchronously. This allows
149 timers units to depend on services which become only available
150 later in boot.</para>
151 </refsect1>
152
153 <refsect1>
154 <title>Bootup in the Initial RAM Disk (initrd)</title>
155 <para>The initial RAM disk implementation (initrd) can be set up
156 using systemd as well. In this case, boot up inside the initrd
157 follows the following structure.</para>
158
159 <para>The default target in the initrd is
160 <filename>initrd.target</filename>. The bootup process begins
161 identical to the system manager bootup (see above) until it
162 reaches <filename>basic.target</filename>. From there, systemd
163 approaches the special target <filename>initrd.target</filename>.
164
165 Before any file systems are mounted, it must be determined whether
166 the system will resume from hibernation or proceed with normal boot.
167 This is accomplished by <filename>systemd-hibernate-resume@.service</filename>
168 which must be finished before <filename>local-fs-pre.target</filename>,
169 so no filesystems can be mounted before the check is complete.
170
171 When the root device becomes available,
172 <filename>initd-root-device.target</filename> is reached.
173 If the root device can be mounted at
174 <filename>/sysroot</filename>, the
175 <filename>sysroot.mount</filename> unit becomes active and
176 <filename>initrd-root-fs.target</filename> is reached. The service
177 <filename>initrd-parse-etc.service</filename> scans
178 <filename>/sysroot/etc/fstab</filename> for a possible
179 <filename>/usr</filename> mount point and additional entries
180 marked with the <emphasis>x-initrd.mount</emphasis> option. All
181 entries found are mounted below <filename>/sysroot</filename>, and
182 <filename>initrd-fs.target</filename> is reached. The service
183 <filename>initrd-cleanup.service</filename> isolates to the
184 <filename>initrd-switch-root.target</filename>, where cleanup
185 services can run. As the very last step, the
186 <filename>initrd-switch-root.service</filename> is activated,
187 which will cause the system to switch its root to
188 <filename>/sysroot</filename>.
189 </para>
190
191 <programlisting> : (beginning identical to above)
192 :
193 v
194 basic.target
195 | emergency.service
196 ______________________/| |
197 / | v
198 | initrd-root-device.target <emphasis>emergency.target</emphasis>
199 | |
200 | v
201 | sysroot.mount
202 | |
203 | v
204 | initrd-root-fs.target
205 | |
206 | v
207 v initrd-parse-etc.service
208 (custom initrd |
209 services...) v
210 | (sysroot-usr.mount and
211 | various mounts marked
212 | with fstab option
213 | x-initrd.mount...)
214 | |
215 | v
216 | initrd-fs.target
217 \______________________ |
218 \|
219 v
220 initrd.target
221 |
222 v
223 initrd-cleanup.service
224 isolates to
225 initrd-switch-root.target
226 |
227 v
228 ______________________/|
229 / v
230 | initrd-udevadm-cleanup-db.service
231 v |
232 (custom initrd |
233 services...) |
234 \______________________ |
235 \|
236 v
237 initrd-switch-root.target
238 |
239 v
240 initrd-switch-root.service
241 |
242 v
243 Transition to Host OS</programlisting>
244 </refsect1>
245
246 <refsect1>
247 <title>System Manager Shutdown</title>
248
249 <para>System shutdown with systemd also consists of various target
250 units with some minimal ordering structure applied:</para>
251
252 <programlisting> (conflicts with (conflicts with
253 all system all file system
254 services) mounts, swaps,
255 | cryptsetup
256 | devices, ...)
257 | |
258 v v
259 shutdown.target umount.target
260 | |
261 \_______ ______/
262 \ /
263 v
264 (various low-level
265 services)
266 |
267 v
268 final.target
269 |
270 _____________________________________/ \_________________________________
271 / | | \
272 | | | |
273 v v v v
274 systemd-reboot.service systemd-poweroff.service systemd-halt.service systemd-kexec.service
275 | | | |
276 v v v v
277 <emphasis>reboot.target</emphasis> <emphasis>poweroff.target</emphasis> <emphasis>halt.target</emphasis> <emphasis>kexec.target</emphasis></programlisting>
278
279 <para>Commonly used system shutdown targets are <emphasis>emphasized</emphasis>.</para>
280
281 <para>Note that
282 <citerefentry><refentrytitle>systemd-halt.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
283 <filename>systemd-reboot.service</filename>, <filename>systemd-poweroff.service</filename> and
284 <filename>systemd-kexec.service</filename> will transition the system and server manager (PID 1) into the second
285 phase of system shutdown (implemented in the <filename>systemd-shutdown</filename> binary), which will unmount any
286 remaining file systems, kill any remaining processes and release any other remaining resources, in a simple and
287 robust fashion, without taking any service or unit concept into account anymore. At that point, regular
288 applications and resources are generally terminated and released already, the second phase hence operates only as
289 safety net for everything that couldn't be stopped or released for some reason during the primary, unit-based
290 shutdown phase described above.</para>
291 </refsect1>
292
293 <refsect1>
294 <title>See Also</title>
295 <para>
296 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
297 <citerefentry project='man-pages'><refentrytitle>boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
298 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
299 <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
300 <citerefentry><refentrytitle>systemd-halt.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
301 <citerefentry project='die-net'><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>
302 </para>
303 </refsect1>
304
305 </refentry>