Adding upstream version 4.22.0.upstream/4.22.0

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 349 insertions, 0 deletions

diff --git a/upstream/fedora-rawhide/man7/bootup.7 b/upstream/fedora-rawhide/man7/bootup.7
new file mode 100644
index 00000000..3c82f20d
--- /dev/null
+++ b/upstream/fedora-rawhide/man7/bootup.7
@@ -0,0 +1,349 @@
+'\" t
+.TH "BOOTUP" "7" "" "systemd 255" "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 boot of a Linux system\&. Immediately after power\-up, the system firmware will do minimal hardware initialization, and hand control over to a boot loader (e\&.g\&.
+\fBsystemd-boot\fR(7)
+or
+\m[blue]\fBGRUB\fR\m[]\&\s-2\u[1]\d\s+2) stored on a persistent storage device\&. This boot loader will then invoke an OS kernel from disk (or the network)\&. On systems using EFI or other types of firmware, this firmware may also load the kernel directly\&.
+.PP
+The kernel (optionally) mounts an in\-memory file system, often generated by
+\fBdracut\fR(8), which looks for the root file system\&. Nowadays this is implemented as an "initramfs" \(em a compressed CPIO archive that the kernel extracts into a tmpfs\&. In the past normal file systems using an in\-memory block device (ramdisk) were used, and the name "initrd" is still used to describe both concepts\&. It\*(Aqs the boot loader or the firmware that loads both the kernel and initrd/initramfs images into memory, but the kernel which interprets it as a file system\&.
+\fBsystemd\fR(1)
+may be used to manage services in the initrd, similarly to the real system\&.
+.PP
+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 in the root file system, 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
+                             cryptsetup\-pre\&.target veritysetup\-pre\&.target
+                                                  |
+(various low\-level                                v
+ API VFS mounts:             (various cryptsetup/veritysetup devices\&.\&.\&.)
+ mqueue, configfs,                                |    |
+ debugfs, \&.\&.\&.)                                    v    |
+ |                                  cryptsetup\&.target  |
+ |  (various swap                                 |    |    remote\-fs\-pre\&.target
+ |   devices\&.\&.\&.)                                  |    |     |        |
+ |    |                                           |    |     |        v
+ |    v                       local\-fs\-pre\&.target |    |     |  (network file systems)
+ |  swap\&.target                       |           |    v     v                 |
+ |    |                               v           |  remote\-cryptsetup\&.target  |
+ |    |  (various low\-level  (various mounts and  |  remote\-veritysetup\&.target |
+ |    |   services: udevd,    fsck services\&.\&.\&.)   |             |              |
+ |    |   tmpfiles, random            |           |             |    remote\-fs\&.target
+ |    |   seed, sysctl, \&.\&.\&.)          v           |             |              |
+ |    |      |                 local\-fs\&.target    |             | _____________/
+ |    |      |                        |           |             |/
+ \e____|______|_______________   ______|___________/             |
+                             \e /                                |
+                              v                                 |
+                       sysinit\&.target                           |
+                              |                                 |
+       ______________________/|\e_____________________           |
+      /              |        |      |               \e          |
+      |              |        |      |               |          |
+      v              v        |      v               |          |
+ (various       (various      |  (various            |          |
+  timers\&.\&.\&.)      paths\&.\&.\&.)   |   sockets\&.\&.\&.)        |          |
+      |              |        |      |               |          |
+      v              v        |      v               |          |
+timers\&.target  paths\&.target   |  sockets\&.target      |          |
+      |              |        |      |               v          |
+      v              \e_______ | _____/         rescue\&.service   |
+                             \e|/                     |          |
+                              v                      v          |
+                          basic\&.target         \fIrescue\&.target\fR    |
+                              |                                 |
+                      ________v____________________             |
+                     /              |              \e            |
+                     |              |              |            |
+                     v              v              v            |
+                 display\-    (various system   (various system  |
+             manager\&.service     services        services)      |
+                     |         required for        |            |
+                     |        graphical UIs)       v            v
+                     |              |            \fImulti\-user\&.target\fR
+emergency\&.service    |              |              |
+        |            \e_____________ | _____________/
+        v                          \e|/
+\fIemergency\&.target\fR                    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 "USER MANAGER STARTUP"
+.PP
+The system manager starts the
+user@\fIuid\fR\&.service
+unit for each user, which launches a separate unprivileged instance of
+\fBsystemd\fR
+for each user \(em the user manager\&. Similarly to the system manager, the user manager starts units which are pulled in by
+default\&.target\&. The following chart is a structural overview of the well\-known user units\&. For non\-graphical sessions,
+default\&.target
+is used\&. Whenever the user logs into a graphical session, the login manager will start the
+graphical\-session\&.target
+target that is used to pull in units required for the graphical session\&. A number of targets (shown on the right side) are started when specific hardware is available to the user\&.
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+   (various           (various         (various
+    timers\&.\&.\&.)         paths\&.\&.\&.)        sockets\&.\&.\&.)    (sound devices)
+        |                  |                 |               |
+        v                  v                 v               v
+  timers\&.target      paths\&.target     sockets\&.target    sound\&.target
+        |                  |                 |
+        \e______________   _|_________________/         (bluetooth devices)
+                       \e /                                   |
+                        V                                    v
+                  basic\&.target                          bluetooth\&.target
+                        |
+             __________/ \e_______                      (smartcard devices)
+            /                    \e                           |
+            |                    |                           v
+            |                    v                      smartcard\&.target
+            v            graphical\-session\-pre\&.target
+(various user services)          |                       (printers)
+            |                    v                           |
+            |       (services for the graphical session)     v
+            |                    |                       printer\&.target
+            v                    v
+     \fIdefault\&.target\fR      graphical\-session\&.target
+.fi
+.if n \{\
+.RE
+.\}
+.SH "BOOTUP IN THE INITRD"
+.PP
+Systemd can be used in the initrd as well\&. It detects the initrd environment by checking for the
+/etc/initrd\-release
+file\&. The default target in the initrd is
+initrd\&.target\&. The bootup process is identical to the system manager bootup until the target
+basic\&.target\&. After that, systemd executes the special target
+initrd\&.target\&. Before any file systems are mounted, the manager will determine whether the system shall resume from hibernation or proceed with normal boot\&. This is accomplished by
+systemd\-hibernate\-resume\&.service
+which must be finished before
+local\-fs\-pre\&.target, so no filesystems can be mounted before the check is complete\&. When the root device becomes available,
+initrd\-root\-device\&.target
+is reached\&. 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
+       |            initrd\-root\-device\&.target          \fIemergency\&.target\fR
+       |                       |
+       |                       v
+       |                  sysroot\&.mount
+       |                       |
+       |                       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/
+                               |           veritysetup
+                               |          devices, \&.\&.\&.)
+                               |                |
+                               v                v
+                        shutdown\&.target    umount\&.target
+                               |                |
+                               \e_______   ______/
+                                       \e /
+                                        v
+                               (various low\-level
+                                    services)
+                                        |
+                                        v
+                                  final\&.target
+                                        |
+            ___________________________/ \e_________________
+           /               |               |               \e
+           |               |               |               |
+           v               |               |               |
+systemd\-reboot\&.service     |               |               |
+           |               v               |               |
+           |    systemd\-poweroff\&.service   |               |
+           v               |               v               |
+     \fIreboot\&.target\fR         |      systemd\-halt\&.service     |
+                           v               |               v
+                   \fIpoweroff\&.target\fR         |    systemd\-kexec\&.service
+                                           v               |
+                                      \fIhalt\&.target\fR          |
+                                                           v
+                                                     \fIkexec\&.target\fR
+.fi
+.if n \{\
+.RE
+.\}
+.PP
+Commonly used system shutdown targets are
+\fIemphasized\fR\&.
+.PP
+Note that
+\fBsystemd-halt.service\fR(8),
+systemd\-reboot\&.service,
+systemd\-poweroff\&.service
+and
+systemd\-kexec\&.service
+will transition the system and server manager (PID 1) into the second phase of system shutdown (implemented in the
+systemd\-shutdown
+binary), which will unmount any remaining file systems, kill any remaining processes and release any other remaining resources, in a simple and robust fashion, without taking any service or unit concept into account anymore\&. At that point, regular applications and resources are generally terminated and released already, the second phase hence operates only as safety net for everything that couldn\*(Aqt be stopped or released for some reason during the primary, unit\-based shutdown phase described above\&.
+.SH "SEE ALSO"
+.PP
+\fBsystemd\fR(1),
+\fBboot\fR(7),
+\fBsystemd.special\fR(7),
+\fBsystemd.target\fR(5),
+\fBsystemd-halt.service\fR(8),
+\fBdracut\fR(8)
+.SH "NOTES"
+.IP " 1." 4
+GRUB
+.RS 4
+\%https://www.gnu.org/software/grub/
+.RE