openSUSE Leap Documentation › Reference › System › Booting a Linux System
ContentsContents
Reference
  1. About This Guide
  2. I Advanced Administration
    1. 1 YaST in Text Mode
    2. 2 Managing Software with Command Line Tools
    3. 3 System Recovery and Snapshot Management with Snapper
    4. 4 Remote Access with VNC
    5. 5 Advanced Disk Setup
    6. 6 Installing Multiple Kernel Versions
    7. 7 GNOME Configuration for Administrators
  3. II System
    1. 8 32-Bit and 64-Bit Applications in a 64-Bit System Environment
    2. 9 Booting a Linux System
    3. 10 The systemd Daemon
    4. 11 journalctl: Query the systemd Journal
    5. 12 The Boot Loader GRUB 2
    6. 13 Basic Networking
    7. 14 UEFI (Unified Extensible Firmware Interface)
    8. 15 Special System Features
    9. 16 Dynamic Kernel Device Management with udev
  4. III Services
    1. 17 SLP
    2. 18 Time Synchronization with NTP
    3. 19 The Domain Name System
    4. 20 DHCP
    5. 21 Samba
    6. 22 Sharing File Systems with NFS
    7. 23 On-Demand Mounting with Autofs
    8. 24 The Apache HTTP Server
    9. 25 Setting up an FTP Server with YaST
    10. 26 The Proxy Server Squid
  5. IV Mobile Computers
    1. 27 Mobile Computing with Linux
    2. 28 Using NetworkManager
    3. 29 Power Management
  6. A An Example Network
  7. B GNU Licenses
Navigation←→
openSUSE Leap Documentation › Reference › System › Booting a Linux System
Top
←→
Applies to openSUSE Leap 42.1

9 Booting a Linux System

Abstract

Booting a Linux system involves different components and tasks. 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 is completely controlled by the operating system and handled by systemd. systemd provides a set of “targets” that boot setups for everyday usage, maintenance or emergencies.

9.1 The Linux Boot Process
9.2 initramfs
9.3 Init on initramfs

9.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_64 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 called 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 2, the Linux boot loader, can be found in Chapter 12, The Boot Loader GRUB 2. For a network boot, the BIOS acts as the boot loader. It gets the boot image 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 Section 9.2, “initramfs”. If the system does not have a local hard disk, the initramfs must provide the root file system for 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
    Note: The init Process Naming

    Two different programs are commonly named “init”:

    1. the initramfs process mounting the root file system

    2. the operating system process setting up the system

    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. It provides 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 Section 9.3, “Init on initramfs”. Find more information about udev in Chapter 16, Dynamic Kernel Device Management with udev.

  5. systemd.  By starting services and mounting file systems, systemd handles the actual booting of the system. systemd is described in Chapter 10, The systemd Daemon.

9.2 initramfs

initramfs is a small cpio archive that the Kernel can load into 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. 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 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 the systemd unit udev.service 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 in the Kernel at boot time, you must update the initramfs file. This is done by calling dracut -f (the option -f overwrites the existing initramfs file). To add a driver for the new hardware, edit /etc/dracut.conf.d/01-dist.conf and add the following line. 

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 (driver1 driver2.

Important
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 2 after updating initramfs or init, because GRUB 2 searches the directory for the right file when booting.

Tip
Tip: Changing Kernel Variables

If you change the values of some 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 calling dracut -f (the option -f overwrites the existing initramfs file).

9.3 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 disk). 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.

In case you want to change your /usr or swap partitions directly without the help of YaST, further actions are needed. If you forget these steps, your system will start in emergency mode. To avoid starting in emergency mode, perform the following steps:

Procedure 9.1: Updating Init RAM Disk When Switching to Logical Volumes

  1. Edit the corresponding entry in /etc/fstab and replace your previous partitons with the logical volume.

  2. Execute the following commands:

    root # mount -a
root # swapon -a

  3. Regenerate your initial ram disk (initramfs) with mkinitrd or dracut.

  4. For z Systems, additionally run grub2-install.

Find more information about RAID and LVM in Chapter 5, 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 network 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

When starting the installation process, your machine loads an installation Kernel and a special init containing the YaST installer. The YaST installer is running in a RAM file system and needs to have information about the location of the installation medium to access it for installing the operating system.

Initiating Hardware Recognition and Loading Appropriate Kernel Modules

As mentioned in Section 9.2, “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. These drivers 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 can be loaded with systemd; for more information, see Section 10.6.4, “Loading Kernel Modules”.

Loading the Installation System

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

Starting YaST

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

→Chapter 10 The systemd Daemon←Chapter 8 32-Bit and 64-Bit Applications in a 64-Bit System Environment
Print this page

© 2018 SUSE