Linux kernel boot process [go]

launch Process at a glance

Since start-up is a serious thing, let's take a look at the whole start-up process. To make it easier for everyone to find out where problems may occur during the startup process, and how to resolve them after the problem has occurred! However, due to the startup process, the Boot manager program (boot Loader) uses the software may be different, such as the current major Linux distributions mainstream for grub, but early Linux by default is the use of LILO. However, we always have to understand the entire boot loader work, to understand why the multi-boot configuration, always listen to the first installation of Windows and then install Linux reasons ~

Assuming that a personal computer set up a Linux host, for example, when you press the power button, the computer hardware will actively read the BIOS to load hardware information and hardware system self-test, then the system will actively read the first bootable device (configured by the BIOS), at which point you can read into the startup management program.

The startup manager can specify which core file to use to start, and actually load the core into memory to decompress and run, at which point the core can start to operate in memory, and detect all hardware information and load the appropriate driver to enable the entire host to start running, wait until the core detection hardware and load the driver is finished, One of the most Yangchun operating systems started running on your PC.

After the host system is running, Linux will call the external program to start preparing the software to run the environment, and actually load all the software programs needed to run the system! Finally, the system will begin to wait for your landing and operation! Simply put, the system can be started by the process of integration into the bottom of the flow:

1. Load BIOS hardware information and self-test, and obtain the first bootable device according to the configuration;
2. Read and run the boot Loader (i.e. grub, spfdisk, etc.) of the MBR in the first boot device;
3. Based on the configuration of boot loader loading Kernel, Kernel will start to detect hardware and load drivers;

BIOS, starting self-test with MBR

In the PC architecture, you want to start the whole system first you have to let the system load the BIOS (Basic Input Output System), and through the BIOS program to load the CMOS information, and through the CMOS configuration values to obtain the host hardware configuration, such as CPU Communication with peripheral equipment, the search order of the start-up device, the size and type of the hard disk, the system time ah, the peripheral bus is started Plug and Play (PnP, plug-and-use device) Ah, the peripheral device I/O address, and the CPU communication with the IRQ fork and so on information 。

After obtaining this information, the BIOS will also initiate self-test (power-on, Post). Then start the initialization of hardware detection and configure the PnP device, then define the sequence of the devices that can be started, then start the data reading of the boot unit (MBR related tasks start).

Because most of our system software is placed on the hard drive! So the BIOS will specify the device to boot so that we can read the operating system core files in the disk. But because of different operating systems his file system format is not the same, so we have to use a boot manager to handle the core file load (load) problem, so this boot manager is called Boot Loader. So where is this Boot Loader program installed? In the first magnetic region (sector) of the starting device, which is the MBR (master boot record, the main boot record area) We have been talking about.

So you don't think it's weird? Since the core files need loader to read, the loader of each operating system is different, so how does the BIOS read the loader inside the MBR? It's a very interesting question! In fact, the BIOS is through the hardware of the INT 13 interrupt function to read the MBR, that is, as long as the BIOS can detect your disk (whether the disk is SATA or IDE interface), then he has a way to read the first magnetic region of the disk through the INT 13 channel MBR Now! This way the boot loader will be able to be run ROM!

We know that the first magnetic region of each hard drive contains 446 bytes MBR area, then if my host has two hard disks, which disk will the system go to the MBR read boot loader? This depends on the BIOS configuration. Basically, we often talk about the "system of MBR" actually refers to the first boot device of the MBR! So, another day if you want to install the boot manager to a hard disk MBR, pay special attention to the system's "first boot Device" is which, otherwise will be installed on the wrong hard disk above the MBR Oh!

Boot Loader

The main function of Loader is to understand the operating system's file format and to load the core into main memory to run it. Because of the inconsistent file formats of different operating systems, each operating system has its own boot loader! Use your own loader to be able to load the core file! That's the problem, you should have heard too much heavy operating system? It is the installation of a host of different operating systems. Since you (1) have to use their own loader to be able to load their own operating system core, and (2) system MBR only one, then how can you have a host on the same time installed Windows and Linux it?

In fact, each file system (filesystem, or partition) will retain a boot magnetic zone (boot sector) to provide the operating system installation boot loader, and usually the operating system by default installs a copy of the file system loader to his root directory Boot sector. If we install Windows and Linux on a host, the boot sector, boot loader and MBR are a bit like:

Figure 1.2.1, boot loader installed in MBR, boot sector relationship to the operating system

As shown, each operating system by default installs a set of boot loader to his own file system (that is, the box in the lower left corner of each filesystem), while the Linux system installation, you can choose to install the boot loader to the MBR, or you can choose not to install. If you choose to install to the MBR, then theoretically you will be in the MBR and boot sector to maintain a boot loader program. By default, the MBR and boot sector are loaded with a boot loader! on the Windows installation. So, you'll find that when you install multiple operating systems, your MBR is often covered by the boot loader of different operating systems! ^_^

The two problems we have just mentioned are still unresolved. 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 the MBR of the system is only one mile! How are you going to run the loader inside boot sector?

The main features of boot loader are as follows:

• Menu : Users can choose different startup items, which is also an important function of multi-booting!
• load the core file : Point directly to the bootable program section to start the operating system;
• transfer to other loader: Transfer the startup management function to the other loader responsible.

Because of the menu function, we can choose different cores to start. And because of the function of control transfer, we can load the loader in other boot sector! Windows loader, however, does not have control over the default feature, so you can't use Windows loader to load Linux loader! That's why the third chapter talks about MBR and multiple start-up, with special emphasis on Windows reload Linux. We will explain the above three functions in the diagram below to see you understand! (and the diagram in Chapter three is very similar!) )

Figure 1.2.2, Menu function and control transfer function of startup manager

As shown in, my MBR uses Linux grub as the boot manager, and the assumption is that there are already three menus, the first menu can directly point to the kernel file of Linux and directly load the core to boot; the second menu can give the Startup manager control over to Windows to manage, when Windows loader will take over the start-up process, and this time he will be able to start Windows. The third menu is the boot manager that uses Linux in boot sector, and then it jumps out of another grub menu! Did you get it?

and the final boot loader function is " load kernel file"!

load core detection hardware and INITRD

When we start to read the core files with the boot loader management, Linux then compresses the core into main memory and uses the core functions to start testing and driving the various peripherals, including storage devices, CPUs, network cards, sound cards, and so on. At this point , the Linux kernel will re-detect the hardware with its own function, but not necessarily use the hardware information detected by the BIOS Oh! In other words, the core is only beginning to take over the BIOS after the work. So where's the core file? In general, he will be placed in/boot and named/boot/vmlinuz!

[[email protected] ~]# ls--format=single-column-f/bootconfig-2.6.18-92.el5      <== This version core is compiled with the feature and module configuration file grub/                     <== is the boot Manager grub related data directory initrd-2.6.18-92.el5.img  <== virtual file system files! System.map-2.6.18-92.el5  <== core function is placed to the memory address of the corresponding table Vmlinuz-2.6.18-92.el5     <== is the core file! The most important person!

From the table above we can also know this version of the Linux core for 2.6.18-92.el5 this version! For the convenience of hardware developers and other core feature developers, the Linux core can be loaded into the/lib/modules/directory by dynamically loading the core modules (think of them as drivers). since the module is placed in the root directory of the disk (remember that/lib can not be placed in a different partition than/separately!) ), the core must mount the root directory during startup so that the core module can be read to provide the ability to load the driver. And for fear of affecting the file system on the disk, the root directory is mounted in a read-only manner during startup.

In general, non-essential functions and can be compiled into the core functions of the module, the current Linux distributions will compile him into a module. So u disk, SATA, SCSI ... Drivers for disk drives are usually present in a modular way. Now think of a situation where your Linux is installed on a SATA disk, you can get boot loader and kernel files to boot through the BIOS INT 13, and then kernel will start taking over the system and detecting the hardware and trying to mount the root directory to get the amount Outside of the driver.

The problem is that the core doesn't know the SATA disks at all, so the drivers for the SATA disks need to be loaded, or the root directory cannot be mounted at all. But SATA driver in/lib/modules, you can not mount the root directory and how to read the driver inside the/lib/modules/? Right! It's a very difficult dilemma! In this case, your Linux is not able to start smoothly! What do you do? It doesn't matter, we can deal with this problem through the virtual file system.

The virtual file system (Initial RAM Disk) is typically used with a file name of/BOOT/INITRD, which is characterized by the ability to load into memory through the boot loader, which is then decompressed and emulated into a root directory in memory, and this is emulated in memory The file system can provide a running program, through the program to load the boot process of the most needed core modules, usually these modules are U disk, RAID, LVM, SCSI and other file system and disk interface driver! When loading is complete, it will help the core to re-call/sbin/init to begin the subsequent normal startup process.

As shown, the boot loader can load kernel and INITRD, then in memory let initrd extract to the root directory, kernel will be able to load the appropriate driver, eventually release the virtual file system, and mount the actual root file system, you can start the subsequent normal Start the process. For more detailed initrd, you can use man initrd to check it out yourself. Let's take a look at the contents of the CentOS 5.x initrd file below.

# 1. First copy the/BOOT/INITRD to the/TMP/INITRD directory and wait for decompression: [[[email protected] ~]# mkdir/tmp/initrd[[email protected] ~]# CP/ Boot/initrd-2.6.18-92.el5.img/tmp/initrd/[[email protected] ~]# cd/tmp/initrd[[email protected] INITRD] # File Initrd-2.6.18-92.el5.imginitrd-2.6.18-92.el5.img:gzip compressed data, ... # It turns out to be the zip file of gzip! Because it is gzip, the extension is changed to. gz! # 2. Unzip the above file: [[email protected] initrd]# mv initrd-2.6.18-92.el5.img initrd-2.6.18-92.el5.gz[[email  Protected] initrd]# gzip-d initrd-2.6.18-92.el5.gz[[email protected] initrd]# file Initrd-2.6.18-92.el5initrd-2.6.18-92.el5:ascii Cpio Archive (SVR4 with no CRC) # Got the long time, the original or the cpio of the command compressed into the file Ah! Unzip to see! # 3. extract with Cpio [[email protected] initrd]# CPIO-IVCDU < initrd-2.6.18-92.el5[[email protected] initrd]#    lldrwx------2 root root 4096 Apr 02:05 bindrwx------3 root root 4096 Apr 02:05 devdrwx------2 root root 4096 Apr 02:05 etc-rwx------1 root root 1888 Apr 02:05 init-rw-------1root root 5408768 Apr 02:00 initrd-2.6.18-92.el5drwx------3 root root 4096 Apr 02:05 libdrwx------2 root root 4096 Apr 02:05 proclrwxrwxrwx 1 root root 3 Apr 02:05 sbin-bindrwx------2 root root 4096 Apr 10 02 : sysdrwx------2 root root 4096 Apr 02:05 sysroot# Watch! Is like a root directory! In particular, there is the init this run file! Be sure to look at the permissions! # Next look at what's in Init's file? # 4. Observing the more important running items in the init file [[email protected] initrd]# cat Init#!/bin/nash <== using a bash-like Shell to run mount -T Proc/proc/proc <== mount memory virtual file system .... (omitted in middle) .... echo Creating initial device nodesmknod/dev/null C 1 3 <== Create the various devices required by the system! .... (omitted in middle) .... echo "Loading Ehci-hcd.ko module" Insmod/lib/ehci-hcd.ko <== loading each core module is the driver! .... (middle omitted) .... echo Creating root device.mkrootdev-t ext3-o defaults,ro hdc2 <== try to mount the root directory! .... (omitted below) ....

Through the contents of the above running file, we can know that INITRD has loaded the module and tried to mount the virtual file system. The next step is to run smoothly! So is it necessary to INITRD?

Is it not possible to start without initrd? Answer: Not necessarily! The most important reason to need initrd is that when the root directory cannot be mounted at boot time, it is necessary to initrd at this time, such as your root directory on a special disk interface (U disk, SATA, SCSI), or your file system is special (LVM, RAID) and so on, will need in Itrd. If your Linux is installed on the IDE interface of the disk, and use the default Ext2/ext3 file system, then do not need to INITRD can also be successfully launched into Linux!

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

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

Linux kernel boot process [go]