| <?xml version='1.0'?> <!--*-nxml-*--> |
| <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" |
| "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> |
| |
| <!-- |
| SPDX-License-Identifier: LGPL-2.1+ |
| --> |
| |
| <refentry id="bootup"> |
| |
| <refentryinfo> |
| <title>bootup</title> |
| <productname>systemd</productname> |
| </refentryinfo> |
| |
| <refmeta> |
| <refentrytitle>bootup</refentrytitle> |
| <manvolnum>7</manvolnum> |
| </refmeta> |
| |
| <refnamediv> |
| <refname>bootup</refname> |
| <refpurpose>System bootup process</refpurpose> |
| </refnamediv> |
| |
| <refsect1> |
| <title>Description</title> |
| |
| <para>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 |
| <citerefentry project='die-net'><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>, |
| which looks for the root file system (possibly using |
| <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> |
| for this). After the root file system is found and mounted, the |
| initrd hands over control to the host's system manager (such as |
| <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>) |
| stored on the OS image, which is then responsible for probing all |
| remaining hardware, mounting all necessary file systems and |
| spawning all configured services.</para> |
| |
| <para>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.</para> |
| |
| <para>Additional information about the system boot process may be |
| found in |
| <citerefentry project='man-pages'><refentrytitle>boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para> |
| </refsect1> |
| |
| <refsect1> |
| <title>System Manager Bootup</title> |
| |
| <para>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 |
| <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> |
| systems, this process is split up in various discrete steps which |
| are exposed as target units. (See |
| <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry> |
| 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.</para> |
| |
| <para>When systemd starts up the system, it will activate all |
| units that are dependencies of <filename>default.target</filename> |
| (as well as recursively all dependencies of these dependencies). |
| Usually, <filename>default.target</filename> is simply an alias of |
| <filename>graphical.target</filename> or |
| <filename>multi-user.target</filename>, 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 |
| <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para> |
| |
| <para>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.</para> |
| |
| <!-- note: do not use unicode ellipsis here, because docbook will replace that |
| with three dots anyway, messing up alignment --> |
| <programlisting>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, ...) |
| | | | | | |
| \__________________|_________________ | ___________________|____________________/ |
| \|/ |
| v |
| sysinit.target |
| | |
| ____________________________________/|\________________________________________ |
| / | | | \ |
| | | | | | |
| v v | v v |
| (various (various | (various rescue.service |
| timers...) paths...) | sockets...) | |
| | | | | v |
| v v | v <emphasis>rescue.target</emphasis> |
| timers.target paths.target | sockets.target |
| | | | | |
| v \_________________ | ___________________/ |
| \|/ |
| v |
| basic.target |
| | |
| ____________________________________/| emergency.service |
| / | | | |
| | | | v |
| v v v <emphasis>emergency.target</emphasis> |
| display- (various system (various system |
| manager.service services services) |
| | required for | |
| | graphical UIs) v |
| | | <emphasis>multi-user.target</emphasis> |
| | | | |
| \_________________ | _________________/ |
| \|/ |
| v |
| <emphasis>graphical.target</emphasis></programlisting> |
| |
| <para>Target units that are commonly used as boot targets are |
| <emphasis>emphasized</emphasis>. These units are good choices as |
| goal targets, for example by passing them to the |
| <varname>systemd.unit=</varname> kernel command line option (see |
| <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>) |
| or by symlinking <filename>default.target</filename> to them. |
| </para> |
| |
| <para><filename>timers.target</filename> is pulled-in by |
| <filename>basic.target</filename> asynchronously. This allows |
| timers units to depend on services which become only available |
| later in boot.</para> |
| </refsect1> |
| |
| <refsect1> |
| <title>Bootup in the Initial RAM Disk (initrd)</title> |
| <para>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.</para> |
| |
| <para>The default target in the initrd is |
| <filename>initrd.target</filename>. The bootup process begins |
| identical to the system manager bootup (see above) until it |
| reaches <filename>basic.target</filename>. From there, systemd |
| approaches the special target <filename>initrd.target</filename>. |
| |
| Before any file systems are mounted, it must be determined whether |
| the system will resume from hibernation or proceed with normal boot. |
| This is accomplished by <filename>systemd-hibernate-resume@.service</filename> |
| which must be finished before <filename>local-fs-pre.target</filename>, |
| so no filesystems can be mounted before the check is complete. |
| |
| When the root device becomes available, |
| <filename>initd-root-device.target</filename> is reached. |
| If the root device can be mounted at |
| <filename>/sysroot</filename>, the |
| <filename>sysroot.mount</filename> unit becomes active and |
| <filename>initrd-root-fs.target</filename> is reached. The service |
| <filename>initrd-parse-etc.service</filename> scans |
| <filename>/sysroot/etc/fstab</filename> for a possible |
| <filename>/usr</filename> mount point and additional entries |
| marked with the <emphasis>x-initrd.mount</emphasis> option. All |
| entries found are mounted below <filename>/sysroot</filename>, and |
| <filename>initrd-fs.target</filename> is reached. The service |
| <filename>initrd-cleanup.service</filename> isolates to the |
| <filename>initrd-switch-root.target</filename>, where cleanup |
| services can run. As the very last step, the |
| <filename>initrd-switch-root.service</filename> is activated, |
| which will cause the system to switch its root to |
| <filename>/sysroot</filename>. |
| </para> |
| |
| <programlisting> : (beginning identical to above) |
| : |
| v |
| basic.target |
| | emergency.service |
| ______________________/| | |
| / | v |
| | initrd-root-device.target <emphasis>emergency.target</emphasis> |
| | | |
| | 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 |
| \______________________ | |
| \| |
| v |
| initrd.target |
| | |
| v |
| initrd-cleanup.service |
| isolates to |
| initrd-switch-root.target |
| | |
| v |
| ______________________/| |
| / v |
| | initrd-udevadm-cleanup-db.service |
| v | |
| (custom initrd | |
| services...) | |
| \______________________ | |
| \| |
| v |
| initrd-switch-root.target |
| | |
| v |
| initrd-switch-root.service |
| | |
| v |
| Transition to Host OS</programlisting> |
| </refsect1> |
| |
| <refsect1> |
| <title>System Manager Shutdown</title> |
| |
| <para>System shutdown with systemd also consists of various target |
| units with some minimal ordering structure applied:</para> |
| |
| <programlisting> (conflicts with (conflicts with |
| all system all file system |
| services) mounts, swaps, |
| | cryptsetup |
| | devices, ...) |
| | | |
| v v |
| shutdown.target umount.target |
| | | |
| \_______ ______/ |
| \ / |
| v |
| (various low-level |
| services) |
| | |
| v |
| final.target |
| | |
| _____________________________________/ \_________________________________ |
| / | | \ |
| | | | | |
| v v v v |
| systemd-reboot.service systemd-poweroff.service systemd-halt.service systemd-kexec.service |
| | | | | |
| v v v v |
| <emphasis>reboot.target</emphasis> <emphasis>poweroff.target</emphasis> <emphasis>halt.target</emphasis> <emphasis>kexec.target</emphasis></programlisting> |
| |
| <para>Commonly used system shutdown targets are <emphasis>emphasized</emphasis>.</para> |
| |
| <para>Note that |
| <citerefentry><refentrytitle>systemd-halt.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, |
| <filename>systemd-reboot.service</filename>, <filename>systemd-poweroff.service</filename> and |
| <filename>systemd-kexec.service</filename> will transition the system and server manager (PID 1) into the second |
| phase of system shutdown (implemented in the <filename>systemd-shutdown</filename> 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't be stopped or released for some reason during the primary, unit-based |
| shutdown phase described above.</para> |
| </refsect1> |
| |
| <refsect1> |
| <title>See Also</title> |
| <para> |
| <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, |
| <citerefentry project='man-pages'><refentrytitle>boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>, |
| <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>, |
| <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>, |
| <citerefentry><refentrytitle>systemd-halt.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, |
| <citerefentry project='die-net'><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry> |
| </para> |
| </refsect1> |
| |
| </refentry> |