This is a draft document that was built and uploaded automatically. It may document beta software and be incomplete or even incorrect. Use this document at your own risk.
systemd daemonjournalctl: query the systemd journaludev| Revision History | |
|---|---|
| 2024-06-27 | |
Booting a Linux system involves different components and tasks. After a
firmware and hardware initialization process, which depends on the
machine's architecture, the kernel is started by the boot loader
GRUB 2. After this point, the boot process is controlled by the
operating system and handled by systemd. systemd provides a set of
“targets” that boot configurations for everyday usage,
maintenance or emergencies.
This chapter uses terms that can be interpreted ambiguously. To understand how they are used here, read the definitions below:
initTwo different processes are commonly named “init”:
The initramfs process mounting the root
file system
The operating system process that starts all other processes that is executed from the real root file system
In both cases, the systemd program is taking care of this task. It is
first executed from the initramfs to mount the
root file system. When that has succeeded, it is re-executed from the
root file system as the initial process. To avoid confusing these two
systemd processes, we refer to the first process as init on
initramfs and to the second one as
systemd.
initrd/initramfs
An initrd (initial RAM disk) is an image file
containing a root file system image which is loaded by the kernel and
mounted from /dev/ram as the temporary root file
system. Mounting this file system requires a file system driver.
Beginning with kernel 2.6.13, the initrd has been replaced by the
initramfs (initial RAM file system), which does
not require a file system driver to be mounted. openSUSE Leap exclusively
uses an initramfs. However, since the
initramfs is stored as
/boot/initrd, it is often called
“initrd”. In this chapter we exclusively use the name
initramfs.
The Linux boot process consists of several stages, each represented by a different component:
During the initialization phase, the machine's hardware is set up, and the devices are prepared. This process differs across hardware architectures.
openSUSE Leap uses the boot loader GRUB 2 on all architectures. Depending on the architecture and firmware, starting the GRUB 2 boot loader can be a multi-step process. The purpose of the boot loader is to load the kernel and the initial, RAM-based file system (initramfs). For more information about GRUB 2, refer to Chapter 12, The boot loader GRUB 2.
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.
When the boot loader has passed on system control, the boot process is the
same on all architectures. The boot loader loads both the kernel and an
initial RAM-based file system (initramfs) into
memory and the kernel takes over.
After the kernel has set up memory management and has detected the CPU type
and its features, it initializes the hardware and mounts the temporary root
file system from the memory that was loaded with the
initramfs.
initramfs file #Edit source
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.
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:
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 9.1, “Generate an initramfs”.
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 9.1, “Generate an initramfs”.
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 9.1, “Generate an initramfs”.
Proceed with Procedure 9.1, “Generate an initramfs”.
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 9.1, “Generate an initramfs”.
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 9.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 12.2.1, “The file /boot/grub2/grub.cfg”.
All commands in the following procedure need to be executed as the
root user.
Enter your /boot directory:
# cd /boot
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.
(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_INITRAMFSinitrd
The temporary root file system mounted by the kernel from the
initramfs contains the executable systemd (which
is called init on
initramfs in the following, also see Section 9.1, “Terminology”. 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.
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.
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.
The kernel generates device events depending on loaded modules.
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.
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.
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.
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.
openSUSE Leap supports booting from a secondary iSCSI target if the
primary target is not available. .
If the root file system fails to mount from within the boot environment, it must be checked and repaired before the boot can continue. The file system checker will be automatically started for Ext3 and Ext4 file systems. The repair process is not automated for XFS and Btrfs file systems, and the user is presented with information describing the options available to repair the file system. When the file system has been successfully repaired, exiting the boot environment will cause the system to retry mounting the root file system. If successful, the boot will continue normally.
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.
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.
As mentioned in Section 9.2.2.1, “The initramfs file”, the boot process
starts with a minimum set of drivers that can be used with most
hardware configurations. On AArch64, POWER, and AMD64/Intel 64 machines,
linuxrc starts an initial hardware scanning process
that determines the set of drivers suitable for your hardware
configuration. On IBM Z, a list of drivers and their parameters
needs to be provided, for example, via linuxrc or a parmfile.
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”.
When the hardware is properly recognized, the appropriate drivers are
loaded. The udev program
creates the special device files and linuxrc
starts the installation system with the YaST installer.
Finally, linuxrc starts YaST, which starts
the package installation and the system configuration.
After the “real” 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. systemd is Linux's system and service
manager. It is the parent process that is started as PID 1 and acts as an
init system which brings up and maintains user space services. See Chapter 10, The systemd daemon for details.