1BOOTUP(7) bootup BOOTUP(7)
2
6 bootup - System bootup process
7
9 A number of different components are involved in the system boot.
10 Immediately after power-up, the system BIOS will do minimal hardware
11 initialization, and hand control over to a boot loader stored on a
12 persistent storage device. This boot loader will then invoke an OS
13 kernel from disk (or the network). In the Linux case, this kernel
14 (optionally) extracts and executes an initial RAM disk image (initrd),
15 such as generated by dracut(8), which looks for the root file system
16 (possibly using systemd(1) for this). After the root file system is
17 found and mounted, the initrd hands over control to the host's system
18 manager (such as systemd(1)) stored on the OS image, which is then
19 responsible for probing all remaining hardware, mounting all necessary
20 file systems and spawning all configured services.
21 On shutdown, the system manager stops all services, unmounts all file
23 systems (detaching the storage technologies backing them), and then
24 (optionally) jumps back into the initrd code which unmounts/detaches
25 the root file system and the storage it resides on. As a last step, the
26 system is powered down.
27 Additional information about the system boot process may be found in
29 boot(7).
30
32 At boot, the system manager on the OS image is responsible for
33 initializing the required file systems, services and drivers that are
34 necessary for operation of the system. On systemd(1) systems, this
35 process is split up in various discrete steps which are exposed as
36 target units. (See systemd.target(5) for detailed information about
37 target units.) The boot-up process is highly parallelized so that the
38 order in which specific target units are reached is not deterministic,
39 but still adheres to a limited amount of ordering structure.
40 When systemd starts up the system, it will activate all units that are
42 dependencies of default.target (as well as recursively all dependencies
43 of these dependencies). Usually, default.target is simply an alias of
44 graphical.target or multi-user.target, depending on whether the system
45 is configured for a graphical UI or only for a text console. To enforce
46 minimal ordering between the units pulled in, a number of well-known
47 target units are available, as listed on systemd.special(7).
48 The following chart is a structural overview of these well-known units
50 and their position in the boot-up logic. The arrows describe which
51 units are pulled in and ordered before which other units. Units near
52 the top are started before units nearer to the bottom of the chart.
53 local-fs-pre.target
55 |
56 v
57 (various mounts and (various swap (various cryptsetup
58 fsck services...) devices...) devices...) (various low-level (various low-level
59 | | | services: udevd, API VFS mounts:
60 v v v tmpfiles, random mqueue, configfs,
61 local-fs.target swap.target cryptsetup.target seed, sysctl, ...) debugfs, ...)
62 | | | | |
63 \__________________|_________________ | ___________________|____________________/
64 \|/
65 v
66 sysinit.target
67 |
68 ____________________________________/|\________________________________________
69 / | | | \
70 | | | | |
71 v v | v v
72 (various (various | (various rescue.service
73 timers...) paths...) | sockets...) |
74 | | | | v
75 v v | v rescue.target
76 timers.target paths.target | sockets.target
77 | | | |
78 v \_________________ | ___________________/
79 \|/
80 v
81 basic.target
82 |
83 ____________________________________/| emergency.service
84 / | | |
85 | | | v
86 v v v emergency.target
87 display- (various system (various system
88 manager.service services services)
89 | required for |
90 | graphical UIs) v
91 | | multi-user.target
92 | | |
93 \_________________ | _________________/
94 \|/
95 v
96 graphical.target
97 Target units that are commonly used as boot targets are emphasized.
99 These units are good choices as goal targets, for example by passing
100 them to the systemd.unit= kernel command line option (see systemd(1))
101 or by symlinking default.target to them.
102 timers.target is pulled-in by basic.target asynchronously. This allows
104 timers units to depend on services which become only available later in
105 boot.
106
108 The initial RAM disk implementation (initrd) can be set up using
109 systemd as well. In this case, boot up inside the initrd follows the
110 following structure.
111 The default target in the initrd is initrd.target. The bootup process
113 begins identical to the system manager bootup (see above) until it
114 reaches basic.target. From there, systemd approaches the special target
115 initrd.target. Before any file systems are mounted, it must be
116 determined whether the system will resume from hibernation or proceed
117 with normal boot. This is accomplished by
118 systemd-hibernate-resume@.service which must be finished before
119 local-fs-pre.target, so no filesystems can be mounted before the check
120 is complete. When the root device becomes available,
121 initd-root-device.target is reached. If the root device can be mounted
122 at /sysroot, the sysroot.mount unit becomes active and
123 initrd-root-fs.target is reached. The service initrd-parse-etc.service
124 scans /sysroot/etc/fstab for a possible /usr mount point and additional
125 entries marked with the x-initrd.mount option. All entries found are
126 mounted below /sysroot, and initrd-fs.target is reached. The service
127 initrd-cleanup.service isolates to the initrd-switch-root.target, where
128 cleanup services can run. As the very last step, the
129 initrd-switch-root.service is activated, which will cause the system to
130 switch its root to /sysroot.
131 : (beginning identical to above)
133 :
134 v
135 basic.target
136 | emergency.service
137 ______________________/| |
138 / | v
139 | initrd-root-device.target emergency.target
140 | |
141 | v
142 | sysroot.mount
143 | |
144 | v
145 | initrd-root-fs.target
146 | |
147 | v
148 v initrd-parse-etc.service
149 (custom initrd |
150 services...) v
151 | (sysroot-usr.mount and
152 | various mounts marked
153 | with fstab option
154 | x-initrd.mount...)
155 | |
156 | v
157 | initrd-fs.target
158 \______________________ |
159 \|
160 v
161 initrd.target
162 |
163 v
164 initrd-cleanup.service
165 isolates to
166 initrd-switch-root.target
167 |
168 v
169 ______________________/|
170 / v
171 | initrd-udevadm-cleanup-db.service
172 v |
173 (custom initrd |
174 services...) |
175 \______________________ |
176 \|
177 v
178 initrd-switch-root.target
179 |
180 v
181 initrd-switch-root.service
182 |
183 v
184 Transition to Host OS
185
187 System shutdown with systemd also consists of various target units with
188 some minimal ordering structure applied:
189 (conflicts with (conflicts with
191 all system all file system
192 services) mounts, swaps,
193 | cryptsetup
194 | devices, ...)
195 | |
196 v v
197 shutdown.target umount.target
198 | |
199 \_______ ______/
200 \ /
201 v
202 (various low-level
203 services)
204 |
205 v
206 final.target
207 |
208 _____________________________________/ \_________________________________
209 / | | \
210 | | | |
211 v v v v
212 systemd-reboot.service systemd-poweroff.service systemd-halt.service systemd-kexec.service
213 | | | |
214 v v v v
215 reboot.target poweroff.target halt.target kexec.target
216 Commonly used system shutdown targets are emphasized.
218 Note that systemd-halt.service(8), systemd-reboot.service,
220 systemd-poweroff.service and systemd-kexec.service will transition the
221 system and server manager (PID 1) into the second phase of system
222 shutdown (implemented in the systemd-shutdown binary), which will
223 unmount any remaining file systems, kill any remaining processes and
224 release any other remaining resources, in a simple and robust fashion,
225 without taking any service or unit concept into account anymore. At
226 that point, regular applications and resources are generally terminated
227 and released already, the second phase hence operates only as safety
228 net for everything that couldn't be stopped or released for some reason
229 during the primary, unit-based shutdown phase described above.
230
232 systemd(1), boot(7), systemd.special(7), systemd.target(5), systemd-
233 halt.service(8), dracut(8)
234systemd 239 BOOTUP(7)