X-Git-Url: https://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=elogind.git;a=blobdiff_plain;f=man%2Fbootup.xml;h=a596e85b70aaa567cb6522bdde6063793ab996f5;hp=6bd22ef476c73743e6a441fc9691f45ddf48451c;hb=310b59edcf0a98343425a47ea5835fc670c0cda3;hpb=9e5f0f92915b777308797294c6e103e430957b5d diff --git a/man/bootup.xml b/man/bootup.xml index 6bd22ef47..a596e85b7 100644 --- a/man/bootup.xml +++ b/man/bootup.xml @@ -50,18 +50,20 @@ Description - 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 now (optionally) extracts and + 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 dracut8 - which looks for the root file system. After the root - file system is found and mounted the initrd hands over - control to the system manager (such as + which looks for the root file system (possibly using + systemd1 + for this). After the root file system is found and + mounted the initrd hands over control to the host's + system manager (such as systemd1) stored on the OS image which is then responsible for probing all remaining hardware, mounting all necessary @@ -132,35 +134,35 @@ v sysinit.target | - _________________/|\___________________ - / | \ - | | | - v | v - (various | rescue.service - sockets...) | | - | | v - v | rescue.target - sockets.target | - | | - \_________________ | - \| + ____________________________________/|\________________________________________ + / | | | \ + | | | | | + v v | v v + (various (various | (various rescue.service + timers...) paths...) | sockets...) | + | | | | v + v v | v rescue.target + timers.target paths.target | sockets.target + | | | | + \__________________|_________________ | ___________________/ + \|/ v basic.target | - __________________________________/| emergency.service - / | | | - | | | v - v v v emergency.target - display- (various system (various system - manager.service services services) - | required for | - | graphical UIs) v - | | multi-user.target - | | | - \_______________ | _________________/ + ____________________________________/| emergency.service + / | | | + | | | v + v v v emergency.target + display- (various system (various system + manager.service services services) + | required for | + | graphical UIs) v + | | multi-user.target + | | | + \_________________ | _________________/ \|/ v - graphical.target + graphical.target Target units that are commonly used as boot targets are emphasized. These @@ -174,24 +176,41 @@ - Systemd in the Initrd - If the initrd creation tool used the services provided - by systemd, the default target in the initrd is the - initrd-fs.target. The process is the same as above until the basic.target is reached. - Systemd now continues to the initrd.target. If the root device could be mounted - on /sysroot, the sysroot.mount unit is active and the initrd-root-fs.target is reached. - initrd-parse-etc.service scans /sysroot/etc/fstab for the /usr mountpoint and for entries - marked with the x-initrd.mount option set. If these mountpoint are - mounted in /sysroot, the initrd-fs.target is reached. - The initrd-cleanup.service isolates to the initrd-switch-root.target, - where cleanup services can run. At the very last end - initrd-switch-root.service is activated, which will cause - the system to switch root to /sysroot. + Bootup in the Initial RAM Disk (initrd) + 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. + + 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 + x-initrd.mount 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. - - (same as above) - : + : (beginning identical to above) : v basic.target @@ -204,17 +223,16 @@ | initrd-root-fs.target | | | v - | initrd-parse-etc.service - (custom initrd services) | - | v + v initrd-parse-etc.service + (custom initrd | + services...) v | (sysroot-usr.mount and | various mounts marked | with fstab option - | x-initrd.mount) + | x-initrd.mount...) | | | v | initrd-fs.target - | | \______________________ | \| v @@ -227,11 +245,11 @@ | v ______________________/| - / | + / v | initrd-udevadm-cleanup-db.service - | | - (custom initrd services) | - | | + v | + (custom initrd | + services...) | \______________________ | \| v @@ -241,17 +259,16 @@ initrd-switch-root.service | v - switch-root - + Transition to Host OS System Manager Shutdown - System shutdown also consists of various target - units with some minimal ordering structure - applied: + System shutdown with systemd also consists of + various target units with some minimal ordering + structure applied: