1BOOTUP(7)                           bootup                           BOOTUP(7)
2
3
4

NAME

6       bootup - System bootup process
7

DESCRIPTION

9       A number of different components are involved in the boot of a Linux
10       system. Immediately after power-up, the system firmware will do minimal
11       hardware initialization, and hand control over to a boot loader (e.g.
12       systemd-boot(7) or GRUB[1]) stored on a persistent storage device. This
13       boot loader will then invoke an OS kernel from disk (or the network).
14       On systems using EFI or other types of firmware, this firmware may also
15       load the kernel directly.
16
17       The kernel (optionally) mounts an in-memory file system, often
18       generated by dracut(8), which looks for the root file system. Nowadays
19       this is implemented as an "initramfs" — a compressed CPIO archive that
20       the kernel extracts into a tmpfs. In the past normal file systems using
21       an in-memory block device (ramdisk) were used, and the name "initrd" is
22       still used to describe both concepts. It's the boot loader or the
23       firmware that loads both the kernel and initrd/initramfs images into
24       memory, but the kernel which interprets it as a file system.
25       systemd(1) may be used to manage services in the initrd, similarly to
26       the real system.
27
28       After the root file system is found and mounted, the initrd hands over
29       control to the host's system manager (such as systemd(1)) stored in the
30       root file system, which is then responsible for probing all remaining
31       hardware, mounting all necessary file systems and spawning all
32       configured services.
33
34       On shutdown, the system manager stops all services, unmounts all file
35       systems (detaching the storage technologies backing them), and then
36       (optionally) jumps back into the initrd code which unmounts/detaches
37       the root file system and the storage it resides on. As a last step, the
38       system is powered down.
39
40       Additional information about the system boot process may be found in
41       boot(7).
42

SYSTEM MANAGER BOOTUP

44       At boot, the system manager on the OS image is responsible for
45       initializing the required file systems, services and drivers that are
46       necessary for operation of the system. On systemd(1) systems, this
47       process is split up in various discrete steps which are exposed as
48       target units. (See systemd.target(5) for detailed information about
49       target units.) The boot-up process is highly parallelized so that the
50       order in which specific target units are reached is not deterministic,
51       but still adheres to a limited amount of ordering structure.
52
53       When systemd starts up the system, it will activate all units that are
54       dependencies of default.target (as well as recursively all dependencies
55       of these dependencies). Usually, default.target is simply an alias of
56       graphical.target or multi-user.target, depending on whether the system
57       is configured for a graphical UI or only for a text console. To enforce
58       minimal ordering between the units pulled in, a number of well-known
59       target units are available, as listed on systemd.special(7).
60
61       The following chart is a structural overview of these well-known units
62       and their position in the boot-up logic. The arrows describe which
63       units are pulled in and ordered before which other units. Units near
64       the top are started before units nearer to the bottom of the chart.
65
66                                        cryptsetup-pre.target veritysetup-pre.target
67                                                             |
68           (various low-level                                v
69            API VFS mounts:             (various cryptsetup/veritysetup devices...)
70            mqueue, configfs,                                |    |
71            debugfs, ...)                                    v    |
72            |                                  cryptsetup.target  |
73            |  (various swap                                 |    |    remote-fs-pre.target
74            |   devices...)                                  |    |     |        |
75            |    |                                           |    |     |        v
76            |    v                       local-fs-pre.target |    |     |  (network file systems)
77            |  swap.target                       |           |    v     v                 |
78            |    |                               v           |  remote-cryptsetup.target  |
79            |    |  (various low-level  (various mounts and  |  remote-veritysetup.target |
80            |    |   services: udevd,    fsck services...)   |             |              |
81            |    |   tmpfiles, random            |           |             |    remote-fs.target
82            |    |   seed, sysctl, ...)          v           |             |              |
83            |    |      |                 local-fs.target    |             | _____________/
84            |    |      |                        |           |             |/
85            \____|______|_______________   ______|___________/             |
86                                        \ /                                |
87                                         v                                 |
88                                  sysinit.target                           |
89                                         |                                 |
90                  ______________________/|\_____________________           |
91                 /              |        |      |               \          |
92                 |              |        |      |               |          |
93                 v              v        |      v               |          |
94            (various       (various      |  (various            |          |
95             timers...)      paths...)   |   sockets...)        |          |
96                 |              |        |      |               |          |
97                 v              v        |      v               |          |
98           timers.target  paths.target   |  sockets.target      |          |
99                 |              |        |      |               v          |
100                 v              \_______ | _____/         rescue.service   |
101                                        \|/                     |          |
102                                         v                      v          |
103                                     basic.target         rescue.target    |
104                                         |                                 |
105                                 ________v____________________             |
106                                /              |              \            |
107                                |              |              |            |
108                                v              v              v            |
109                            display-    (various system   (various system  |
110                        manager.service     services        services)      |
111                                |         required for        |            |
112                                |        graphical UIs)       v            v
113                                |              |            multi-user.target
114           emergency.service    |              |              |
115                   |            \_____________ | _____________/
116                   v                          \|/
117           emergency.target                    v
118                                         graphical.target
119
120       Target units that are commonly used as boot targets are emphasized.
121       These units are good choices as goal targets, for example by passing
122       them to the systemd.unit= kernel command line option (see systemd(1))
123       or by symlinking default.target to them.
124
125       timers.target is pulled-in by basic.target asynchronously. This allows
126       timers units to depend on services which become only available later in
127       boot.
128

USER MANAGER STARTUP

130       The system manager starts the user@uid.service unit for each user,
131       which launches a separate unprivileged instance of systemd for each
132       user — the user manager. Similarly to the system manager, the user
133       manager starts units which are pulled in by default.target. The
134       following chart is a structural overview of the well-known user units.
135       For non-graphical sessions, default.target is used. Whenever the user
136       logs into a graphical session, the login manager will start the
137       graphical-session.target target that is used to pull in units required
138       for the graphical session. A number of targets (shown on the right
139       side) are started when specific hardware is available to the user.
140
141              (various           (various         (various
142               timers...)         paths...)        sockets...)    (sound devices)
143                   |                  |                 |               |
144                   v                  v                 v               v
145             timers.target      paths.target     sockets.target    sound.target
146                   |                  |                 |
147                   \______________   _|_________________/         (bluetooth devices)
148                                  \ /                                   |
149                                   V                                    v
150                             basic.target                          bluetooth.target
151                                   |
152                        __________/ \_______                      (smartcard devices)
153                       /                    \                           |
154                       |                    |                           v
155                       |                    v                      smartcard.target
156                       v            graphical-session-pre.target
157           (various user services)          |                       (printers)
158                       |                    v                           |
159                       |       (services for the graphical session)     v
160                       |                    |                       printer.target
161                       v                    v
162                default.target      graphical-session.target
163

BOOTUP IN THE INITRD

165       Systemd can be used in the initrd as well. It detects the initrd
166       environment by checking for the /etc/initrd-release file. The default
167       target in the initrd is initrd.target. The bootup process is identical
168       to the system manager bootup until the target basic.target. After that,
169       systemd executes the special target initrd.target. Before any file
170       systems are mounted, the manager will determine whether the system
171       shall resume from hibernation or proceed with normal boot. This is
172       accomplished by systemd-hibernate-resume@.service which must be
173       finished before local-fs-pre.target, so no filesystems can be mounted
174       before the check is complete. When the root device becomes available,
175       initrd-root-device.target is reached. If the root device can be mounted
176       at /sysroot, the sysroot.mount unit becomes active and
177       initrd-root-fs.target is reached. The service initrd-parse-etc.service
178       scans /sysroot/etc/fstab for a possible /usr/ mount point and
179       additional entries marked with the x-initrd.mount option. All entries
180       found are mounted below /sysroot, and initrd-fs.target is reached. The
181       service initrd-cleanup.service isolates to the
182       initrd-switch-root.target, where cleanup services can run. As the very
183       last step, the initrd-switch-root.service is activated, which will
184       cause the system to switch its root to /sysroot.
185
186                                          : (beginning identical to above)
187                                          :
188                                          v
189                                    basic.target
190                                          |                       emergency.service
191                   ______________________/|                               |
192                  /                       |                               v
193                  |            initrd-root-device.target          emergency.target
194                  |                       |
195                  |                       v
196                  |                  sysroot.mount
197                  |                       |
198                  |                       v
199                  |             initrd-root-fs.target
200                  |                       |
201                  |                       v
202                  v            initrd-parse-etc.service
203           (custom initrd                 |
204            services...)                  v
205                  |            (sysroot-usr.mount and
206                  |             various mounts marked
207                  |               with fstab option
208                  |              x-initrd.mount...)
209                  |                       |
210                  |                       v
211                  |                initrd-fs.target
212                  \______________________ |
213                                         \|
214                                          v
215                                     initrd.target
216                                          |
217                                          v
218                                initrd-cleanup.service
219                                     isolates to
220                               initrd-switch-root.target
221                                          |
222                                          v
223                   ______________________/|
224                  /                       v
225                  |        initrd-udevadm-cleanup-db.service
226                  v                       |
227           (custom initrd                 |
228            services...)                  |
229                  \______________________ |
230                                         \|
231                                          v
232                              initrd-switch-root.target
233                                          |
234                                          v
235                              initrd-switch-root.service
236                                          |
237                                          v
238                                Transition to Host OS
239

SYSTEM MANAGER SHUTDOWN

241       System shutdown with systemd also consists of various target units with
242       some minimal ordering structure applied:
243
244                                  (conflicts with  (conflicts with
245                                     all system     all file system
246                                      services)     mounts, swaps,
247                                          |           cryptsetup/
248                                          |           veritysetup
249                                          |          devices, ...)
250                                          |                |
251                                          v                v
252                                   shutdown.target    umount.target
253                                          |                |
254                                          \_______   ______/
255                                                  \ /
256                                                   v
257                                          (various low-level
258                                               services)
259                                                   |
260                                                   v
261                                             final.target
262                                                   |
263                       ___________________________/ \_________________
264                      /               |               |               \
265                      |               |               |               |
266                      v               |               |               |
267           systemd-reboot.service     |               |               |
268                      |               v               |               |
269                      |    systemd-poweroff.service   |               |
270                      v               |               v               |
271                reboot.target         |      systemd-halt.service     |
272                                      v               |               v
273                              poweroff.target         |    systemd-kexec.service
274                                                      v               |
275                                                 halt.target          |
276                                                                      v
277                                                                kexec.target
278
279       Commonly used system shutdown targets are emphasized.
280
281       Note that systemd-halt.service(8), systemd-reboot.service,
282       systemd-poweroff.service and systemd-kexec.service will transition the
283       system and server manager (PID 1) into the second phase of system
284       shutdown (implemented in the systemd-shutdown binary), which will
285       unmount any remaining file systems, kill any remaining processes and
286       release any other remaining resources, in a simple and robust fashion,
287       without taking any service or unit concept into account anymore. At
288       that point, regular applications and resources are generally terminated
289       and released already, the second phase hence operates only as safety
290       net for everything that couldn't be stopped or released for some reason
291       during the primary, unit-based shutdown phase described above.
292

SEE ALSO

294       systemd(1), boot(7), systemd.special(7), systemd.target(5), systemd-
295       halt.service(8), dracut(8)
296

NOTES

298        1. GRUB
299           https://www.gnu.org/software/grub/
300
301
302
303systemd 253                                                          BOOTUP(7)
Impressum