Linux Kernel Startup Process)

Startup Process Overview

Since it is very serious to start, let's take a look at the entire startup process! So that you can easily find out where problems may occur during the startup process, as well as the solutions to the problems! However, during the startup process, the startup managementProgramThe software used by (Boot Loader) may be different. For example, grub is currently the mainstream of the major Linux distributions, but lilo is used by default in early Linux. However, in any case, we always have to understand the operating status of the entire boot loader, so that we can understand the reason why we need to install windows before installing Linux ~

Assume that the Linux host set up on a PC is used as an example. When you press the power button, the computer hardware will actively read the BIOS to load hardware information and perform hardware system self-testing, then the system will actively read the first device that can be started (configured by BIOS), and then you can read the start management program.

The start management program can specify the core file to be used for startup, and load the core to the memory for decompression and operation. At this time, the core can start activity in the memory, detects all hardware information and loads appropriate drivers to run the entire host.After the core detection hardware and the loaded driver are complete, an operating system in the most Yang spring will start to run on your PC..

After the host system starts running, Linux calls an external program to prepare the environment for running the software, and loads all the software programs required for running the system! Finally, the system will start waiting for your login and operations! Simply put, the process of system startup can be merged into the following process:

1. Load BIOS hardware information and perform self-testing, and obtain the first device that can be started according to the configuration;
2. Read and run the Boot Loader (grub, spfdisk, and other programs) of MBR in the first startup device );
3. Based on the boot loader configuration, the kernel starts to detect the hardware and load the driver;

Bios, enable self-testing and MBR

In a personal computer architecture, to start the entire system, you must first let the system load the BIOS (Basic Input Output System) and load the CMOS information through the BIOS program, the hardware configurations of the host are obtained by using the configuration values in CMOS, for example, the communication between the CPU and peripheral devices, 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 devices), I/O addresses of peripheral devices, and IRQ disconnections with CPU.

After obtaining this information, the BIOS will also start the self-test (post ). Then start hardware detection initialization, configure the PNP device, and then define the device sequence that can be started, next we will start reading data from the Startup Device (MBr-related task starts ).

Most of our system software is stored on the hard disk! So the BIOS will specify the boot device so that we can read the operating system core files on the disk. However, because different operating systems have different file system formats, we must start a hypervisor to handle core file loading issues.Start the management program is called boot loader. Where is the boot loader installed? In the first magnetic zone (sector) of the boot device, that is, the MBR (Master Boot Record, main startup record area) We have been talking about).

Do you think it is strange? Since the core file needs to be read by loader, the loader in each operating system is different. In this case, how does the BIOS read the loader in MBR? Interesting question! In fact, BIOS reads MBR through the INT 13 interrupt function of the hardware, that is, as long as the BIOS can detect your disk (whether the disk is SATA or IDE Interface ), then he can read the MBR in the first magnetic zone of the disk through the channel INT 13! In this way, the boot loader can be run!

We know that each hard disk's first MBR region contains 446 bytes, so if there are two hard disks on my host, which hard disk does the system go to the MBR to read the boot loader? This depends on the BIOS configuration. Basically, we often talk about the system MBR, which actually refers to the MBR of the first startup device! Therefore, if you want to install the Boot manager to an MBR on a hard disk in another day, pay special attention to the "first boot device" of the system at that time, otherwise, the MBR will be installed on the wrong hard disk!

Boot Loader

The main function of loader is to understand the file format of the operating system and load the core to the main memory for running. Because different operating systems have different file formats, each operating system has its own boot loader! You can use your own loader to load core files! That's the problem. Have you heard of multiple operating systems? That is, multiple operating systems are installed on a host. Since you(1) You must use your own loader to load the core of your operating system. (2) there is only one MBR of the system, how can you install Windows and Linux on a host at the same time?

In fact, each file system (filesystem, or partition) will retain a boot sector to provide the operating system to Install Boot Loader, by default, the operating system installs a loader to the Boot Sector of the file system in which the root directory is located. If we install Windows and Linux on a host, the correlation between the Boot Sector, boot loader, and MBR will be a bit like:

Figure 1.2.1. Relationship between boot loader and operating system installed in MBR

As shown in, by default, each operating system installs a boot loader to its own file system (that is, the box in the lower left corner of each filesystem, you can install the boot loader to MBR or choose not to install it. If you choose to install MBR, theoretically you will have a boot loader program in MBR and Boot Sector. When Windows is installed, the MBR and boot sector are automatically installed with a boot loader by default! So, you will find that when multiple operating systems are installed, your MBR is often overwritten by Boot Loader of different operating systems! Pai_^

The two problems we just mentioned are still unsolved! Although each operating system can install a boot loader to their boot sector, the operating system can load the core through its own boot loader. The problem is that there is only one MBR in the system! How do you run the loader in the boot sector?

The main functions of Boot Loader are as follows:

• Menu provided: Users can select different startup projects, which is also an important feature of multiple startup!
• Load core files: Directly point to the executable program section to start the operating system;
• Transfer another Loader: Transfers the startup management function to other loaders.

Because of the menu function, we can choose different cores to start. Due to the function of transferring control, we can load the loader in other boot sector! However, by default, Windows loader does not have the control transfer function. Therefore, you cannot use Windows loader to load Linux Loader! This is why when we talk about MBR and multi-boot in Chapter 3, we will particularly emphasize installing windows and then Linux. Let's explain the above three functions in the following illustration! (Similar to the illustration in Chapter 3 !)

Figure 1.2.2 start the menu function of the hypervisor and Control Transfer Function

As shown in, my MBR starts the hypervisor using grub in Linux and assumes that there are three menus in it, the first menu can direct to the Linux core file and directly load the core to start. The second menu can control the startup management program to Windows for management. At this time, the Windows loader will take over the startup process, in this case, he can start Windows. The third menu is to start the Management Program in the boot sector of Linux. At this time, it will jump out of another GRUB menu! Do you understand?

The final function of the boot loader is 『Load the Kernel File!

 

Load core detection hardware and initrd

after we start to read the core file through the management of boot loader, Linux will decompress the core to the main memory, the core functions are used to test and drive various peripheral devices, including storage devices, CPU, network cards, and sound cards. In this case, the Linux core uses its own functions to re-detect the hardware, rather than using the hardware information detected by the BIOS! That is to say, the core is now taking over the BIOS . So where is the core file? Generally, it will be placed in/boot and named/boot/vmlinuz!

 [root @ WWW ~] #  ls  -- format = single-column-F/ bootconfig - 2.6 .  18 - 92 . EL5 <=  grub /<=  is to start the grub-related data directory initrd - 2.6 .  18 - 92 . el5.img <=  Virtual File System File! System. map - 2.6 .  18 - 92 . EL5 <=  table vmlinuz - 2.6 .  18 - 92 . EL5 <= is the core file! The most important one! 

From the above table, we can also know that the Linux kernel of this version is 2.6.18-92. EL5! For the convenience of hardware developers and other core function developers, the Linux core can dynamically load the core modules (think of it as a driver ), these core modules are placed in the/lib/modules/directory.Because the module is placed in the root directory of the disk (remember that/lib cannot be placed with/in different partitions !), Therefore, during startup, the core must be mounted to the root directory to read the core module and provide the driver loading function.To avoid affecting the file system on the disk, the root directory is mounted in read-only mode during startup.

In general, non-essential functions can be compiled into the core functions of the module. Currently, Linux distributions will compile it into a module. ThereforeDrive programs for disk devices such as USB flash drives, Sata disks, and SCSI disks usually exist as modules.. Now, let's take a look at the situation. If your Linux is installed on a SATA disk, you can get the boot loader and the kernel file through INT 13 in the BIOS to start it, then, the kernel starts to take over the system and detects the hardware and tries to mount the root directory to obtain additional drivers.

 

The problem is,The core does not know the SATA disk, so the driver of the SATA disk needs to be loaded. Otherwise, the root directory cannot be mounted. However, if the SATA driver is in/lib/modules, you cannot mount the root directory. How can you read the driver in/lib/modules?Right! A dilemma! In this case, your Linux cannot be started smoothly! What should we do? It doesn't matter. We can solve this problem through the Virtual File System.

Initial RAM disk is generally named/boot/initrd.This file is also capable of being loaded to the memory through the boot loader. Then the file will be decompressed and simulated into a root directory in the memory, in addition, the file system in the simulated memory can provide a program that can run.Load the core modules required during startup. These modules are generally the drivers of the file system and disk interface, such as USB flash drives, raid, LVM, and SCSI.! After the loading is complete, the core will call/sbin/init again to start the subsequent normal START process.

As shown in, the boot loader can load the kernel and initrd, and then decompress initrd into the root directory in the memory, so that the kernel can load the appropriate driver and finally release the virtual file system, and mount the actual root directory file system to start the subsequent normal startup process. For more information about initrd, see man initrd. Let's take a look at the content of the initrd file in centos 5.x!

# 1 . First copy/boot/initrd to/tmp/ In the initrd directory, wait for decompression: [root @ WWW ~] # Mkdir /Tmp/Initrd [root @ WWW ~] # CP /Boot/initrd- 2.6 . 18 - 92 . El5.img/tmp/initrd/ [Root @ WWW ~] # Cd/tmp/ Initrd [root @ WWW initrd] #  File Initrd- 2.6 . 18 - 92  . El5.imginitrd - 2.6 .18 - 92 . El5.img: Gzip  Compressed data,... # It turns out to be  Gzip ! Because yes Gzip  So change the extension to. GZ! #  2  . Decompress the above file: [root @ WWW initrd] #  MV Initrd- 2.6 . 18 - 92 . El5.img initrd- 2.6 .18 - 92  .El5.gz [root @ WWW initrd] #  Gzip -D initrd- 2.6 . 18 - 92  .El5.gz [root @ WWW initrd] #  File Initrd- 2.6 . 18 - 92  . El5initrd - 2.6 .18 - 92  . EL5: ASCII cpio archive (svr4 with no CRC) # after a long time, it turns out that cpio commands are compressed into files! Decompress the package! #  3  . Use cpio to decompress [root @ WWW initrd] # cpio -Ivcdu <initrd- 2.6 . 18 - 92  . EL5 [root @ WWW initrd] # lldrwx ------ 2 Root 4096 APR 10   02 :05  Bindrwx ------ 3 Root 4096 APR 10   02 : 05  Devdrwx ------ 2 Root 4096 APR 10   02 : 05  Etc -Rwx ------1 Root 1888 APR 10   02 : 05  Init -RW ------- 1 Root 5408768 APR 10   02 : 00 Initrd- 2.6 . 18 - 92 . El5drwx ------ 3 Root 4096 APR 10   02 : 05  Libdrwx ------ 2 Root 4096 APR 10   02 : 05  Proclrwxrwxrwx  1 Root3 APR 10   02 : 05 Sbin-> Bindrwx ------ 2 Root 4096 APR 10   02 : 05  Sysdrwx ------ 2 Root 4096 APR 10  02 : 05  Sysroot # Check! Is it like the root directory! Especially the init file! Check the permission! # Next, let's take a look at the init file? #  4  . Observe the important running projects in the init file [root @ WWW initrd] #  Cat  Init # ! /Bin/Nash <= Run a shell similar to bash.  Mount -T proc/proc <= Virtual File System with memory mounted... (omitted in the middle )....  Echo  Creating initial device nodes  Mknod /Dev/ Null C 1   3 <= Create various devices required by the system !.... (Omitted in the middle )....  Echo   "  Loading ehci-hcd.ko Module  "  Insmod /Lib/ehci-hcd.ko <= Load the core modules, that is, the driver !.... (Omitted in the middle )....  Echo  Creating root device. mkrootdev -T ext3-O defaults, RO hdc2 <= Try mounting the root directory !.... (Omitted below ).... 

Through the above running file content, we can know that initrd has a loading module and has tried to mount a virtual file system. Then we can run it smoothly! Is it necessary to use initrd?

 
Is it impossible to start smoothly without initrd? A: No! The most important reason for initrd is that when the root directory cannot be mounted at startup, initrd is required. For example, if your root directory is in a special disk interface (USB flash drive, SATA, SCSI), or your file system is special (LVM, raid) and so on, you will need initrd. If your Linux is installed on the disk of the IDE interface and the default ext2The/ext3 file system can be smoothly started into Linux without the need for initrd!
 

After the core is fully loaded, your host should start to run correctly.

 

From http://vbird.dic.ksu.edu.tw/linux_basic/0510osloader_1.php