Linux boot process details
For any system, it is not just a matter of power-on, but many things will happen in a few or dozens of seconds, understanding this complete process will be a prerequisite for solving any boot problems or improving the boot speed. next, let's take a closer look at the Linux boot process:
1. Load BIOS hardware information, perform self-testing, and obtain the first device that can be turned on;
2. read and execute the Boot Loader (such as grub and spfdisk) of MBR in the first Boot device );
3. Load the kernel according to the Boot Loader settings. The kernel starts to detect the hardware and load the driver program;
4. After the hardware driver is successful, the kernel will call the init program, and the init will get the run-level information;
5. Run the/etc/rc. d/rc. sysinit file in init to prepare the environment (such as network and Time Zone) for running the software );
6. init executes run-level service startup (script Mode );
7. Run the/etc/rc. d/rc. local file in init;
8. init executes the terminal simulation program mingetty to start the login program, and the user can log on to it;
Next, we will detail the above steps:
1. Load BIOS hardware information, perform self-testing, and obtain the first device that can be turned on;
On the X86 platform, if you want the system to run, you must first let the system load BOIS and load the CMOS information through the BOIS program. obtain the hardware configurations of the host through the settings in CMOS: for example, the frequency of communication between the CPU and the interface device, the search sequence of the boot device, the size and type of the hard disk, the system time, and whether Plug and Play (PnP
Plug-and-play device), the I/O address of each interface device, and the IRQ interrupt that communicates with the CPU.
Here we need to understand BOIS and CMOS concepts:
BOIS: Basic Input Output System ). its content is integrated into a ROM chip on the motherboard, which stores the most important basic input and output programs of the system, including terminal service programs, system setup programs, boot power-on self-check program and system startup self-lifting program.
CMOS: Complementary Metal Oxide Semiconductor memory (Complementary Metal Oxide semicondu ). it is a read-write RAM chip on the motherboard. It is mainly used to save the hardware configurations of the current system and set certain parameters for the operator (in general, the hardware configuration information of your computer and the parameter settings of your computer are saved ). the cmos ram chip is powered by a back-up battery. Therefore, the CMOS information will not be lost whether it is in the shutdown status or in the case of system power loss. (this is also the principle of discharging and cracking the boot password ^-^)
Contact BOIS and CMOS:
CMOS is the medium for storing the system parameters set by BOIS, And BOIS is the method for modifying CMOS.
Next, we will continue to introduce the above content. After loading the CMOS information in BOIS, we will start to perform self-check on the startup, then we will start to initialize the hardware, set the PnP, and then define the device sequence for the startup, next, read the data from the specified boot device. so far, the first step has been completed.
2. read and execute the Boot Loader (such as grub and spfdisk) of MBR in the first Boot device );
After step 1 is completed, the system starts to read MRB from the first Boot device and runs the Boot Loader. Here, we will briefly explain the MBR and Boot Loader concepts:
MRB: Master Boot Record ). located in the entire hard disk 0 track 0 cylindrical 1 sector. however, in the Master Boot Sector with a total of 512 bytes, MBR only occupies 446 bytes, And the other 64 bytes are handed over to the DPT (Disk Partition Table ), the last two bytes "55, AA" indicate the end of the partition. This constitutes the primary Boot Sector of the hard disk.
Boot Loader: After BOIS specifies the Boot device, we can read the system files on the device. However, the file formats of different operating systems are generally different, therefore, we must use a Boot management program to handle core file loading issues. This Boot Management Program is the Boot Loader. the program is installed in the first sector of the boot device, that is, MBR. that is to say, MBR stores the Boot Loader.
Through the introduction of MBR and Boot Loader, we know that the storage location of Boot Loader is always certain, so when the BIOS recognizes the disk, it can be interrupted by the INT 13 to the specified location, therefore, the Boot Loader program is executed to load the core file of the operating system. so far, the second step has been completed.
3. Load the kernel according to the Boot Loader settings. The kernel starts to detect the hardware and load the driver;
After step 2 is completed, the Boot Loader can load the kernel from the specified disk, extract the kernel to the memory, and use the kernel function to test and drive the hardware device. at the same time, the kernel will detect the hardware again, rather than using the hardware information detected by the BIOS. now, the kernel takes over the BIOS after it is started. here, we need to briefly introduce the Linux kernel.
In Linux, the kernel is stored in the/boot partition and named vmlinuz.
Next, we will introduce that in this step, the kernel will load the driver, but there will be a problem that these drivers are generally stored in the/lib/modules/directory, to identify a disk, the kernel must first load the drive program of the disk, and the drive program of the disk is stored in the disk (/lib/modules), which is in a dilemma, as a result, the system cannot continue to be started. For this problem, the Linux predecessors have come up with a wonderful method-Virtual File System to solve this problem, here we will briefly introduce this virtual file system.
The Virtual File System (Initial RAM Disk) is generally named initrd and stored in the/boot/directory. This file has the following features: it can be loaded to the memory through the Boot Loader, and then the file is decompressed to the memory and simulated as a root directory, the simulation root directory in the memory file system can provide an executable program, through which to load the core modules required during the boot process, usually USB, RAID, LVM, the drivers of file systems and disk interfaces such as SCSI. After loading is complete, the kernel will reload/sbin/init to start the subsequent normal boot process. now, step 3 is complete.
The content of the initrd file is as follows:
Drwxrwxr-x 10 freeman 4096 October 18 14:50. /drwxrwxrwt 16 root 4096 October 18 14:47 .. /drwxr-xr-x 2 freeman 4096 October 18 14:50 bin/drwxr-xr-x 3 freeman 4096 October 18 14:50 conf/drwxr-xr-x 7 freeman 4096 October 18 14:50 etc/ -rwxr-xr-x 1 freeman 7237 October 18 14:50 init *-rw-r -- 1 freeman 51981312 October 18 14:46 initrddrwxr-xr-x 7 freeman 4096 October 18 14:50 lib/ drwxr-xr-x 2 freeman 4096 October 18 14:50 lib64/drwxr-xr-x 2 freeman 4096 October 18 14:50 run/drwxr-xr-x 2 freeman 4096 October 18 14:50 sbin/drwxr -xr-x 7 freeman 4096 14:50 scripts/
Is it like the directory structure of a Linux File System (^-^)
4. After the hardware driver is successful, the kernel will call the init program to initialize the running environment of the software.
After step 3 is completed, the kernel starts to call the init program, which is also the first program in the system. Therefore, the PID is 1. Why should we call this program? Here, we need to know the role of this init program:
The main function of the init program is to prepare the software running environment, including the system Host Name, network settings, language selection, file system format, and startup of other services. all these actions are planned through the init configuration file, that is,/etc/inittab. There is also a very important configuration item in inittab, that is, the default runlevel (BOOT execution level ). therefore, the/etc/inittab file guides the init program to execute specific actions.
Next let's take a look at the content of the/etc/inittab file:
Freeman @ freeman-H55M-S2 :~ $ Cat/etc/inittabid: 3: initdefault: # Set the default running level. init first reads this line to determine the running level. si: sysinit:/etc/rc. d/init. d/rc sysinit # Run/etc/rc. d/init. d/rc. the sysinit script is used to set the host name, mount it to the file system, and start swap partitions. 0: 0: wait:/etc/rc. d/init. d/rc 01: S1: wait:/etc/rc. d/init. d/rc 12: 2: wait:/etc/rc. d/init. d/rc 23: 3: wait:/etc/rc. d/init. d/rc 34: 4: wait:/etc/rc. d/init. d/rc 45: 5: wait:/etc/rc. d/init. d/rc 56: 6: wait:/etc/rc. d/init. d/rc 6 # Corresponds to/etc/rc. d/rc [0-6]. d. # The configuration row arrangement syntax is: # id: runlevels: action: process [argument] # id is the flag field, generally 2 to 4 characters. # runlevel defines the applicable running level of the bank. generally: # running level | description # --------- | -------------------------------------------------------------- #0 | Halt, disable the system. #1 | for a single user, add the parameter single to the kernel during grub startup to enter the running level #2 | no network user mode. #3 | Multi-User Network Mode. #4 | Multi-User Network Mode. #5 | X mode #6 | reboot restart system # S/s | same running level 1 # a, B, c | Custom Level, usually not used. # --------------------------------------------------------------------- # define the action to be taken. # Actions # actions | description # ------------------------------------------------------------------- # respawn | restart a process once it is stopped. # wait | the process runs only once. init will wait until it ends and execute other commands. # once | the process runs only once. # boot | process running in the system boot process. init ignores the running level. # bootwait | during system boot, the process runs and init waits for the process to end. # off | if you do not take any action, the function is equivalent to using this line # comment out. # ondemand | the process runs as long as init calls any running level in a, B, and c. # initdefault | default running level set by the system. the process field is ignored. # sysinit | the process runs as long as the system is booted, and takes precedence over boot and bootwait. # powerwait | when init receives the SIGPWR signal, the process starts to run and generally runs when a power failure occurs. # powerfail | same as powerwait, but init does not wait for the process to complete. # powerokwait | run when the power supply fails to be repaired. # ctrialdel | when init receives the SIGNT signal (Press ctrl + alt + del), the process runs. # kbrequest | the process runs when init receives the KeyboardSignal signal processed by the keyboard. # restart ca: 12345: ctrlaltdel:/sbin/shutdown-t1-a-r now # restart the system when ctrl + alt + del is pressed in the 1-5 running level. su: S016: once:/sbin/sulogin # sulogin will be run under S, 6 levels. # generally, if grub or lilo is used for startup, if the single parameter is added to the kernel, the single-user mode is directly entered without a password. this may cause some security risks. add this line to solve the problem. 1: 2345: respawn:/sbin/agetty-I '\ 033 (k'tty1 96002: 2345: respawn:/sbin/agetty-I' \ 033 (k'tty2 96003: 2345: respawn:/sbin/agetty-I '\ 033 (k'tty3 96004: 2345: respawn:/sbin/agetty-I' \ 033 (k'tty4 96005: 2345: respawn: /sbin/agetty-I '\ 033 (k'tty5 96006: 2345: respawn:/sbin/agetty-I' \ 033 (k'tty6 9600 # set the number of tty consoles, it is generally tty [1-6], and the X Window System runs in tty7
By viewing the content in/etc/inittab, we can clearly understand that init will run/etc/rc. d/rc. the sysinit script is used to prepare the environment for running the software (such as the network and time zone ). so far, step 4 has been completed.
5. init executes run-level service startup (script Mode );
After step 4 is completed, init starts the corresponding service based on the run-level specified in the inittab file. specific services can be viewed based on the script files corresponding to different run-levels,
The script file corresponding to each run-level is described in inittab, as follows:
0:0:wait:/etc/rc.d/init.d/rc 01:S1:wait:/etc/rc.d/init.d/rc 12:2:wait:/etc/rc.d/init.d/rc 23:3:wait:/etc/rc.d/init.d/rc 34:4:wait:/etc/rc.d/init.d/rc 45:5:wait:/etc/rc.d/init.d/rc 56:6:wait:/etc/rc.d/init.d/rc 6
So far, let's take a simple look at the corresponding script file content with run-level 5:
Freeman @ freeman-H55M-S2:/etc/rc5.d $ ls-llrwxrwxrwx 1 root 20 September 20 18:00 S20kerneloops-> .. /init. d/kerneloopslrwxrwxrwx 1 root 15 September 20 18:00 S20rsync-> .. /init. d/rsynclrwxrwxrwx 1 root 27 September 20 18:00 S20speech-dispatcher-> .. /init. d/speech-dispatcherlrwxrwxrwx 1 root 15 September 20 18:00 S50saned-> .. /init. d/sanedlrwxrwxrwx 1 root 19 September 20 18:00 S70dns-clean-> .. /init. d/dns-cleanlrwxrwxrwx 1 root September 20 18:00 S70pppd-dns-> .. /init. d/pppd-dnslrwxrwxrwx 1 root 21 September 20 18:00 S99grub-common-> .. /init. d/grub-commonlrwxrwxrwx 1 root 18 September 20 18:00 S99ondemand-> .. /init. d/ondemandlrwxrwxrwx 1 root 18 September 20 18:00 S99rc. local-> .. /init. d/rc. local
Briefly describe the naming meaning of this file: S indicates Start, K indicates Kill, followed by numbers indicates the running sequence, and the following word is the name of the running program.
So far, step 5 has been completed.
6. Run the/etc/rc. d/rc. local file in init;
After Step 5 is completed, the system can basically be said to have run. For this step, only user tasks before the system starts are executed. Therefore, if you want, do some work,
Then you can move your hands and feet in the rc. local file.
7. init executes the terminal simulation program mingetty to start the login program, and the user can log on to it;
After step 6 is completed, the services required for system contraction have been started. Next, Linux will start the terminal or X Window. Now, the entire system boot process is completed.
References:
Laruence's private kitchen (Third edition)
Differences between BIOS and CMOS
/Etc/inittab File Analysis
