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 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 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 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 Additional information about the system boot process may be found in
42 boot(7).
43
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 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 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 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...) | | remote-fs.target
82 | | tmpfiles, random | | | /
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 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 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
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 (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
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 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 : (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
246 System shutdown with systemd also consists of various target units with
247 some minimal ordering structure applied:
248 (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 Commonly used system shutdown targets are emphasized.
278 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
292 systemd(1), boot(7), systemd.special(7), systemd.target(5), systemd-
293 halt.service(8), dracut(8)
294
296 1. GRUB
297 https://www.gnu.org/software/grub/
298systemd 248 BOOTUP(7)