]>
Commit | Line | Data |
---|---|---|
013d8a39 | 1 | <?xml version='1.0'?> <!--*-nxml-*--> |
3a54a157 | 2 | <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" |
eea10b26 | 3 | "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"> |
db9ecf05 | 4 | <!-- SPDX-License-Identifier: LGPL-2.1-or-later --> |
013d8a39 LP |
5 | |
6 | <refentry id="bootup"> | |
7 | ||
798d3a52 ZJS |
8 | <refentryinfo> |
9 | <title>bootup</title> | |
10 | <productname>systemd</productname> | |
798d3a52 ZJS |
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 | ||
543e6bd4 ZJS |
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 | ||
98118c44 DDM |
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 | |
39 | system. | |
b66a6e1a ZJS |
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> | |
543e6bd4 ZJS |
42 | |
43 | <para>After the root file system is found and mounted, the initrd hands over control to the host's system | |
44 | manager (such as | |
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> | |
798d3a52 ZJS |
48 | |
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> | |
54 | ||
55 | <para>Additional information about the system boot process may be | |
56 | found in | |
57 | <citerefentry project='man-pages'><refentrytitle>boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para> | |
58 | </refsect1> | |
59 | ||
60 | <refsect1> | |
61 | <title>System Manager Bootup</title> | |
62 | ||
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> | |
74 | ||
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> | |
85 | ||
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> | |
013d8a39 | 91 | |
24c44fdf ZJS |
92 | <!-- note: do not use unicode ellipsis here, because docbook will replace that |
93 | with three dots anyway, messing up alignment --> | |
08b04ec7 | 94 | <programlisting> cryptsetup-pre.target veritysetup-pre.target |
f71502c4 ZJS |
95 | | |
96 | (various low-level v | |
08b04ec7 | 97 | API VFS mounts: (various cryptsetup/veritysetup devices...) |
f71502c4 ZJS |
98 | mqueue, configfs, | | |
99 | debugfs, ...) v | | |
100 | | cryptsetup.target | | |
101 | | (various swap | | remote-fs-pre.target | |
102 | | devices...) | | | | | |
103 | | | | | | v | |
104 | | v local-fs-pre.target | | | (network file systems) | |
105 | | swap.target | | v v | | |
106 | | | v | remote-cryptsetup.target | | |
08b04ec7 | 107 | | | (various low-level (various mounts and | remote-veritysetup.target | |
bd330fb0 ZJS |
108 | | | services: udevd, fsck services...) | | | |
109 | | | tmpfiles, random | | | remote-fs.target | |
110 | | | seed, sysctl, ...) v | | | | |
111 | | | | local-fs.target | | _____________/ | |
112 | | | | | | |/ | |
113 | \____|______|_______________ ______|___________/ | | |
114 | \ / | | |
115 | v | | |
116 | sysinit.target | | |
117 | | | | |
118 | ______________________/|\_____________________ | | |
119 | / | | | \ | | |
120 | | | | | | | | |
121 | v v | v | | | |
122 | (various (various | (various | | | |
f71502c4 ZJS |
123 | timers...) paths...) | sockets...) | | |
124 | | | | | | | | |
125 | v v | v | | | |
126 | timers.target paths.target | sockets.target | | | |
127 | | | | | v | | |
128 | v \_______ | _____/ rescue.service | | |
129 | \|/ | | | |
130 | v v | | |
131 | basic.target <emphasis>rescue.target</emphasis> | | |
132 | | | | |
133 | ________v____________________ | | |
134 | / | \ | | |
135 | | | | | | |
136 | v v v | | |
137 | display- (various system (various system | | |
138 | manager.service services services) | | |
139 | | required for | | | |
140 | | graphical UIs) v v | |
141 | | | <emphasis>multi-user.target</emphasis> | |
142 | emergency.service | | | | |
143 | | \_____________ | _____________/ | |
144 | v \|/ | |
145 | <emphasis>emergency.target</emphasis> v | |
146 | <emphasis>graphical.target</emphasis></programlisting> | |
798d3a52 ZJS |
147 | |
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>) | |
72b7d998 ZJS |
153 | or by symlinking <filename>default.target</filename> to them. |
154 | </para> | |
798d3a52 ZJS |
155 | |
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> | |
160 | </refsect1> | |
161 | ||
277519db ZJS |
162 | <refsect1> |
163 | <title>User manager startup</title> | |
164 | ||
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 | |
86b52a39 | 172 | graphical session. A number of targets (shown on the right side) are started when specific hardware is |
277519db ZJS |
173 | available to the user.</para> |
174 | ||
175 | <programlisting> | |
6ce4de29 ZJS |
176 | (various (various (various |
177 | timers...) paths...) sockets...) (sound devices) | |
178 | | | | | | |
179 | v v v v | |
180 | timers.target paths.target sockets.target sound.target | |
181 | | | | | |
182 | \______________ _|_________________/ (bluetooth devices) | |
183 | \ / | | |
184 | V v | |
185 | basic.target bluetooth.target | |
186 | | | |
187 | __________/ \_______ (smartcard devices) | |
188 | / \ | | |
189 | | | v | |
190 | | v smartcard.target | |
191 | v graphical-session-pre.target | |
192 | (various user services) | (printers) | |
193 | | v | | |
194 | | (services for the graphical session) v | |
195 | | | printer.target | |
196 | v v | |
197 | <emphasis>default.target</emphasis> graphical-session.target</programlisting> | |
277519db | 198 | |
6ce4de29 | 199 | </refsect1> |
277519db | 200 | |
798d3a52 | 201 | <refsect1> |
55c041b4 LP |
202 | <title>Bootup in the initrd</title> |
203 | ||
1485925d ZJS |
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>. | |
209 | ||
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 | |
760e99bb | 212 | <filename>systemd-hibernate-resume.service</filename> which must be finished before |
1485925d | 213 | <filename>local-fs-pre.target</filename>, so no filesystems can be mounted before the check is complete. |
6d9e45e9 | 214 | |
7163e1ca | 215 | When the root device becomes available, |
57680ddd | 216 | <filename>initrd-root-device.target</filename> is reached. |
798d3a52 ZJS |
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 | |
3b121157 | 223 | <filename>/usr/</filename> mount point and additional entries |
798d3a52 ZJS |
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>. | |
233 | </para> | |
234 | ||
6ce4de29 ZJS |
235 | <programlisting> : (beginning identical to above) |
236 | : | |
237 | v | |
238 | basic.target | |
239 | | emergency.service | |
240 | ______________________/| | | |
241 | / | v | |
242 | | initrd-root-device.target <emphasis>emergency.target</emphasis> | |
243 | | | | |
244 | | v | |
245 | | sysroot.mount | |
246 | | | | |
247 | | v | |
248 | | initrd-root-fs.target | |
249 | | | | |
250 | | v | |
251 | v initrd-parse-etc.service | |
252 | (custom initrd | | |
253 | services...) v | |
254 | | (sysroot-usr.mount and | |
255 | | various mounts marked | |
256 | | with fstab option | |
257 | | x-initrd.mount...) | |
258 | | | | |
259 | | v | |
260 | | initrd-fs.target | |
261 | \______________________ | | |
262 | \| | |
263 | v | |
264 | initrd.target | |
265 | | | |
266 | v | |
267 | initrd-cleanup.service | |
268 | isolates to | |
269 | initrd-switch-root.target | |
270 | | | |
271 | v | |
272 | ______________________/| | |
273 | / v | |
274 | | initrd-udevadm-cleanup-db.service | |
275 | v | | |
276 | (custom initrd | | |
277 | services...) | | |
278 | \______________________ | | |
279 | \| | |
280 | v | |
281 | initrd-switch-root.target | |
282 | | | |
283 | v | |
284 | initrd-switch-root.service | |
285 | | | |
286 | v | |
287 | Transition to Host OS</programlisting> | |
798d3a52 ZJS |
288 | </refsect1> |
289 | ||
798d3a52 ZJS |
290 | <refsect1> |
291 | <title>System Manager Shutdown</title> | |
292 | ||
293 | <para>System shutdown with systemd also consists of various target | |
294 | units with some minimal ordering structure applied:</para> | |
295 | ||
6ce4de29 ZJS |
296 | <programlisting> (conflicts with (conflicts with |
297 | all system all file system | |
298 | services) mounts, swaps, | |
299 | | cryptsetup/ | |
300 | | veritysetup | |
301 | | devices, ...) | |
302 | | | | |
303 | v v | |
304 | shutdown.target umount.target | |
305 | | | | |
306 | \_______ ______/ | |
307 | \ / | |
308 | v | |
309 | (various low-level | |
310 | services) | |
311 | | | |
312 | v | |
313 | final.target | |
314 | | | |
315 | ___________________________/ \_________________ | |
316 | / | | \ | |
317 | | | | | | |
318 | v | | | | |
319 | systemd-reboot.service | | | | |
320 | | v | | | |
321 | | systemd-poweroff.service | | | |
322 | v | v | | |
323 | <emphasis>reboot.target</emphasis> | systemd-halt.service | | |
324 | v | v | |
325 | <emphasis>poweroff.target</emphasis> | systemd-kexec.service | |
326 | v | | |
327 | <emphasis>halt.target</emphasis> | | |
328 | v | |
329 | <emphasis>kexec.target</emphasis></programlisting> | |
798d3a52 | 330 | |
e799056e LP |
331 | <para>Commonly used system shutdown targets are <emphasis>emphasized</emphasis>.</para> |
332 | ||
333 | <para>Note that | |
39e4f5bc | 334 | <citerefentry><refentrytitle>systemd-halt.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, |
e799056e LP |
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> | |
798d3a52 ZJS |
343 | </refsect1> |
344 | ||
345 | <refsect1> | |
346 | <title>See Also</title> | |
13a69c12 DT |
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> | |
13a69c12 | 353 | </simplelist></para> |
798d3a52 | 354 | </refsect1> |
013d8a39 LP |
355 | |
356 | </refentry> |