diff options
Diffstat (limited to 'man/bootup.xml')
| -rw-r--r-- | man/bootup.xml | 562 |
1 files changed, 270 insertions, 292 deletions
diff --git a/man/bootup.xml b/man/bootup.xml index 0854b6c316..b5c3e1523a 100644 --- a/man/bootup.xml +++ b/man/bootup.xml @@ -1,6 +1,6 @@ <?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"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> <!-- This file is part of systemd. @@ -23,301 +23,279 @@ <refentry id="bootup"> - <refentryinfo> - <title>bootup</title> - <productname>systemd</productname> - - <authorgroup> - <author> - <contrib>Developer</contrib> - <firstname>Lennart</firstname> - <surname>Poettering</surname> - <email>lennart@poettering.net</email> - </author> - </authorgroup> - </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> + <refentryinfo> + <title>bootup</title> + <productname>systemd</productname> + + <authorgroup> + <author> + <contrib>Developer</contrib> + <firstname>Lennart</firstname> + <surname>Poettering</surname> + <email>lennart@poettering.net</email> + </author> + </authorgroup> + </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> <programlisting>local-fs-pre.target - | - v + | + 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, + 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>. 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 - | sysroot.mount <emphasis>emergency.target</emphasis> - | | - | 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 + | | | | | + \__________________|_________________ | ___________________|____________________/ + \|/ + 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>. + 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 + | sysroot.mount <emphasis>emergency.target</emphasis> + | | + | 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> - </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 project='die-net'><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry> - </para> - </refsect1> + | | | | + 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> + </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 project='die-net'><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> </refentry> |