Linux system startup process

The Linux system is used all the time, but it is not clear about the system startup process and the system initialization and the various service startup. Today I finally figured out what the whole thing was. Originally want to write an article, just on the internet to see a good introduction, very detailed, directly brought.

Linux system startup process:

BIOS self-Test-> grub bootstrapper-> Load Kernel-> execute init-> boot shell-> Login Login System

Detailed introduction to the various stages of system startup:

I. BIOS self-test

The computer is first post self-test by the BIOS after powering it on, and the boot block is read from the hard disk, floppy disk, or CDROM according to the boot order set in the BIOS. The Linux system is the address oxFFFF0 in the human BIOS that starts booting. The 1th step in the BIOS is the Power post self-test. The job of post is to test the hardware. The 2nd step in the BIOS is to perform an enumeration and initialization of the local device. The BIOS consists of two parts: Post code and runtime service. When the post completes, it is cleaned out of memory, but the BIOS runtime service remains in memory and the target operating system can use these services.

The BIOS runtime searches for devices that are active and can be booted in the order defined by the CMOS settings. The boot device can be a floppy disk, a CD-ROM, a partition on the hard disk, a device on the network, or even a USB flash. Typically, Linux systems are booted from the hard disk, where the master boot Record (MBR) contains the primary boot loader. The MBR is a 512-byte sector that is located in the first sector (0-0-cylinder 1-sector) on disk. When the MBR is loaded into RAM, the BIOS will give control to the MBR.

If you want to view the contents of the MBR, the user needs to run the following command as the root user:

#dd If=/dev/had of=mbr.bin bs=512 count=1

Read the 1+0 block.

Output 1+0 block.

#od –xa Mbr.bin

... ...

It reads the first 512 bytes of content from/dev/had (the first IDE disk) and writes it to the Mbr.bin file. The OD command prints the contents of this binary file in 16-in and ASCII format.

Two. Start Grub/lilo

Both grub and Lilo are boot loaders. The boot loader is used to boot an operating system boot. When the machine boots its operating system, the BIOS reads the front 512 bytes (master boot record) on the boot media. Only one operating system boot record can be stored in a single MBR, so there is a problem when multiple operating systems are needed and more flexible boot loader is required.

All boot loaders work in a similar way to meet common goals, but there are many differences between Lilo and Grub:

Lilo has no interactive command interface, and Grub has it;

Lilo does not support network booting, while Grub supports;

Lilo stores information that can boot the operating system in the MBR.

If you modify the Lilo profile, you must rewrite the first phase of the Lilo boot loader to the MBR. This is a more dangerous option than grub, because an incorrectly configured MBR may cause the system to fail to boot. When you use GRUB, if the configuration file is misconfigured, you are only transferred to the Grub command-line interface by default.

Three. Load kernel

The next step is to load the kernel image into memory, and the kernel image is not an executable kernel, but a compressed kernel image. Usually it is a zimage (compressed image, less than 512KB) or a bzimage (larger compressed image, greater than 512KB), which is used in advance zlib compression. In front of this kernel image is a routine that implements a small number of hardware settings and compresses the kernel contained in the kernel image and puts it into high-end memory. If you have an initial RAM disk image, the system moves it into memory and indicates that it will be used later. The routine then invokes the kernel and begins the process of booting the kernel.

Four. Executing the INIT process

The init process is the starting point for all processes in the system, and the kernel, after completing the kernel boot, loads the INIT program in this process space, and its process is 1. The init process is the initiator and controller of all processes. Because it is the first running process in any Linux based system, the INIT process number (PID) is always 1.

The INIT process has the following two effects.

The first role of the INIT process is to play the role of terminating the parent process. Because the init process will never be terminated, the system can always be sure of its existence and use it as a reference when necessary. If a process is terminated before the end of all the child processes it derives, a situation that must be referenced by Init is present. At this point, the child processes that have lost the parent process will use Init as their parent process.

The second role of Init is to manage a variety of run levels by running programs at a specific level of operation. This function is defined by the/etc/inittab file.

Five. Initialize via/etc/inittab file

Init's work is based on/etc/inittab to execute the corresponding script, system initialization, such as setting the keyboard, font, loading module, set up the network and so on.

1./etc/rc.d/rc.sysinit

The following line is in the configuration file for init:

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

Rc.sysinit is the first script executed by INIT, which mainly completes some system initialization work. Rc.sysinit is an important script that runs at every run level, and its main tasks include activating swap partitions, checking disks, loading hardware modules, and others that require priority execution. /etc/rc.d/rc.sysinit mainly completes the same initialization work in each running mode. Including:

Set the initial $path variable;

Configure the network;

Start swapping for virtual memory;

The host name of the co-ordination system;

Check the root file system for necessary repairs;

Check the root file system quota;

Open the user and group quotas for the root file system;

Re-load the root file system in read/write mode;

Clears the loaded file system table/etc/mtab;

Enter the root file system into the mTAB;

Making the system ready for loading modules;

Find the relevant files of the module;

Check the file system to make the necessary repairs;

Load all other file systems;

Removal of/etc/mtab,/etc/fastboot and/etc/nologin;

Delete UUCP and lock files;

Delete obsolete subsystem files;

Delete obsolete PID files;

Set the system clock;

Activate the swap partition;

Initialize the serial port;

Load the module.

2./etc/rc.d/rcx.d/[ks]

After the rc.sysinit is executed, the INIT is returned and the/ETC/RC.D/RC program continues to execute. For example, run Level 5, Init will execute the following in the configuration file Inittab:

15:5:WAIT:/ETC/RC.D/RC 5

This line represents a 5-parameter run/ETC/RC.D/RC,/ETC/RC.D/RC is a shell script that takes 5 as a parameter to execute all the RC startup scripts in the/ETC/RC.D/RC5.D directory/etc/rc.d/ The startup scripts in the RC5.D directory are actually some linked files, not the real RC startup scripts, and the real RC startup scripts are actually in the/ETC/RC.D/INIT.D directory. These RC startup scripts have similar usage, they generally accept stat, stop, restart, status and other parameters.

The RC startup script in/ETC/RC.D/RC5.D is usually a link file that begins with a K or S, and a startup script starting with S will run with the start argument. If you find that the corresponding script also has a K-linked link and is already running (with the file under/var/lock/subsys as the flag), you will first stop these started daemons with the stop, and then rerun. This is done to ensure that all associated daemons are restarted when Init changes the run level.

As for which Daemons will run at each run level, the user can chkconfig from the row setting. The common daemons are as follows.

AMD: Automatically installs the NFS daemon.

APMD: Advanced Power Management daemon.

Arpwatch: Logs and builds a database of the Ethernet addresses and IP addresses that are seen on the LAN interface.

Outofs: Automatic installation of the management process AutoMount, NFS dependent, dependant on NIS.

Crond:linux the daemon for scheduled tasks under the system.

Named:dns server.

NETFS: Installs the NFS, Samba, and NetWare network file systems.

Network: Activates the script for the configured network interface.

NFS: Open NFS Service.

Portmap:rpcportmap Manager, which manages the connections based on RPC services.

SendMail: Mail server sendmail.

Smb:samba File share/Print service.

Syslog: A script that initiates syslog and KLOGD system log waiting processes when the system boots.

xfs:x window font server, which provides a font set for both local and remote X servers.

XINETD: Support a variety of network services of the core daemon process, can manage wuftp, sshd, Telnet and other services.

These daemons are started, the RC program is finished, and then return to Init to proceed to the next step.

3. Executive/etc/ec.d/rc.local

The run mode 2, 3, and 5 in RHEL 4 is the last in the initialization script, so the user can add some commands to the file that need to be executed after other initialization work, before logging in. When you are maintaining a Linux system, you typically encounter situations where you need a system administrator to modify the boot or shutdown command script. If you make changes that work only when booting the boot, and if the changes are small, consider simply editing the/etc/rc.d/rc.local script. This command script is executed at the last step of the boot process.

Six. Implementation of the/bin/login procedure

The login program prompts the user to enter the account and password, and then encodes and confirms the correctness of the password, if the account and password match, then initialize the environment for the users, and give control to the shell, that is, waiting for login.

Login will receive Mingetty's user name as the username parameter, and login will parse the username. If the user name is not root and there is a/etc/nologin file, login will output the contents of the Nologin file and exit. This is typically used to prevent non-root logins from being logged on during system maintenance. Only terminals registered in/etc/securetty allow the root user to log in, and if this file is not present, root can log on to any terminal. The/etc/usertty file is used to make additional access restrictions on users, and there are no other restrictions if this file is not present.

After analyzing the user name, login will search/etc/passwd and/etc/shadow to verify the password and set up additional information about the account, such as the home directory and what Shell to use. If no home directory is specified, the home directory defaults to the root directory, and if no shell is specified, the shell type defaults to/bin/bash.

When the login program succeeds, it outputs the most recent login information (recorded in/var/log/lostlog) to the corresponding terminal, and checks to see if the user has new mail (in/usr/spool/mail's corresponding user list), and then starts setting up various environment variables. For bash, the system first looks for the/etc/profile script file and executes it, and then executes it if there is a. bash_profile file in the user's home directory, where other configuration files may be invoked, and after all the configuration files are executed, the various environment variables are set. , a familiar command-line prompt appears, and the entire startup process is over.