mirror of
https://git.proxmox.com/git/systemd
synced 2025-06-05 05:39:28 +00:00
257 lines
13 KiB
Groff
257 lines
13 KiB
Groff
'\" t
|
|
.TH "BOOTUP" "7" "" "systemd 219" "bootup"
|
|
.\" -----------------------------------------------------------------
|
|
.\" * Define some portability stuff
|
|
.\" -----------------------------------------------------------------
|
|
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
.\" http://bugs.debian.org/507673
|
|
.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
|
|
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
.ie \n(.g .ds Aq \(aq
|
|
.el .ds Aq '
|
|
.\" -----------------------------------------------------------------
|
|
.\" * set default formatting
|
|
.\" -----------------------------------------------------------------
|
|
.\" disable hyphenation
|
|
.nh
|
|
.\" disable justification (adjust text to left margin only)
|
|
.ad l
|
|
.\" -----------------------------------------------------------------
|
|
.\" * MAIN CONTENT STARTS HERE *
|
|
.\" -----------------------------------------------------------------
|
|
.SH "NAME"
|
|
bootup \- System bootup process
|
|
.SH "DESCRIPTION"
|
|
.PP
|
|
A number of different components are involved in the system boot\&. Immediately after power\-up, the system BIOS will do minimal hardware initialization, and hand control over to a boot loader stored on a persistent storage device\&. This boot loader will then invoke an OS kernel from disk (or the network)\&. In the Linux case, this kernel (optionally) extracts and executes an initial RAM disk image (initrd), such as generated by
|
|
\fBdracut\fR(8), which looks for the root file system (possibly using
|
|
\fBsystemd\fR(1)
|
|
for this)\&. After the root file system is found and mounted, the initrd hands over control to the host\*(Aqs system manager (such as
|
|
\fBsystemd\fR(1)) stored on the OS image, which is then responsible for probing all remaining hardware, mounting all necessary file systems and spawning all configured services\&.
|
|
.PP
|
|
On shutdown, the system manager stops all services, unmounts all file systems (detaching the storage technologies backing them), and then (optionally) jumps back into the initrd code which unmounts/detaches the root file system and the storage it resides on\&. As a last step, the system is powered down\&.
|
|
.PP
|
|
Additional information about the system boot process may be found in
|
|
\fBboot\fR(7)\&.
|
|
.SH "SYSTEM MANAGER BOOTUP"
|
|
.PP
|
|
At boot, the system manager on the OS image is responsible for initializing the required file systems, services and drivers that are necessary for operation of the system\&. On
|
|
\fBsystemd\fR(1)
|
|
systems, this process is split up in various discrete steps which are exposed as target units\&. (See
|
|
\fBsystemd.target\fR(5)
|
|
for detailed information about target units\&.) The boot\-up process is highly parallelized so that the order in which specific target units are reached is not deterministic, but still adheres to a limited amount of ordering structure\&.
|
|
.PP
|
|
When systemd starts up the system, it will activate all units that are dependencies of
|
|
default\&.target
|
|
(as well as recursively all dependencies of these dependencies)\&. Usually,
|
|
default\&.target
|
|
is simply an alias of
|
|
graphical\&.target
|
|
or
|
|
multi\-user\&.target, depending on whether the system is configured for a graphical UI or only for a text console\&. To enforce minimal ordering between the units pulled in, a number of well\-known target units are available, as listed on
|
|
\fBsystemd.special\fR(7)\&.
|
|
.PP
|
|
The following chart is a structural overview of these well\-known units and their position in the boot\-up logic\&. The arrows describe which units are pulled in and ordered before which other units\&. Units near the top are started before units nearer to the bottom of the chart\&.
|
|
.sp
|
|
.if n \{\
|
|
.RS 4
|
|
.\}
|
|
.nf
|
|
local\-fs\-pre\&.target
|
|
|
|
|
v
|
|
(various mounts and (various swap (various cryptsetup
|
|
fsck services\&.\&.\&.) devices\&.\&.\&.) devices\&.\&.\&.) (various low\-level (various low\-level
|
|
| | | services: udevd, API VFS mounts:
|
|
v v v tmpfiles, random mqueue, configfs,
|
|
local\-fs\&.target swap\&.target cryptsetup\&.target seed, sysctl, \&.\&.\&.) debugfs, \&.\&.\&.)
|
|
| | | | |
|
|
\e__________________|_________________ | ___________________|____________________/
|
|
\e|/
|
|
v
|
|
sysinit\&.target
|
|
|
|
|
____________________________________/|\e________________________________________
|
|
/ | | | \e
|
|
| | | | |
|
|
v v | v v
|
|
(various (various | (various rescue\&.service
|
|
timers\&.\&.\&.) paths\&.\&.\&.) | sockets\&.\&.\&.) |
|
|
| | | | v
|
|
v v | v \fIrescue\&.target\fR
|
|
timers\&.target paths\&.target | sockets\&.target
|
|
| | | |
|
|
v |_________________ | ___________________/
|
|
\e|/
|
|
v
|
|
basic\&.target
|
|
|
|
|
____________________________________/| emergency\&.service
|
|
/ | | |
|
|
| | | v
|
|
v v v \fIemergency\&.target\fR
|
|
display\- (various system (various system
|
|
manager\&.service services services)
|
|
| required for |
|
|
| graphical UIs) v
|
|
| | \fImulti\-user\&.target\fR
|
|
| | |
|
|
\e_________________ | _________________/
|
|
\e|/
|
|
v
|
|
\fIgraphical\&.target\fR
|
|
.fi
|
|
.if n \{\
|
|
.RE
|
|
.\}
|
|
.PP
|
|
Target units that are commonly used as boot targets are
|
|
\fIemphasized\fR\&. These units are good choices as goal targets, for example by passing them to the
|
|
\fIsystemd\&.unit=\fR
|
|
kernel command line option (see
|
|
\fBsystemd\fR(1)) or by symlinking
|
|
default\&.target
|
|
to them\&.
|
|
.PP
|
|
timers\&.target
|
|
is pulled\-in by
|
|
basic\&.target
|
|
asynchronously\&. This allows timers units to depend on services which become only available later in boot\&.
|
|
.SH "BOOTUP IN THE INITIAL RAM DISK (INITRD)"
|
|
.PP
|
|
The initial RAM disk implementation (initrd) can be set up using systemd as well\&. In this case, boot up inside the initrd follows the following structure\&.
|
|
.PP
|
|
The default target in the initrd is
|
|
initrd\&.target\&. The bootup process begins identical to the system manager bootup (see above) until it reaches
|
|
basic\&.target\&. From there, systemd approaches the special target
|
|
initrd\&.target\&. If the root device can be mounted at
|
|
/sysroot, the
|
|
sysroot\&.mount
|
|
unit becomes active and
|
|
initrd\-root\-fs\&.target
|
|
is reached\&. The service
|
|
initrd\-parse\-etc\&.service
|
|
scans
|
|
/sysroot/etc/fstab
|
|
for a possible
|
|
/usr
|
|
mount point and additional entries marked with the
|
|
\fIx\-initrd\&.mount\fR
|
|
option\&. All entries found are mounted below
|
|
/sysroot, and
|
|
initrd\-fs\&.target
|
|
is reached\&. The service
|
|
initrd\-cleanup\&.service
|
|
isolates to the
|
|
initrd\-switch\-root\&.target, where cleanup services can run\&. As the very last step, the
|
|
initrd\-switch\-root\&.service
|
|
is activated, which will cause the system to switch its root to
|
|
/sysroot\&.
|
|
.sp
|
|
.if n \{\
|
|
.RS 4
|
|
.\}
|
|
.nf
|
|
: (beginning identical to above)
|
|
:
|
|
v
|
|
basic\&.target
|
|
| emergency\&.service
|
|
______________________/| |
|
|
/ | v
|
|
| sysroot\&.mount \fIemergency\&.target\fR
|
|
| |
|
|
| v
|
|
| initrd\-root\-fs\&.target
|
|
| |
|
|
| v
|
|
v initrd\-parse\-etc\&.service
|
|
(custom initrd |
|
|
services\&.\&.\&.) v
|
|
| (sysroot\-usr\&.mount and
|
|
| various mounts marked
|
|
| with fstab option
|
|
| x\-initrd\&.mount\&.\&.\&.)
|
|
| |
|
|
| v
|
|
| initrd\-fs\&.target
|
|
\e______________________ |
|
|
\e|
|
|
v
|
|
initrd\&.target
|
|
|
|
|
v
|
|
initrd\-cleanup\&.service
|
|
isolates to
|
|
initrd\-switch\-root\&.target
|
|
|
|
|
v
|
|
______________________/|
|
|
/ v
|
|
| initrd\-udevadm\-cleanup\-db\&.service
|
|
v |
|
|
(custom initrd |
|
|
services\&.\&.\&.) |
|
|
\e______________________ |
|
|
\e|
|
|
v
|
|
initrd\-switch\-root\&.target
|
|
|
|
|
v
|
|
initrd\-switch\-root\&.service
|
|
|
|
|
v
|
|
Transition to Host OS
|
|
.fi
|
|
.if n \{\
|
|
.RE
|
|
.\}
|
|
.SH "SYSTEM MANAGER SHUTDOWN"
|
|
.PP
|
|
System shutdown with systemd also consists of various target units with some minimal ordering structure applied:
|
|
.sp
|
|
.if n \{\
|
|
.RS 4
|
|
.\}
|
|
.nf
|
|
(conflicts with (conflicts with
|
|
all system all file system
|
|
services) mounts, swaps,
|
|
| cryptsetup
|
|
| devices, \&.\&.\&.)
|
|
| |
|
|
v v
|
|
shutdown\&.target umount\&.target
|
|
| |
|
|
\e_______ ______/
|
|
\e /
|
|
v
|
|
(various low\-level
|
|
services)
|
|
|
|
|
v
|
|
final\&.target
|
|
|
|
|
_____________________________________/ \e_________________________________
|
|
/ | | \e
|
|
| | | |
|
|
v v v v
|
|
systemd\-reboot\&.service systemd\-poweroff\&.service systemd\-halt\&.service systemd\-kexec\&.service
|
|
| | | |
|
|
v v v v
|
|
\fIreboot\&.target\fR \fIpoweroff\&.target\fR \fIhalt\&.target\fR \fIkexec\&.target\fR
|
|
.fi
|
|
.if n \{\
|
|
.RE
|
|
.\}
|
|
.PP
|
|
Commonly used system shutdown targets are
|
|
\fIemphasized\fR\&.
|
|
.SH "SEE ALSO"
|
|
.PP
|
|
\fBsystemd\fR(1),
|
|
\fBboot\fR(7),
|
|
\fBsystemd.special\fR(7),
|
|
\fBsystemd.target\fR(5),
|
|
\fBdracut\fR(8)
|