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. If the root device can be mounted at /sysroot, the
116 sysroot.mount unit becomes active and initrd-root-fs.target is reached.
117 The service initrd-parse-etc.service scans /sysroot/etc/fstab for a
118 possible /usr mount point and additional entries marked with the
119 x-initrd.mount option. All entries found are mounted below /sysroot,
120 and initrd-fs.target is reached. The service initrd-cleanup.service
121 isolates to the initrd-switch-root.target, where cleanup services can
122 run. As the very last step, the initrd-switch-root.service is
123 activated, which will cause the system to switch its root to /sysroot.
124 : (beginning identical to above)
126 :
127 v
128 basic.target
129 | emergency.service
130 ______________________/| |
131 / | v
132 | sysroot.mount emergency.target
133 | |
134 | v
135 | initrd-root-fs.target
136 | |
137 | v
138 v initrd-parse-etc.service
139 (custom initrd |
140 services...) v
141 | (sysroot-usr.mount and
142 | various mounts marked
143 | with fstab option
144 | x-initrd.mount...)
145 | |
146 | v
147 | initrd-fs.target
148 \______________________ |
149 \|
150 v
151 initrd.target
152 |
153 v
154 initrd-cleanup.service
155 isolates to
156 initrd-switch-root.target
157 |
158 v
159 ______________________/|
160 / v
161 | initrd-udevadm-cleanup-db.service
162 v |
163 (custom initrd |
164 services...) |
165 \______________________ |
166 \|
167 v
168 initrd-switch-root.target
169 |
170 v
171 initrd-switch-root.service
172 |
173 v
174 Transition to Host OS
175
177 System shutdown with systemd also consists of various target units with
178 some minimal ordering structure applied:
179 (conflicts with (conflicts with
181 all system all file system
182 services) mounts, swaps,
183 | cryptsetup
184 | devices, ...)
185 | |
186 v v
187 shutdown.target umount.target
188 | |
189 \_______ ______/
190 \ /
191 v
192 (various low-level
193 services)
194 |
195 v
196 final.target
197 |
198 _____________________________________/ \_________________________________
199 / | | \
200 | | | |
201 v v v v
202 systemd-reboot.service systemd-poweroff.service systemd-halt.service systemd-kexec.service
203 | | | |
204 v v v v
205 reboot.target poweroff.target halt.target kexec.target
206 Commonly used system shutdown targets are emphasized.
208
210 systemd(1), boot(7), systemd.special(7), systemd.target(5), dracut(8)
211systemd 219 BOOTUP(7)