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 usually implemented as an initramfs — a compressed archive
20       which is extracted when the kernel boots up into a lightweight
21       in-memory file system based on tmpfs, but in the past normal file
22       systems using an in-memory block device (ramdisk) were used, and the
23       name "initrd" is still used to describe both concepts. It's the boot
24       loader or the firmware that loads both the kernel and initrd/initramfs
25       images into memory, but the kernel which interprets it as a file
26       system.  systemd(1) may be used to manage services in the initrd,
27       similarly to the real system.
28
29       After the root file system is found and mounted, the initrd hands over
30       control to the host's system manager (such as systemd(1)) stored in the
31       root file system, which is then responsible for probing all remaining
32       hardware, mounting all necessary file systems and spawning all
33       configured services.
34
35       On shutdown, the system manager stops all services, unmounts all file
36       systems (detaching the storage technologies backing them), and then
37       (optionally) jumps back into the initrd code which unmounts/detaches
38       the root file system and the storage it resides on. As a last step, the
39       system is powered down.
40
41       Additional information about the system boot process may be found in
42       boot(7).
43

SYSTEM MANAGER BOOTUP

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

USER MANAGER STARTUP

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

BOOTUP IN THE INITIAL RAM DISK (INITRD)

166       The initial RAM disk implementation (initrd) can be set up using
167       systemd as well. In this case, boot up inside the initrd follows the
168       following structure.
169
170       systemd detects that it is run within an initrd by checking for the
171       file /etc/initrd-release. The default target in the initrd is
172       initrd.target. The bootup process begins identical to the system
173       manager bootup (see above) until it reaches basic.target. From there,
174       systemd approaches the special target initrd.target. Before any file
175       systems are mounted, it must be determined whether the system will
176       resume from hibernation or proceed with normal boot. This is
177       accomplished by systemd-hibernate-resume@.service which must be
178       finished before local-fs-pre.target, so no filesystems can be mounted
179       before the check is complete. When the root device becomes available,
180       initrd-root-device.target is reached. If the root device can be mounted
181       at /sysroot, the sysroot.mount unit becomes active and
182       initrd-root-fs.target is reached. The service initrd-parse-etc.service
183       scans /sysroot/etc/fstab for a possible /usr/ mount point and
184       additional entries marked with the x-initrd.mount option. All entries
185       found are mounted below /sysroot, and initrd-fs.target is reached. The
186       service initrd-cleanup.service isolates to the
187       initrd-switch-root.target, where cleanup services can run. As the very
188       last step, the initrd-switch-root.service is activated, which will
189       cause the system to switch its root to /sysroot.
190
191                                                          : (beginning identical to above)
192                                                          :
193                                                          v
194                                                    basic.target
195                                                          |                                 emergency.service
196                                   ______________________/|                                         |
197                                  /                       |                                         v
198                                  |            initrd-root-device.target                    emergency.target
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
244

SYSTEM MANAGER SHUTDOWN

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

SEE ALSO

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

NOTES

296        1. GRUB
297           https://www.gnu.org/software/grub/
298
299
300
301systemd 251                                                          BOOTUP(7)
Impressum