16 Introduction to the boot process #

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 boot media and its geometry are recognized, the system control passes from the BIOS/UEFI to the boot loader.

On a machine equipped with a traditional BIOS, only code from the first physical 512-byte data sector (the Master Boot Record, MBR) of the boot disk can be loaded. Only a minimal GRUB 2 fits into the MBR. Its sole purpose is to load a GRUB 2 core image containing file system drivers from the gap between the MBR and the first partition (MBR partition table) or from the BIOS boot partition (GPT partition table). This image contains file system drivers and therefore is able to access /boot located on the root file system. /boot contains additional modules for GRUB 2 core as well as the kernel and the initramfs image. When it has access to this partition, GRUB 2 loads the kernel and the initramfs image into memory and hands control over to the kernel.

When booting a BIOS system from an encrypted file system that includes an encrypted /boot partition, you need to enter the password for decryption twice. It is first needed by GRUB 2 to decrypt /boot and then for systemd to mount the encrypted volumes.

On machines with UEFI the boot process is much simpler than on machines with a traditional BIOS. The firmware is able to read from a FAT formatted system partition of disks with a GPT partition table. This EFI system-partition (in the running system mounted as /boot/efi) holds enough space to host a fully fledged GRUB 2 which is directly loaded and executed by the firmware.

If the BIOS/UEFI supports network booting, it is also possible to configure a boot server that provides the boot loader. The system can then be booted via PXE. The BIOS/UEFI acts as the boot loader. It gets the boot image from the boot server and starts the system, independent of local hard disks.

On IBM Z the boot process must be initialized by a boot loader called zipl (z initial program load). Although zipl supports reading from multiple file systems, it does not support the SLE default file system (Btrfs) or booting from snapshots. SUSE Linux Enterprise Server therefore uses a two-stage boot process that ensures full Btrfs support at boot-time:

initramfs (initial RAM file system) is a small cpio archive that the kernel can load into a RAM disk. It is located at /boot/initrd. It can be created with a tool called dracut—refer to man 8 dracut for details.

The initramfs 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. The initramfs archive 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 disks or even network drivers to access a network file system. The needed modules for the root file system are 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 the systemd unit systemd-udev-trigger.service.

16.2.2.1.1 Regenerating the initramfs #

  

Because the initramfs contains drivers, it needs to be updated whenever a new version of one of its drivers is available. This is done automatically when installing the package containing the driver update. YaST or zypper informs you about this by showing the output of the command that generates the initramfs. However, there are specific occasions when you need to regenerate an initramfs manually:

Adding drivers because of hardware changes

If you need to change hardware, for example, hard disks, and this hardware requires different drivers to be in the kernel at boot time, you must update the initramfs file.

Open or create /etc/dracut.conf.d/10-DRIVER.conf and add the following line (mind the leading blank space):

force_drivers+=" DRIVER1 "

Replace DRIVER1 with the module name of the driver. If you need to add more than one driver, list them space-separated:

force_drivers+=" DRIVER1 DRIVER2 "

Proceed with Procedure 16.1, “Generate an initramfs”.

Moving system directories to a RAID or LVM

Whenever you move swap files, or system directories like /usr in a running system to a RAID or logical volume, you need to create an initramfs that contains support for software RAID or LVM drivers.

To do so, create the respective entries in /etc/fstab and mount the new entries (for example with mount -a and/or swapon -a).

Proceed with Procedure 16.1, “Generate an initramfs”.

Adding disks to an LVM group or Btrfs RAID containing the root file system

Whenever you add (or remove) a disk to a logical volume group or a Btrfs RAID containing the root file system, you need to create an initramfs that contains support for the enlarged volume. Follow the instructions at Procedure 16.1, “Generate an initramfs”.

Proceed with Procedure 16.1, “Generate an initramfs”.

Changing kernel variables

If you change the values of kernel variables via the sysctl interface by editing related files (/etc/sysctl.conf or /etc/sysctl.d/*.conf), the change will be lost on the next system reboot. Even if you load the values with sysctl --system at runtime, the changes are not saved into the initramfs file. You need to update it by proceeding as outlined in Procedure 16.1, “Generate an initramfs”.

Adding or removing swap devices, re-creating swap area

Whenever you add or remove a swap device, or re-create a swap area with a different UUID, update the initramfs as outlined in Procedure 16.1, “Generate an initramfs”. You may also need to update GRUB_CMDLINE_* variables that include the resume= option in /etc/default/grub, and then regenerate /boot/grub2/grub.cfg as outlined in Section 18.2.1, “The file /boot/grub2/grub.cfg”.

Procedure 16.1: Generate an initramfs #

  

Important

All commands in the following procedure need to be executed as the root user.

1. Enter your /boot directory:

   # cd /boot

2. Generate a new initramfs file with dracut, replacing MY_INITRAMFS with a file name of your choice:

   # dracut MY_INITRAMFS

   Alternatively, run dracut -f FILENAME to replace an existing init file.

3. (Skip this step if you ran dracut -f in the previous step.) Create a symbolic link from the initramfs file you created in the previous step to initrd:

   #  ln -sf MY_INITRAMFS initrd

4. On the IBM Z architecture, additionally run grub2-install.

When init on initramfs is called during the initial boot as part of the installation process, its tasks differ from those mentioned above. The installation system also does not start systemd from initramfs—these tasks are performed by linuxrc.