Linux basic study notes-boot process, module management and Loader

Boot process, module management and Loader

1. Analysis of Linux boot process

1.1 Overview of the boot process

The system boot process can be summarized as follows:

1. Load the hardware information of BIOS and perform self-test, and obtain the first bootable device according to the setting;
2. Read and execute the boot loader of MBR in the first boot device (that is, programs such as grub2, spfdisk);
3. Load the Kernel according to the boot loader setting, and the Kernel will start to detect the hardware and load the driver;
4. After the hardware drive is successful, Kernel will actively call the systemd program and start it with the default.target process;
   • systemd executes sysinit.target to initialize the system and basic.target to prepare the operating system;
   • systemd executes local and server services under multi-user.target;
   • systemd executes the /etc/rc.d/rc.loacl file under multi-user.target;
   • systemd executes getty.target and login service under multi-user.target;
   • systemd performs services required by graphical.

1.2. BIOS, boot loader and kernel loading

Let's first explain the proper nouns:

• BIOS: Both traditional BIOS and UEFI BIOS will be referred to as BIOS for short;
• MBR: Although the partition table consists of the traditional MBR and the new GPT, GPT also reserves some MBR-compatible blocks. Therefore, the instructions below are referred to as MBR for the installation of the boot loader. In short, MBR represents the first block of the disk where the boot loader can be installed .

1.2.1, BIOS, boot self-test and MBR/GPT

Under the personal computer architecture, if you want to start the entire system , you must first let the system load the BIOS, and load the CMOS information through the BIOS, and obtain the hardware configuration of the host from the settings in the CMOS , such as the CPU Frequency of communication with interface devices, search sequence of boot devices, hard disk size and type, system time, etc.

After obtaining this information, the BIOS will also perform a power-on self-test (POST) . Then start to perform the initialization of the hardware detection, and set the PnP device, and then define the bootable device sequence, and then start to read the data of the boot device .

Because our system software is mostly placed in the hard disk! So the BIOS will specify the boot device so that we can read the operating system kernel in the disk. But because different operating systems have different file system formats, we must use a boot management program to handle the kernel file loading problem, so this boot management program is called Boot Loader . Where is this Boot Loader installed ? It is in the first sector of the boot device, which is what we have always said MBR (Master Boot Partition) .

Since the kernel file needs Loader to read, the Loader of each operating system is different. In this case, how does the BIOS read the Loader in the MBR? In fact, the BIOS reads the MBR through the hardware INT 13 interrupt function . That is to say, as long as the BIOS can detect your disk (whether the disk is a SATA or SAS interface), then it has a way to pass the INT 13 channel To read the MBR software in the first sector of the disk.

1.2.2, Boot Loader function

I just mentioned that the main function of Loader is to recognize the file format of the operating system and load it into the memory for execution accordingly . Because the file formats of different operating systems are inconsistent, each operating system has its own Boot Loader, and only with its own Boot Loader can you load your own kernel files ! So the question is, you should have heard of multiple systems, right? That is, multiple different operating systems are installed on a host. Since ( 1) you must use your own Loader to load your own operating system kernel, and (2) there is only one MBR, then how can you have a single host? How about installing multiple systems at the same time ?

It is necessary to recall the function of the file system. In fact, every file system will reserve a boot sector to provide the operating system to install the Boot Loader , and usually the operating system will install a copy of Loader to the Boot Loader of the file system where its root directory is located by default . If we install Windows and Linux on one of our hosts, the correlation between the Boot Sector, Boot Loader and MBR is as follows:

As shown in the figure above, each operating system will install a set of Boot Loader into its own file system by default (that is, the box in the lower left corner of each filesystem), and when installing a Linux system, you can choose to install the Boot Loader to Go to MBR, you can also choose not to install . If you choose to install to MBR, then in theory you will keep a copy of the Boot Loader program in both MBR and Boot Sector. As for Windows installation, it will automatically install a Boot Loader on both MBR and Boot Sector by default ! So you will find that when installing multiple operating systems, your MBR is often overwritten by the Boot Loader of different operating systems .

The problem we just mentioned has not been solved yet! Although each operating system can install a Boot Loader into their Boot Sector, the operating system can load the kernel through its own Boot Loader . The problem is that there is only one MBR in the system. How do you execute the Loader in the Boot Loader ? This requires understanding the main functions of Boot Loader :

• Provide menu : users can choose different boot items, which is also an important function of multi-boot!
• Load the kernel file : directly point to the bootable program section to start the operating system;
• Transfer to other Loaders : transfer the boot management function to other Loaders for management.

Due to the menu function, we can choose a different kernel to boot. And because of the control transfer function, so we can load Loader in other Boot Sector ! However, the Windows Loader does not have the control transfer function by default, so you cannot use the Windows Loader to load the Linux Loader .

As shown in the figure above, my MBR uses Linux's grub2 boot management program, and it is assumed that there are already three menus, the first menu can directly point to the Linux kernel file and load the kernel directly to boot; the second menu can Give the boot management control to Windows. At this time, the Windows Loader will take over the boot process. At this time, it can start Windows. The third menu is to use the boot management program of Linux in the Boot Loader. At this time, another grub2 menu will pop up:

• Single choice: MBR (grub2) → kernel file → booting
• Menu 2: MBR (grub2) → Boot Sector (Windows Loader) → Windows kernel → booting
• Menu 3: MBR (grub2) → Boot Sector (grub2) → booting

1.2.3, load the kernel to detect hardware and initramfs function

When we start to read the kernel file under the management of Boot Loader, then Linux will compress the kernel file into memory, and use the function of the kernel to start testing and driving various peripheral devices , including storage devices, CPU, Network card, sound card, etc. At this time, the Linux kernel will re-detect the hardware with its own functions, and not necessarily use the hardware information detected by the BIOS. In other words, the kernel officially took over the work of the BIOS. So where are the core files generally stored? Generally speaking, it will be placed in /boot and named /boot/vmlinuz .

[root@li ~]# ls  --format=single-column -F /boot
config-3.10.0-1127.el7.x86_64		#此版本内核被编译时选择的功能与模块配置文件
efi/		
grub/		#旧版的
grub2/		#就是开机管理程序 grub2 相关数据目录
initramfs-0-rescue-1b1f29b2be3d4dafbdcac2da7f5a3c15.img		#底下是虚拟文件系统文件！
initramfs-3.10.0-1127.el7.x86_64.img
symvers-3.10.0-1127.el7.x86_64.gz
System.map-3.10.0-1127.el7.x86_64
vmlinuz-0-rescue-1b1f29b2be3d4dafbdcac2da7f5a3c15*
vmlinuz-3.10.0-1127.el7.x86_64*		#内核文件。最重要的文件！

For the convenience of hardware developers and other kernel function developers, the Linux kernel can dynamically load kernel modules , which are usually placed in the /lib/modules directory . Since the module is placed in the root directory of the disk ( remember that /lib cannot be placed in a separate partition from / !), it must be hung in the root directory during the boot process, so that the kernel module provides the driver function . And to worry about affecting the file system in the disk, the root directory is mounted read-only during the boot process .

The virtual file system generally uses the file name /boot/initrd or /boot/initramfs. The feature of this file is that it can be loaded into the memory through the Boot Loader, and then the file will be compressed and simulated as a root directory in the memory. And this simulated file system in the memory can provide an executable program through which to load the most needed kernel modules during the boot process, usually these modules are USB, RAID, LVM, SCSI and other file systems and disk interfaces Driver . Wait for the help kernel to call systemd again to start the subsequent normal boot process:

As shown in the figure above, Boot Loader can load kernel and initramfs, and then decompress the initramfs in the memory called the root directory, the kernel can load the appropriate driver from this, finally release the virtual file system, and mount the actual root directory The file system can start the subsequent normal boot process.

After the kernel is fully loaded, your host should start to operate correctly. Next, you must start executing the first program of the system: systemd !

1.3, the first program systemd and use default.target to enter the boot program analysis

After the kernel is loaded, hardware detection and driver loading are complete, your host hardware should be ready at this time. At this time, the kernel will actively call the first program, which is systemd. This is why when you use the pstree -p command, you will find that the PID number of systemd is 1 . The main function of systemd is to prepare the environment for software execution, including the host name of the system, network settings, language processing, file system format, and the startup of other services . All actions will be planned through systemd's default startup service set, namely /etc/systemd/system/default.target . In addition, systemd has abandoned the runlevel that has been used for many years.

1.3.1、Common operating environment target and compatibility and runlevel level

The main items that can be used as the preset operating environment are: multi-user.target and graphical.target. Of course, there are more special operating environments, including rescue.target, shutdown.target, emergency.target, etc., and initrd.target.

However, in the past, systemV used a concept called runlevel to start the system. In order to be compatible with the old-style systemV operation behavior, systemd combines runlevel with the operating environment.

SystemV	system
init 0	systemctl poweroff
init 1	systemctl rescue
init [234]	systemctl isolate multi-user.target
init 5	systemctl isolate graphical.target
init 6	systemctl reboot

1.3.2, systemd processing flow

After we get the default operation interface of /etc/systemd/system/default.target, what will the system do for us next? First, it will link to the /usr/lib/systemd/system/ directory to obtain one of multi-user.target or graphical.target. Assuming that we are using graphical.target, then systemd will look for settings in two places, which are the following directories:

• /etc/systemd/system/graphic.target.wants/：Users set the loaded unit
• /usr/lib/systemd/system/graphical.target.wants/ : unit loaded by default

Then the following content is found in the configuration file /usr/lib/systemd/system/graphical.target:

[root@li ~]# cat /usr/lib/systemd/system/graphical.target
[Unit]
Description=Graphical Interface
Documentation=man:systemd.special(7)
Requires=multi-user.target		#必须先加载 multi-user.target 
Wants=display-manager.service	#启动完 graphical.target 之后，还必须启动 display-manager.service
Conflicts=rescue.service rescue.target
After=multi-user.target rescue.service rescue.target display-manager.service
AllowIsolate=yes

[root@li ~]# cat /usr/lib/systemd/system/multi-user.target
[Unit]
Description=Multi-User System
Documentation=man:systemd.special(7)
Requires=basic.target		#必须先加载 basic.target
Conflicts=rescue.service rescue.target
After=basic.target rescue.service rescue.target
AllowIsolate=yes

What units are loaded by the system by default?

[root@li ~]# ls /usr/lib/systemd/system/multi-user.target.wants/
dbus.service           plymouth-quit-wait.service      systemd-update-utmp-runlevel.service
getty.target           systemd-ask-password-wall.path  systemd-user-sessions.service
plymouth-quit.service  systemd-logind.service

What are the user-defined units?

[root@li ~]# ls /etc/systemd/system/multi-user.target.wants/
auditd.service      kdump.service           rhel-configure.service  vmtoolsd.service
crond.service       NetworkManager.service  rsyslog.service
firewalld.service   postfix.service         sshd.service
irqbalance.service  remote-fs.target        tuned.service

In fact, the easiest way to know the service startup process of the system is the systemctl list-dependencies graphical.target command . However, if you want to know the meaning of the configuration file behind it, you have to find out the data in the graphical.target.wants/ directory under /etc and /usr/lib respectively! Of course, the service represented by the value of Requires in the configuration file also needs to be loaded first.

1.3.3, systemd starts services under multi-user.target

After the kernel driver hardware is loaded, the system can be accessed through the initialization process of sysinit.target, and basic.target is added to make the system the basis of the operating system, and then the various host services needed for the server to run smoothly And the start of the network service that provides the server function. The startup of these services is mostly attached to the multi-user.target operating environment. You can go to /etc/systemd/system/multi-user.target.wants/ to see the default startup services. In other words, generally speaking, the service startup script settings are placed in the following directory :

• /usr/lib/systemd/system: system default service startup script setting
• /etc/systemd/syetem: startup script developed and set by the administrator

If the user wants to enbale the local services of the host and the various units of the server network service, put it in the /etc/systemd/system/multi-user.target.wants/ directory and make a link. It can be started automatically when booting .

[root@li lib]# systemctl enable vsftpd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/vsftpd.service to /usr/lib/systemd/system/vsftpd.service.
[root@li lib]# systemctl disable vsftpd.service
Removed symlink /etc/systemd/system/multi-user.target.wants/vsftpd.service.

1.3.4, compatible systemV rc-local.service

Users who have used Linux in the past probably know that after the system is booted, if you want the system to execute some additional programs , you can write the absolute path name of the program instruction or script to /etc/rc.s/rc .local to this file. In the new systemd mechanism, it is recommended to write a systemd startup script configuration file directly to /etc/systemd/system, and then use the systemctl enable method to set and start it, instead of directly using the rc.local file!

Is there a compatible method for the new version of systemd? Of course there is, that is the function of the rc-local.service service. This service does not need to be started, it will determine whether /etc/rc.d/rc.local has executable permissions to determine whether to start this service.

#1、先看一下 /etc/rc.d/rc.local 的权限，然后检查一下 multi-user.target 有没有这个服务
[root@li lib]# ll /etc/rc.d/rc.local
-rw-r--r--. 1 root root 473 8月   7 01:30 /etc/rc.d/rc.local

[root@li lib]# systemctl status rc-local.service
● rc-local.service - /etc/rc.d/rc.local Compatibility
   Loaded: loaded (/usr/lib/systemd/system/rc-local.service; static; vendor preset: disabled)
   Active: inactive (dead)
[root@li lib]# systemctl list-dependencies multi-user.target | grep rc-local
#明明就有这个服务，但是 rc.local 不具有执行的权限，因此这个服务不会被执行

#2、加入 x 权限后，再看一下 rc-local 是否可被执行
[root@li lib]# chmod a+x /etc/rc.d/rc.local; ll /etc/rc.d/rc.local
-rwxr-xr-x. 1 root root 473 8月   7 01:30 /etc/rc.d/rc.local
[root@li lib]# systemctl daemon-reload
[root@li lib]# systemctl list-dependencies multi-user.target | grep rc-local
● ├─rc-local.service		#这个服务确实被记录到启动的环境下了

By chmod a+x /etc/rc.d/rc.local, many of your scripts can be placed in the file /etc/rc.d/rc.local, and the system will execute the files in this file every time the system boots instruction.

1.3.5. Main configuration files used in the boot process

Basically, systemd has its own configuration file processing method, but in order to be compatible with systemV, many script settings still read the environment configuration file located under /etc/sysconfig/. Common configuration files:

• About modules: /etc/modprode.d/ .conf and /etc/modules-load.d/ .conf

  In fact, there are two places to deal with the problem of loading modules:

  • /etc/modprode.d/*.conf: Simply want the location of the kernel to load the module;
  • /etc/modules-load.d/*.conf: The location of module parameters can be added.

• /etc/sysconfig/*

  • authconfig

    This file is mainly used to regulate the user's identity authentication mechanism, including whether to use the local /etc/passwd, /etc/shadow, etc., and what algorithm encryption is used for /etc/shadow password records.

  • cpupower

    This file will be read when the cpupower.service service is started.

  • firewalld，iptables-config，etables-config

    Parameters related to firewall

  • network-scripts/

The file mainly regulates the user's identity authentication mechanism, including whether to use the local /etc/passwd, /etc/shadow, etc., and which algorithm to encrypt the /etc/shadow password record.

• cpupower

  This file will be read when the cpupower.service service is started.

• firewalld，iptables-config，etables-config

  Parameters related to firewall

• network-scripts/

  Network card setting parameters