1BOOTUP(7) bootup BOOTUP(7)
2
6 bootup - System bootup process
7
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 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 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 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 Additional information about the system boot process may be found in
41 boot(7).
42
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 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 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 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 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 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
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 (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
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 finished
173 before local-fs-pre.target, so no filesystems can be mounted before the
174 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 : (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
241 System shutdown with systemd also consists of various target units with
242 some minimal ordering structure applied:
243 (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 Commonly used system shutdown targets are emphasized.
280 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
294 systemd(1), boot(7), systemd.special(7), systemd.target(5), systemd-
295 halt.service(8), dracut(8)
296
298 1. GRUB
299 https://www.gnu.org/software/grub/
300systemd 254 BOOTUP(7)