14.1 The Linux Boot Process
The Linux boot process consists of several stages each represented by
another component. The following list briefly summarizes the boot process
and features all the major components involved.
After the computer has been turned on, the BIOS 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
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 Section 15.0, The Boot Loader.
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 14.1.1, initramfs.
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 has been successful, the initramfs is cleaned and the init
program on the root file system is executed. For more information
about init, refer to Section 14.1.2, init on initramfs. Find more
information about udev in Section 17.0, Dynamic Kernel Device Management with udev.
init handles the actual booting of the system through several
different levels providing different functionality. init is described
in Section 14.2, The init Process.
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 routines and does not
have specific hardware requirements other than sufficient memory.
initramfs must always provide an executable named init that should
execute the actual init program 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
If you need to change hardware (e.g. 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, initrd—by calling
mkinitrd. Calling mkinitrd without
any argument creates an initramfs. Calling mkinitrd
-R creates an initrd. In openSUSE®,
the modules to load are specified by the variable
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 initrd
The boot loader loads initramfs or initrd in the same way as the
kernel. It is not necessary to reinstall GRUB after updating initramfs
or initrd, because GRUB searches the directory for the right file when
14.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 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 block special files
on a RAM file system in /dev. Without those
special files, the file system and other devices would not be
- Managing RAID and LVM Setups
If you configured your system to hold the root file system under RAID
or LVM, init sets up LVM or RAID to enable access to the root file
system later. Find information about RAID and LVM in
Section 2.0, Advanced Disk Setup.
- Managing Network Configuration
If you configured your system to use a network-mounted root file
system (mounted via NFS), init must make sure that the proper network
drivers are loaded and that they are set up to allow access to the
root file system.
When init is called during the initial boot as part of the installation
process, its tasks differ from those mentioned earlier:
- Finding the Installation Medium
As you start the installation process, your machine loads an
installation kernel and a special initrd with the YaST installer
from 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
As mentioned in Section 14.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 or Rescue System
As soon as the hardware has been properly recognized, the appropriate
drivers have been loaded, and udev has created the device special
files, init starts the installation system, which contains the actual
YaST installer, or the rescue system.
- Starting YaST
Finally, init starts YaST, which starts package installation and