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 local-fs-pre.target
68 |
69 v
70 (various mounts and (various swap (various cryptsetup
71 fsck services...) devices...) devices...) (various low-level (various low-level
72 | | | services: udevd, API VFS mounts:
73 v v v tmpfiles, random mqueue, configfs,
74 local-fs.target swap.target cryptsetup.target seed, sysctl, ...) debugfs, ...)
75 | | | | |
76 \__________________|_________________ | ___________________|____________________/
77 \|/
78 v
79 sysinit.target
80 |
81 ____________________________________/|\________________________________________
82 / | | | \
83 | | | | |
84 v v | v v
85 (various (various | (various rescue.service
86 timers...) paths...) | sockets...) |
87 | | | | v
88 v v | v rescue.target
89 timers.target paths.target | sockets.target
90 | | | |
91 v \_________________ | ___________________/
92 \|/
93 v
94 basic.target
95 |
96 ____________________________________/| emergency.service
97 / | | |
98 | | | v
99 v v v emergency.target
100 display- (various system (various system
101 manager.service services services)
102 | required for |
103 | graphical UIs) v
104 | | multi-user.target
105 | | |
106 \_________________ | _________________/
107 \|/
108 v
109 graphical.target
110 Target units that are commonly used as boot targets are emphasized.
112 These units are good choices as goal targets, for example by passing
113 them to the systemd.unit= kernel command line option (see systemd(1))
114 or by symlinking default.target to them.
115 timers.target is pulled-in by basic.target asynchronously. This allows
117 timers units to depend on services which become only available later in
118 boot.
119
121 The initial RAM disk implementation (initrd) can be set up using
122 systemd as well. In this case, boot up inside the initrd follows the
123 following structure.
124 systemd detects that it is run within an initrd by checking for the
126 file /etc/initrd-release. The default target in the initrd is
127 initrd.target. The bootup process begins identical to the system
128 manager bootup (see above) until it reaches basic.target. From there,
129 systemd approaches the special target initrd.target. Before any file
130 systems are mounted, it must be determined whether the system will
131 resume from hibernation or proceed with normal boot. This is
132 accomplished by systemd-hibernate-resume@.service which must be
133 finished before local-fs-pre.target, so no filesystems can be mounted
134 before the check is complete. When the root device becomes available,
135 initd-root-device.target is reached. If the root device can be mounted
136 at /sysroot, the sysroot.mount unit becomes active and
137 initrd-root-fs.target is reached. The service initrd-parse-etc.service
138 scans /sysroot/etc/fstab for a possible /usr mount point and additional
139 entries marked with the x-initrd.mount option. All entries found are
140 mounted below /sysroot, and initrd-fs.target is reached. The service
141 initrd-cleanup.service isolates to the initrd-switch-root.target, where
142 cleanup services can run. As the very last step, the
143 initrd-switch-root.service is activated, which will cause the system to
144 switch its root to /sysroot.
145 : (beginning identical to above)
147 :
148 v
149 basic.target
150 | emergency.service
151 ______________________/| |
152 / | v
153 | initrd-root-device.target emergency.target
154 | |
155 | v
156 | sysroot.mount
157 | |
158 | v
159 | initrd-root-fs.target
160 | |
161 | v
162 v initrd-parse-etc.service
163 (custom initrd |
164 services...) v
165 | (sysroot-usr.mount and
166 | various mounts marked
167 | with fstab option
168 | x-initrd.mount...)
169 | |
170 | v
171 | initrd-fs.target
172 \______________________ |
173 \|
174 v
175 initrd.target
176 |
177 v
178 initrd-cleanup.service
179 isolates to
180 initrd-switch-root.target
181 |
182 v
183 ______________________/|
184 / v
185 | initrd-udevadm-cleanup-db.service
186 v |
187 (custom initrd |
188 services...) |
189 \______________________ |
190 \|
191 v
192 initrd-switch-root.target
193 |
194 v
195 initrd-switch-root.service
196 |
197 v
198 Transition to Host OS
199
201 System shutdown with systemd also consists of various target units with
202 some minimal ordering structure applied:
203 (conflicts with (conflicts with
205 all system all file system
206 services) mounts, swaps,
207 | cryptsetup
208 | devices, ...)
209 | |
210 v v
211 shutdown.target umount.target
212 | |
213 \_______ ______/
214 \ /
215 v
216 (various low-level
217 services)
218 |
219 v
220 final.target
221 |
222 _____________________________________/ \_________________________________
223 / | | \
224 | | | |
225 v v v v
226 systemd-reboot.service systemd-poweroff.service systemd-halt.service systemd-kexec.service
227 | | | |
228 v v v v
229 reboot.target poweroff.target halt.target kexec.target
230 Commonly used system shutdown targets are emphasized.
232 Note that systemd-halt.service(8), systemd-reboot.service,
234 systemd-poweroff.service and systemd-kexec.service will transition the
235 system and server manager (PID 1) into the second phase of system
236 shutdown (implemented in the systemd-shutdown binary), which will
237 unmount any remaining file systems, kill any remaining processes and
238 release any other remaining resources, in a simple and robust fashion,
239 without taking any service or unit concept into account anymore. At
240 that point, regular applications and resources are generally terminated
241 and released already, the second phase hence operates only as safety
242 net for everything that couldn't be stopped or released for some reason
243 during the primary, unit-based shutdown phase described above.
244
246 systemd(1), boot(7), systemd.special(7), systemd.target(5), systemd-
247 halt.service(8), dracut(8)
248
250 1. GRUB
251 https://www.gnu.org/software/grub/
252systemd 241 BOOTUP(7)