Linux system startup process

Post-->bios (Boot Sequence)-->mbr (bootloader,446)-->kernel-->initrd--> (ROOTFS)/sbin/init (/etc/ Inittab

Description: The BIOS self-test reads the boot sequence from the BIOS and reads the bootloader--> load kernel in the MBR--reads the pseudo root--reads the init in the root file

• 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.

• System boot

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), partition number of magnetic columns

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 after 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.

• Boot 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.

L 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), the implementation of 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 systems, 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/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 custom bootloader/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. The above analysis of the place also invites you to correct the shrimp.

Other analytics about Linux continue writing next time.

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

The service started differently:
Operating level: 0-6
0:halt
1:single user mode, directly as an administrator, S,s,single
2:multi user mode, no NFS
3:multi user mode, text mode
4:reserved
5:multi user mode, graphic mode
6:reboot

Detailed start-up process
Bootloader (MBR)
Lilo:linux LOader
Grub:grand Unified Bootloader
Stage1:mbr
Stage1_5:
Stage2:/boot/grub/

Grub.conf

Default=0 # Sets the number of the default start title, starting with 0
Timeout=5 # waits for the user to select the timeout length, in seconds
Splashimage= (hd0,0)/grub/splash.xpm.gz # Grub Background image
Hiddenmenu # Hidden Menu
Password Redhat
Password--md5 $1$hkxj51$b9z8a. X//xa. Atzu1.kug.
Title Red Hat Enterprise Linux Server (2.6.18-308.el5) # kernel header, or operating system name, string, can be freely modified
Root (hd0,0) # The device on which the kernel file resides; For grub, all types of hard drives are HD, in the format (hd#,n), hd#, #表示第几个磁盘; the last N indicates the partition of the corresponding disk;
Kernel/vmlinuz-2.6.18-308.el5 ro root=/dev/vol0/root rhgb quiet # Kernel file path, and parameters passed to the kernel
INITRD/INITRD-2.6.18-308.EL5.IMG # RAMDisk file path
Password--md5 $1$hkxj51$b9z8a. X//xa. Atzu1.kug.
Title Install Red Hat Enterprise Linux 5
Root (hd0,0)
Kernel/vmlinuz-5 ks=http://172.16.0.1/workstation.cfg Ksdevice=eth0 Noipv6
Initrd/initrd-5
Password--md5 $1$fsueu/$uhUUc 8usbk5qaxc.bfw4m.

To view the run level:
RunLevel
Who-r

To view the kernel release number:
Uname-r

Install Grub Stage1:
# Grub
grub> Root (hd0,0)
Grub> Set (hd0)

Install grub the second way:
# Grub-install--root-directory=/path/to/boot ' S_parent_dir/path/to/device

Grub> Find
grub> Root (Hd#,n)
Grub> Kernel/path/to/kernel_file
Grub> Initrd/path/to/initrd_file
grub> Boot

Kernel initialization process:
1, equipment detection
2. Driver initialization (May load driver module from INITRD (INITRAMFS) file)
3. Mount the root file system with read-only loading;
4. Loading the first process init (pid:1)

/sbin/init: (/etc/inittab)
Upstart:ubuntu, D-bus, Event-driven
Systemd

Id:runlevels:action:process
ID: identifier
Runlevels: At which level this line runs;
Action: Under what circumstances the line is executed;
Process: to run the program;

Id:3:initdefault:

Si::sysinit:/etc/rc.d/rc.sysinit

ACTION:
Initdefault: Setting the default Run level
Sysinit: System Initialization
Wait: Execution when the waiting level switches to this level
Respawn: Once the program is terminated, it restarts

Tasks completed by/etc/rc.d/rc.sysinit:
1. Activate Udev and SELinux;
2, according to the/etc/sysctl.conf file, to set the kernel parameters;
3, set the clock clock;
4, loading keyboard mapping;
5, enable the swap partition;
6, set the host name;
7, the root file system detection, and read-write mode to re-mount;
8. Activate RAID and LVM devices;
9, enable disk quotas;
10, according to/etc/fstab, check and mount other file system;
11, clean up the expired lock and PID file;

For I in/etc/rc3.d/k*; Do
$I stop
Done

For I in/etc/rc3.d/s*; Do
$I start
Done

# #: The priority of closing or starting, the smaller the data the higher the priority is selected
First, the service starting with K is closed and the service starts with S.

Kernel design style:

RedHat, SUSE
Core: Dynamic load kernel module
Kernel:/lib/modules/"kernel version number command directory"/
vmlinuz-2.6.32
/lib/modules/2.6.32/

Redhat5:ramdisk-->initrd
Redhat6:ramfs-->initramfs

Single core: Linux (LWP)
Core: KO (Kernel object)



So ()

Microkernel: Windows, Solaris (threads)

Chroot:chroot/path/to/temproot [COMMAND ...]
Chroot/test/virrrot/bin/bash

Ldd/path/to/binary_file: Shows the shared libraries on which the binaries depend

MBR (bootloader)--Kernel-INITRD (INITRAMFS)--(ROOTFS)--/sbin/init (/etc/inittab)
/etc/inittab,/etc/init/*.conf
Upstart

Init/etc/inittab
Id:runlevels:action:process

Id:5:initdefault:

Si::sysinit:/etc/rc.d/rc.sysinit
OS Initialization

L0:0:WAIT:/ETC/RC.D/RC 0
rc0.d/
k*
Stop
s*
Start

/ETC/RC.D/INIT.D,/ETC/INIT.D

Service class Script:
Start

SysV:/ETC/RC.D/INIT.D
Start|stop|restart|status
Reload|configtest

Linux system startup process