Linux Start-up process

If you have a certain understanding of the Linux operating system, want to further explore its deeper things. This includes the system start-up process, the composition of the file system, the dynamic library and the static library based on the execution of the program, the structure and principle of the protocol stack, the mechanism of the driver and so on.

One of the Linux operating system startup process is certainly the most interested to understand, here in the integration of the existing online wisdom, based on the 2.6.32 kernel of the CentOS 6.0 system, the Linux startup process to do some analysis, I hope to help you.

OK, let's have a closer. For a host with a Linux system installed, when the user presses the power-on button, there are a total of the following processes,

Each of these processes performs its own initialization part, and some processes can be divided into several sub-processes. Next, we will do a detailed analysis and explanation of each stage.

one, the BIOS self-test

People with a slight computer base should have heard the BIOS (Basic input/output system), also known as the basic input and output system, which can be regarded as a software that is permanently recorded in ROM and is part of the operating system input and output management system. The early BIOS chip is really "read-only", the content is written with a burner, once written can not be changed, unless the chip is replaced. Now the motherboard uses a chip called Flash EPROM to store the system BIOS, the contents of which can be re-written by using the erase program provided by the board manufacturer, so that the user upgrade BIOS provides a great convenience.

The function of the BIOS consists of two parts, the post code and the runtime service respectively. After the post phase is complete it will be purged from memory, and the runtime service will be retained for the target operating system startup. The detailed work done in the BIOS two phases is as follows:

Step 1: power-on self-test post (power-on), mainly responsible for detecting the system peripheral critical equipment (such as: CPU, memory, graphics card, I/O, keyboard mouse, etc.) is normal. For example, the most common is the memory loose situation, the BIOS self-test stage will be error, the system can not start up;

Step 2: after step 1 succeeds, a small program is executed to enumerate the local device and initialize it. This step is primarily based on the system boot order that we set up in the BIOS to search for the drives that are used to boot the system, such as hard disks, CDs, USB drives, floppy disks, and networks. We take the hard drive as an example, the BIOS now reads the first sector of the hard drive (mbr,512 bytes) and executes the code inside. In fact, the BIOS here does not care what is in the first sector of the boot device, it is simply responsible for reading the sector content and executing it.

At this point, the BIOS task is completed, and then the system-initiated control is transferred to the MBR section of the code.

PS: In a PC, Linux starts from the 0XFFFF0 address.

second, System guidance

Let's first look at the MBR, which is the abbreviation for the Master Boot record. The hard disk's 0 cylinders, 0 heads, and 1 sectors are referred to as the primary boot sector. It consists of three parts, the Master boot Program (Bootloader), the hard disk partition table DPT (disk Partition table), and the hard disk valid flag (55AA), and its structure is as follows:

The disk partition table contains the following three parts:

1. Partition ID (5: Enshin 82:swap 83:linux 8E:LVM fd:raid)
2. Partition starting Magnetic column
3. Number of magnetic columns in the partition

Typically, common boot programs such as Lilo and Grub are installed directly in the MBR. Let's take grub as an example to analyze the boot process.

Grub guidance is also divided into two stages stage1 and stage2 phases (some newer grub also defines the stage1.5 phase).

1. Stage1:Stage1 is directly written to the MBR, so that when the machine starts to detect the hardware, the control is given to the grub code. That is, the STAGE1 code is stored in the first 446 bytes of space you see. The BIOS loads the stage1 into the in-memory 0x7c00 and jumps to execution. Stage1 (/stage1/start. S) is very simple, just read the hard disk 0 first 0 Channel 2 sectors into memory. The 0-First 0-Channel 2-sector content is/stage2/start in the source code. S, compiled 512 bytes, is the entrance to Stage2 or stage1_5. At this point, stage1 is not capable of identifying the file system. If you feel a bit dizzy, then the following process will skip directly, to see Stage2 Bar!

"Rumor" The process of locating the hard disk's 0-head 0-Channel 2 sector:

The BIOS loads the stage1 into the memory 0x7c00 and executes, then calls the BIOS INIT13 interrupts, loads the hard 0 header 0 2 sector contents into memory 0x7000, and then calls Copy_buffer to transfer it to memory 0x8000. There are usually two ways of addressing the 0-head 0-Channel 2 sector: LBA and CHS. If you are a Hugan type of enthusiasts, then go to find Google inquire about these two ways of the ins and outs of it.

2. Stage2: Strictly speaking here should also distinguish a stage1.5, and put stage1.5 here together to introduce, lest everyone see in the mind noisy. OK, let's go ahead and say 0/stage2/start from 0 to 2 sectors. s file, when its content is read into memory, its primary role is to be responsible for reading stage2 or stage1.5 from the hard disk into memory. If it is stage2, it will be loaded into the 0x820, and if it is stage1.5, it will be loaded into the 0x2200 place. The Stage2 or stage1_5 here is not a file in the/boot partition/boot/grub directory because grub is not capable of identifying any file systems at this time.

Ø if start. s load stage1.5:stage1.5 It is stored in the hard disk 0 Head 0 Channel 3 sector backward position, stage1_5 as the bridge between Stage1 and Stage2, Stage1_5 has the ability to identify the file system, then grub has the ability to access the/boot partition/ The Stage2 file in the Boot/grub directory loads the stage2 into memory and executes.

Ø if start. s load stage2: Similarly, this stage2 is not a stage2 in the/boot partition/boot/grub directory, this time start. S reads the stage2 that is stored in the/boot partition boot sector. There is a limit in this case: because start. s addresses the hard drive directly through the BIOS interrupt mode (rather than by accessing the specific file system), with a limited addressing range of less than 8GB. Therefore, this situation requires that the/boot partition be divided before the hard drive 8GB addressing space.

If it is case 2, we will clear the contents of the/boot/grub directory, can still successfully boot grub, if it is case 1, the/boot/grub directory stage2 deleted, the system startup process grub will fail.

Third, start the kernel

When Stage2 is loaded into memory execution, it first parses the grub configuration file/boot/grub/grub.conf, then loads the kernel image into memory and transfers control to the kernel. The kernel immediately initializes the devices in the system and makes the relevant configuration work, including CPU, I/O, storage devices, and so on.

With regard to the loading of Linux device drivers, some of the drivers are compiled directly into the kernel image, while the other drivers are placed in INITRD (RAMDisk) in the form of modules.

The Linux kernel needs to adapt to a variety of hardware architectures, but it is impractical to incorporate all hardware drivers into the kernel, and it is not possible for the kernel to write device drivers to the kernel for each new hardware structure. In fact, the kernel image of Linux only contains the basic hardware driver, the system hardware information is detected during the system installation, and some device drivers are written to INITRD according to the installation information and system hardware information. This allows a part of the device driver to be loaded in INITRD at a later time when the system is booted. Here it is necessary to give you a little more about initrd this stuff:

The English meaning of INITRD is bootloader initialized RAM disk, which is the memory disk initialized by boot loader. Before the linu2.6 kernel is booted, boot loader loads the Initrd file from the storage media into memory, which accesses the Initrd file system in the memory before accessing the real root filesystem. In the case where boot loader is configured with INITRD, the kernel boot is divided into two phases, the first stage is init in the Initrd file system, the loading of the driver module is completed, and the second stage executes the/sbin/init process in the real root file system.

Another concept: Initramfs

Initramfs is the technique introduced in kernel 2.5, which actually means attaching a cpio package to the kernel image, which contains a small file system that the kernel unlocks when the kernel is booted, and releasing the file system contained therein to ROOTFS, some of the initialization code in the kernel is placed in the filesystem and executed as a user-level process. The obvious benefit is that the kernel initialization code is streamlined, and the kernel initialization process is made easier to customize.
The question is: My kernel is 2.6.32-71.el6.i686 version, but in my/boot partition there is a/boot/initramfs-2.6.32-71.el6.i686.img type of file, do not understand, but also look for the expert doubts. I only know that in the 2.6 kernel support two formats of INITRD, one is the 2.4 kernel file system image IMAGE-INITRD, one is the cpio format. And then we'll explore what the initramfs-2.6.32-71.el6.i686.img put in there.

Unzip the contents of the INITRD.IMG in the TMP folder:

If the format of the Initrd.img file is displayed as "Initrd.img:ISO 9660 CD-ROM filesystem data", you can mount it directly by entering the command "Mount-o loop initrd.img/mnt/test".

Through the analysis and our validation, we do get the conclusion that:

Grub's stage2 loads the initrd into memory, letting it release the content into the content, and the kernel executes the init script in Initrd, when the kernel gives control to the init file processing. We simply browsed the contents of the Init script and found that it was also primarily loaded with device drivers related to various storage media. When the required drivers are loaded, a root device is created, and the root file system Rootfs is mounted as read-only. At the end of this step, release unused memory, switch to the real root filesystem, run the/sbin/init program, and execute the system 1th process. Thereafter, the control of the system was fully delegated to the/sbin/init process.

Iv. Initialization System

After the arduous trek, we finally approached the dawn of the dawn. This is the final step: Initialize the system. The/sbin/init process is the parent process of all other processes in the system, and when it takes over the control of the system, it first reads the/etc/inittab file to execute the corresponding script for system initialization, such as setting up the keyboard, fonts, loading modules, setting up the network, etc. The main tasks include the following:

1. Execute the System initialization script (/etc/rc.d/rc.sysinit), the basic configuration of the system , read and write to mount the root file system and other file system, to this system is basically run up, the need to run the level of determination and the corresponding service start. Rc.sysinit do things (different Linux distributions, the file may have some differences) as follows:

(1) Get the network environment and host type. The network environment settings file "/etc/sysconfig/network" is read first to obtain a network environment such as host name and default gateway.
(2) Test and load the memory device/proc and USB device/sys. In addition to/proc, the system proactively detects if a USB device is available and actively loads the USB drive, attempting to load the USB file system.
(3) Decide whether to start SELinux.
(4) Detection of interface devices and testing of Plug and Play (PNP) parameters.
(5) Loading of user-defined modules. The user can then "/etc/sysconfig/modules/*.modules" to add a custom module, which will be loaded into the system.
(6) Load the relevant settings of the core. Press "/etc/sysctl.conf" to configure the function for the setting value of this file.
(7) Set the system time (clock).
(8) Set the font style for the console of the terminal.
(9) Set up raid and LVM and other hard disk functions.
(10) View the test disk file system in a way.
(11) The conversion of disk quota quota.
(12) Re-loading the system disk in read mode.
(13) Start the quota function.
(14) Start the system random number device (generate random number function).
(15) Clear the temporary files during the startup process.
(16) Load the boot information into the "/VAR/LOG/DMESG" file.

When the/etc/rc.d/rc.sysinit is finished, the system will work smoothly, but also need to start the system needs a variety of services, so that the host can provide the relevant network and host functions, so the following script will be executed.

2. Execute the/ETC/RC.D/RC script. The file defines the order in which the service is started with K after S, and the specific service status for each runlevel is placed in the/ETC/RC.D/RC*.D (*=0~6) directory, and all files are symbolic links to the corresponding files under/ETC/INIT.D. Rc.sysinit analyzes the/etc/inittab file to determine the boot level of the system before it executes the files under/ETC/RC.D/RC*.D.

/etc/init.d->/ETC/RC.D/INIT.D
/ETC/RC->/ETC/RC.D/RC
/ETC/RC*.D->/ETC/RC.D/RC*.D
/etc/rc.local->/etc/rc.d/rc.local
/etc/rc.sysinit->/etc/rc.d/rc.sysinit

In other words, INIT.D, RC, RC*.D, rc.local, and rc.sysinit in the/etc directory are symbolic links to the corresponding files and folders in the/ETC/RC.D directory. Let's take the start Level 3 as an example to explain briefly.

The/ETC/RC.D/RC3.D directory, where the contents are all linked files starting with S or K, are linked to various shell scripts in the "/ETC/RC.D/INIT.D" directory. s represents the service content that requires start at startup, and K indicates the service content that needs to be shut down when the computer is shut down. System services in/ETC/RC.D/RC*.D are started in the background, if you want to make more specific customizations to a service in a runlevel, by Chkconfig command, or through Setup, Ntsys, System-config-services to be customized. If we need to increase the startup content ourselves, we can add the relevant shell script in the INIT.D directory and then establish a link file in the RC*.D directory to point to the shell script. The start or end order of these shell scripts is determined by the numbers that follow the s or K letters, and the smaller the number, the more the script executes. For example,/etc/rc.d/rc3.d/s01sysstat is executed before/etc/rc.d/rc3.d/s99local.

3. Execute user-defined bootstrapper/etc/rc.d/rc.local. in fact, when executing/etc/rc.d/rc3.d/s99local, it is executing/etc/rc.d/rc.local. S99local is a symbolic link that points to rc.local. In general, the custom program does not need to perform the above mentioned cumbersome to build the shell to increase the link file step, only need to put the command in rc.local, the shell script is reserved for the user to customize the boot content.

4. After completing all the system startup tasks, Linux will start the terminal or X-window to wait for the user to log in. tty1,tty2,tty3 ... This means that when running level 1,2,3,4, "/sbin/mingetty" will be executed, and there are 6 executed, so Linux will have 6 plain text terminals, Mingetty is the command to start the terminal.

In addition to these 6 will also perform the "/etc/x11/prefdm-nodaemon" this main start X-window

At this point, the system starts to complete.

PS: Finally, attach a very complete system start flowchart, suitable for all levels of readers.

Linux Start-up process