<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
+ <para>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.
+ <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry> or
+ <ulink url="https://www.gnu.org/software/grub/">GRUB</ulink>) 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.</para>
+
+ <para>The kernel (optionally) mounts an in-memory file system, often 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>
+ which looks for the root file system. Nowadays this is usually implemented as an initramfs — a compressed
+ archive which is extracted when the kernel boots up into a lightweight in-memory file system based on
+ tmpfs, but 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's 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. <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> may
+ be used to manage services in the initrd, similarly to the real system.</para>
+
+ <para>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 in
+ the root file system, 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
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
+ <para>systemd detects that it is run within an initrd by checking
+ for the file <filename>/etc/initrd-release</filename>.
+ 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
projects / thirdparty / systemd.git / blobdiff