Shulou(Shulou.com)06/02 Report--

A guided understanding of the operating system boot and boot process is essential for configuring the operating system and solving related startup problems. This article states the process of the GRUB2 boot loader booting the kernel and the systemd initialization system executing the boot boot operating system.

In fact, the startup of the operating system is divided into two stages: booting boot and starting startup. The boot phase begins when the power switch is turned on and ends when the kernel initialization completes and the systemd process runs successfully. The startup phase takes over the rest of the work until the operating system becomes operational.

Overall, the boot and boot process of Linux is fairly easy to understand, and the different steps are described in detail in the following sections.

BIOS Power on self Test (POST)

Bootloader (GRUB2)

Kernel initialization

Start systemd, which is the father of all processes.

Note that this article uses GRUB2 and systemd as carriers to describe the boot and boot process of the operating system, because they are the boot loader and initialization software used by mainstream linux distributions. Of course, some other related software used in the past is still used in some Linux distributions.

Guiding process

The boot process can be initialized in one of two ways. First, if the system is turned off, turning on the power button will start the system boot process. Second, if the operating system is already running on a local user (that user can be root or other unprivileged user), the user can initiate a restart programmatically through the graphical interface or command line interface, thus triggering the system boot process. Restarting includes a shutdown and a restart operation.

BIOS Power on self Test (POST)

In fact, Linux does nothing during the power-on self-test, and the power-on self-test is mainly completed by the hardware, which is the same for all operating systems. When the computer is powered on, the computer begins to perform the POST (Power-on self-Test Power On Self Test) process of BIOS (basic input and output system Basic I Dot O System).

In 1981, in the first personal computer designed by IBM, the BIOS was designed to initialize hardware components. As a part of BIOS, POST is used to check whether the basic function of computer hardware is normal. If POST fails, the computer will not work and the boot process will be interrupted.

The BIOS power-on self-test confirms that the basic function of the hardware is normal, and then generates a BIOS interrupt INT 13H that points to the boot sector of an accessible bootable device. The first boot sector it finds that contains a valid boot record will be loaded into memory, and control will be transferred from the boot sector to this code.

The boot sector is the real first stage of the boot loader. Most Linux distributions use three boot loaders: GRUB, GRUB2, and LILO. GRUB2 is the latest and the most widely used compared to other older programs of its kind.

GRUB2

The full name of GRUB2 is GRand Unified BootLoader,Version 2 (the second edition of the unified boot loader). It is the main boot loader for most popular Linux distributions. GRUB2 is an intelligent program for computers to find the operating system kernel and load it into memory. Since the word GRUB is easier to write and read than GRUB2, below, unless otherwise specified, GRUB will refer to GRUB2.

GRUB is designed to be compatible with the operating system multi-boot specification, which can be used to boot different versions of Linux and other open source operating systems; it can also chain load the boot records of proprietary operating systems.

GRUB allows users to boot from one of several different kernels in any given Linux distribution. This feature enables the operating system to boot to a previous version of the kernel if the upgrade fails due to incompatibility of key software or for some other reason. GRUB can be configured through the file / boot/grub/grub.conf. (LCTT translation note: here refers to GRUB1)

GRUB1 has been gradually deprecated and has been replaced by GRUB2 in most modern distributions, and GRUB2 is rewritten on the basis of GRUB1. Red Hat-based distributions were upgraded to GRUB2 around Fedora 15 and CentOS/RHEL 7. GRUB2 provides the same boot functionality as GRUB1, but GRUB2 is also a command-line-based pre-operating system (Pre-OS) environment similar to the main framework (mainframe) system, making it easier to configure and operate during the pre-boot phase. GRUB2 is configured through / boot/grub2/grub.cfg.

The primary role of both GRUB is to load the kernel into memory and run it. The basic working mode of the two versions of GRUB is the same, and the main phases remain the same, which can be divided into three phases. In this paper, we will take GRUB2 as an example to discuss its working process. The configuration of GRUB or GRUB2, and the command usage of GRUB2 are beyond the scope of this article and will not be covered in this article.

Although GRUB2 does not formally use these phase stage terms in its three boot phases, we use them in this article for the sake of discussion.

Stage 1

As mentioned above in the POST (Power-on self-Test) phase, at the end of the POST phase, BIOS will look for the boot record on the accessed disk, which is usually located in MBR (the master boot record Master Boot Record). It loads the first boot record it finds into memory and starts executing this code. The boot code (and stage 1 code) must be very small because it must be placed in the first 512-byte sector of the hard disk together with the partition table. In a traditional regular MBR, the boot code actually takes up 446 bytes of space. The 446-byte file of this stage 1 is usually called the boot image (boot.img), which does not contain the partition information for the device, and the partition is generally added separately to the boot record.

Because the boot record must be very small, it cannot be very smart and cannot understand the file system structure. So the only function of phase 1 is to locate and load the code for phase 1.5. To accomplish this task, the code for phase 1.5 must be located between the boot record and the first partition of the device. After loading phase 1.5 code into memory, control is transferred from phase 1 to phase 1.5.

Stage 1.5

As mentioned above, the code for phase 1.5 must be located between the boot record and the first partition of the device. The space is free for historical technical reasons. The first partition starts with 62 512-byte sectors (31744 bytes in total) left between sector 63 and MBR (sector 0), which is used to store phase 1.5 code mirrored core.img files. The file size is 25389 bytes, so there is enough space in the area to store core.img.

Because there is more storage space for phase 1.5, and enough space to accommodate some general file system drivers, such as standard EXT and other Linux file systems, such as FAT and NTFS, and so on. GRUB2's core.img is far more complex and powerful than the older GRUB1 phase 1.5. This means that Phase 2 of GRUB2 can be placed in the standard EXT file system, but not in logical volumes. Therefore, phase 2 files can be stored in the / boot file system, usually in the / boot/grub2 directory.

Note that the / boot directory must be placed on a file system supported by GRUB (not all file systems are available). The function of stage 1.5 is to start executing the driver of the / boot file system where the phase 2 files are stored, and load the relevant drivers.

Stage 2

All the files in GRUB phase 2 are stored in the / boot/grub2 directory and several subdirectories. This phase does not have a mirror file similar to phase 1 and phase 1.5. Accordingly, this phase mainly requires loading some kernel runtime modules from the / boot/grub2/i386-pc directory.

The main function of GRUB phase 2 is to locate and load the Linux kernel into memory and transfer control to the kernel. Kernel-related files are located in the / boot directory, and these kernel files can be identified by their filenames, all with the prefix vmlinuz. You can list the contents of the / boot directory to see which kernels are currently installed in the operating system.

GRUB2, like GRUB1, supports booting from one of the Linux kernels of choice. The Red Hat package Manager (DNF) supports the retention of multiple kernel versions in case the latest version of the kernel fails to start, and the older version of the kernel can be restored. By default, GRUB provides a preboot menu for the installed kernel, including the problem diagnosis menu (recuse) and the recovery menu (if the configuration has already set the recovery image).

Phase 2 loads the selected kernel into memory and transfers control to the kernel code.

Kernel

Kernel files are stored in a self-extracting compressed format to save space, along with an initialized memory image and storage device mapping table stored in the / boot directory.

After the selected kernel is loaded into memory and starts execution, the kernel file must first extract itself from the compressed format before it can do any work. Once the kernel self-extracting is complete, load the systemd process (which is a replacement for the init program for older System V systems) and transfer control to systemd.

This is the end of the boot process. At the moment, the Linux kernel and systemd are running, but because there are no other programs executing, they cannot perform any functional tasks related to the user.

Startup process

The boot process immediately follows the boot process, which makes the Linux system operable and capable of performing user functional tasks.

Systemd

Systemd is the parent of all processes. It is responsible for bringing the Linux host to a user-operable state (which can perform functional tasks). Some of the functions of systemd are much richer than the old init programs, and it can manage many aspects of the running Linux host, including mounting the file system and opening and managing the system services of the Linux host. However, any features of systemd that have nothing to do with the system startup process are beyond the scope of this article.

First, systemd mounts the file system configured in / etc/fstab, including memory swap files or partitions. Accordingly, systemd must be able to access the configuration files located in the / etc directory, including its own. Systemd uses its configuration file / etc/systemd/system/default.target to determine which state (or target state target) the Linux system should boot up to. Default.target is a symbolic link to a real target file. For desktop systems, it links to graphical.target, which is the equivalent of runlevel 5 in the old systemV init way. For a server operating system, default.target is more of a default link to multi-user.target, which is equivalent to runlevel 3 of a systemV system. Emergency.target is equivalent to single-user mode.

LCTT translation note: "target" is a new concept introduced by systemd. At present, it has not been found that there is an official exact translation. Considering its function and the context in which it is used, we think that it is more appropriate to translate it into the "target state". And, "unit" refers to each object / file in systemd, such as service and target state, which is translated as "unit" according to the context. )

Note that all target target and service service are unit unit of systemd.

Table 1 below is a comparison between the target state target launched by systemd and the old systemV init startup runlevel runlevel. This systemd target state alias is provided for systemd forward compatibility with systemV. This target alias allows system administrators (including myself) to change the run level with systemV commands (such as init 3). Of course, the systemV command is forwarded to systemd for interpretation and execution.

Table 1 comparison of run levels of older versions of systemV with systemd and target-state target or target-state aliases

Each target state target has a dependency set described in its configuration file. Systemd needs to start its required dependencies first. These dependent services are required by the Linux host to run at a specific functional level. When all dependent services in the configuration file are loaded and running, the system is running at that target level.

Systemd also checks to see if the relevant startup files exist in the old systemV init directory, and if so, systemd starts the corresponding service based on the contents of these configuration files. In the Fedora system, the outdated network service is an example of starting in this way.

Figure 1 below is copied directly from the man page of bootup. It shows the general sequence of events during systemd startup and the basic sequence requirements to ensure a successful startup.

The target state of sysinit.target and basic.target can be regarded as a state checkpoint during startup. Although systemd is originally designed to start system services in parallel, part of the service or functional target state is the premise of starting other services or target state. The system will pause at the checkpoint until its required service and target state are met.

The arrival of the sysinit.target state is based on the premise that all the resource modules it depends on start up normally, and all other units, such as file system mount, swap file setup, device manager startup, random number generator seed setting, low-level system service initialization, encryption and decryption service startup (if one or more file systems are encrypted), must be completed. But in sysinit.target, these services and modules can be started in parallel.

Sysinit.target starts all the low-level services and the units needed for the initial functioning of the system, which are necessary prerequisites for moving on to the next phase of basic.target.

Figure the startup process of 1:systemd

After the conditions for sysinit.target are met, systemd then launches basic.target, starting all the units it requires. Basic.target provides more functionality by starting the units needed for the next target state, including directory paths to various executables, communication sockets, timers, and so on.

Finally, the user-level target state (multi-user.target or graphical.target) can be initialized, and it should be noted that the multi-user.target must be reached before meeting the dependencies of the graphical target state graphical.target.

In figure 1, the target state that starts with * is the general startup state. When one of the target states is reached, it means that the system has been started. If multi-user.target is the default target state, the successfully started system will be presented to the user as a command line login interface. If graphical.target is the default target state, the system that starts successfully will be presented to the user as a graphical login interface, depending on the display manager configured by the system.

Fault discussion

Recently I need to change the default boot kernel of a Linux computer that uses GRUB2. I found that some GRUB2 commands didn't work on my system, or maybe I used them incorrectly. So far, I still do not know what caused it, and this problem needs to be further explored.

The grub2-set-default command failed to set the default kernel index in the configuration file / etc/default/grub so that the expected replacement kernel was not booted. So I manually changed GRUB_DEFAULT=saved to GRUB_DEFAULT=2,2 in this configuration file is the index of the installed kernel file that I need to boot. Then I executed the command grub2-mkconfig > / boot/grub2/grub.cfg to create a new GRUB configuration file, which circumvented the problem as expected and successfully booted the alternative kernel.

Conclusion

GRUB2 and systemd initialization systems are key components for booting and launching most modern Linux distributions. Although in practice, the use of systemd is still controversial, GRUB2 and systemd can work closely together to load the kernel and then start the system services required by a business system.

Although both GRUB2 and systemd are more complex than their predecessors, they are easier to learn and manage. There are a lot of help notes on systemd on the man page.

The original text is from: https://www.linuxprobe.com/boot-process-details.html

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.