openSUSE-DokumentationReference > System > ◀ ▶

Kapitel 5. Booting a Linux System

Inhaltsverzeichnis

5.1. The Linux Boot Process

Booting a Linux system involves different components. The hardware itself is initialized by the BIOS or the UEFI, which starts the Kernel by means of a boot loader. After this point, the boot process with systemd is completely controlled by the operating system. systemd provides a set of „targets“ that boot setups for everyday usage, maintenance or emergencies.

5.1. The Linux Boot Process

The Linux boot process consists of several stages, each represented by a different component. The following list briefly summarizes the boot process and features all the major components involved.

  1. BIOS/UEFI.  After turning on the computer, the BIOS or the UEFI initializes the screen and keyboard and tests the main memory. Up to this stage, the machine does not access any mass storage media. Subsequently, the information about the current date, time, and the most important peripherals are loaded from the CMOS values. When the first hard disk and its geometry are recognized, the system control passes from the BIOS to the boot loader. If the BIOS supports network booting, it is also possible to configure a boot server that provides the boot loader. On x86 systems, PXE boot is needed. Other architectures commonly use the BOOTP protocol to get the boot loader.

  2. Boot Loader.  The first physical 512-byte data sector of the first hard disk is loaded into the main memory and the boot loader that resides at the beginning of this sector takes over. The commands executed by the boot loader determine the remaining part of the boot process. Therefore, the first 512 bytes on the first hard disk are referred to as the Master Boot Record (MBR). The boot loader then passes control to the actual operating system, in this case, the Linux Kernel. More information about GRUB, the Linux boot loader, can be found in Kapitel 7, The Boot Loader GRUB. For a network boot, the BIOS acts as the boot loader. It gets the image to start from the boot server and starts the system. This is completely independent of local hard disks.

  3. Kernel and initramfs.  To pass system control, the boot loader loads both the Kernel and an initial RAM-based file system (initramfs) into memory. The contents of the initramfs can be used by the Kernel directly. initramfs contains a small executable called init that handles the mounting of the real root file system. If special hardware drivers are needed before the mass storage can be accessed, they must be in initramfs. For more information about initramfs, refer to Abschnitt 5.1.1, „initramfs“. If the system does not have a local hard disk, the initramfs must provide the root file system to the Kernel. This can be done with the help of a network block device like iSCSI or SAN, but it is also possible to use NFS as the root device.

    [Note]The init Process Naming

    The initramfs process mounting the root filesystem and the operating system process setting up the system, are both commonly named „init“. However, it's two completely different programs! In this chapter we will therefore refer to them as „init on initramfs“ and „systemd“, respectively.

  4. init on initramfs .  This program performs all actions needed to mount the proper root file system, like providing Kernel functionality for the needed file system and device drivers for mass storage controllers with udev. After the root file system has been found, it is checked for errors and mounted. If this is successful, the initramfs is cleaned and the systemd daemon on the root file system is executed. For more information about init on initramfs, refer to Abschnitt 5.1.2, „init on initramfs“. Find more information about udev in Kapitel 9, Dynamic Kernel Device Management with udev.

  5. systemd.  systemd handles the actual booting of the system by starting services and mounting file systems. systemd is described in Kapitel 6, The systemd daemon.

5.1.1. initramfs

initramfs is a small cpio archive that the Kernel can load to a RAM disk. It provides a minimal Linux environment that enables the execution of programs before the actual root file system is mounted. This minimal Linux environment is loaded into memory by BIOS or UEFI routines and does not have specific hardware requirements other than sufficient memory. initramfs must always provide an executable named init that executes the systemd daemon on the root file system for the boot process to proceed.

Before the root file system can be mounted and the operating system can be started, the Kernel needs the corresponding drivers to access the device on which the root file system is located. These drivers may include special drivers for certain kinds of hard drives or even network drivers to access a network file system. The needed modules for the root file system may be loaded by init on initramfs. After the modules are loaded, udev provides the initramfs with the needed devices. Later in the boot process, after changing the root file system, it is necessary to regenerate the devices. This is done by boot.udev with the command udevtrigger.

If you need to change hardware (for example hard disks) in an installed system and this hardware requires different drivers to be present in the Kernel at boot time, you must update initramfs. This is done in the same way as with its predecessor, init—by calling mkinitrd. Calling mkinitrd without any argument creates an initramfs. Calling mkinitrd -R creates an init. In openSUSE®, the modules to load are specified by the variable INITRD_MODULES in /etc/sysconfig/kernel. After installation, this variable is automatically set to the correct value. The modules are loaded in exactly the order in which they appear in INITRD_MODULES. This is only important if you rely on the correct setting of the device files /dev/sd?. However, in current systems you also may use the device files below /dev/disk/ that are sorted in several subdirectories, named by-id, by-path and by-uuid, and always represent the same disk. This is also possible at install time by specifying the respective mount option.

[Important] Updating initramfs or init

The boot loader loads initramfs or init in the same way as the Kernel. It is not necessary to re-install GRUB after updating initramfs or init, because GRUB searches the directory for the right file when booting.

5.1.2. init on initramfs

The main purpose of init on initramfs is to prepare the mounting of and access to the real root file system. Depending on your system configuration, init on initramfs is responsible for the following tasks.

Loading Kernel Modules

Depending on your hardware configuration, special drivers may be needed to access the hardware components of your computer (the most important component being your hard drive). To access the final root file system, the Kernel needs to load the proper file system drivers.

Providing Block Special Files

For each loaded module, the Kernel generates device events. udev handles these events and generates the required special block files on a RAM file system in /dev. Without those special files, the file system and other devices would not be accessible.

Managing RAID and LVM Setups

If you configured your system to hold the root file system under RAID or LVM, init on initramfs sets up LVM or RAID to enable access to the root file system later. Find information about RAID and LVM in Kapitel 3, Advanced Disk Setup.

Managing Network Configuration

If you configured your system to use a network-mounted root file system (mounted via NFS), init on initramfs must make sure that the proper network drivers are loaded and that they are set up to allow access to the root file system.

If the file system resides on a networked block device like iSCSI or SAN, the connection to the storage server is also set up by init on initramfs.

When init on initramfs is called during the initial boot as part of the installation process, its tasks differ from those mentioned above:

Finding the Installation Medium

As you start the installation process, your machine loads an installation Kernel and a special init with the YaST installer on the installation medium. The YaST installer, which is run in a RAM file system, needs to have information about the location of the installation medium to access it and install the operating system.

Initiating Hardware Recognition and Loading Appropriate Kernel Modules

As mentioned in Abschnitt 5.1.1, „initramfs“, the boot process starts with a minimum set of drivers that can be used with most hardware configurations. init starts an initial hardware scanning process that determines the set of drivers suitable for your hardware configuration. The names of the modules needed for the boot process are written to INITRD_MODULES in /etc/sysconfig/kernel. These names are used to generate a custom initramfs that is needed to boot the system. If the modules are not needed for boot but for coldplug, the modules are written to /etc/sysconfig/hardware/hwconfig-*. All devices that are described with configuration files in this directory are initialized in the boot process.

Loading the Installation System

As soon as the hardware is properly recognized, the appropriate drivers are loaded, and udev creates the special device files, init starts the installation system with the actual YaST installer.

Starting YaST

Finally, init starts YaST, which starts package installation and system configuration.

openSUSE Reference 12.3

openSUSE-DokumentationReference > System > ◀ ▶