Linux system Boot Process

This article takesRedHatThe 9.0 and i386 platforms, for example, analyze the entire Linux boot process from the user powering on until the command line prompt appears on the screen. and introduces the various files involved in the launch.

Reading the Linux source code is undoubtedly the best way to learn Linux in depth. In this article on the Linux boot process, we also try to dig deeper into the Linux startup process from the source code perspective, so it is also simple to relate to some of the relevant Linux source code, Linux boot this part of the source is mainly used in the C language, but also involves a small number of compilations. The startup process also executes a large number of scripts written by the shell (mostly bash shell). In order to facilitate readers to read, the entire Linux startup process is divided into the following sections, we can refer to:
When the user turns on the power of the PC, the BIOS posts, starts with the boot device (usually the hard disk) set up in the BIOS, and then starts booting the boot program that is installed on the device, LILO or GRUB, boot linux,linux first to boot the kernel, then execute the INIT program, The INIT program calls the Rc.sysinit and RC programs, Rc.sysinit and RC after the completion of the system initialization and operation of the service, after the return init;init started the Mingetty, opened the terminal for users to log on the system, the user login successfully entered the shell, so that the completion of the boot to the login The entire startup process of the recording.

Here are a few of the key parts:

Part I: Booting the kernel (in-core booting)
Red Hat9.0 can start booting the Linux system with a boot program such as Lilo or grub, and when the boot program successfully completes the boot task, Linux takes control of the CPU from them, then the CPU starts executing the Linux core Image code and starts the Linux boot process. Several assembler programs are used to boot Linux, and this step is generalized to these files under "Arch/i386/boot" in the Linux source tree: Bootsect. S, Setup. S, video. S and so on.
Which bootsect. S is the assembly source that generates the boot sector, and it jumps directly to setup after the load action is completed. S of the program entrance. Setup. The main function of S is to copy system parameters (including memory, disk, etc.) to special memory so that they can be read by code in protected mode later. In addition, Setup. s also includes the code in VIDEO.S to detect and set the display and display modes. Finally, Setup. s converts the system to protected mode and jumps to 0x100000.
So 0x100000 what code is stored in this memory address? And where does this code come from?
0x100000 This memory address is stored in the extracted kernel, because Red Hat provides the kernel contains a lot of drivers and functions are relatively large, so in the kernel compiled by using the "Makebzimage" method, to generate a compressed kernel, In Redhat, the kernel is often named Vmlinuz, which is the head in "arch/i386/boot/compressed/" during the initial boot of Linux. S uses the Decompress_kernel () function defined in MISC.C to extract the kernel vmlinuz to 0x100000.
When the CPU jumps to 0x100000, the Arch/i386/kernel/head is executed. S "in Startup_32, which is also the entrance of Vmlinux, and then jumps to Start_kernel (). Start_kernel () is a defined function in "init/main.c", and a series of initialization functions are called in Start_kernel () to complete the settings of the kernel itself. In the Start_kernel () function, a lot of work has been done to build a basic Linux core environment. If the Start_kernel () is executed successfully, the basic Linux core environment is already set up.
At the end of Start_kernel (), by calling the Init () function, the system creates the first core thread and initiates the init process. The core thread init () is primarily to perform some peripheral initialization work, including calling Do_basic_setup () to complete the loading and initialization of peripherals and their drivers. and complete the file system initialization and installation of the root file system.
When the Do_basic_setup () function returns init (), Init () also opens the/dev/console device, redirects three standard input and output files stdin, stdout, and stderr to the console, and finally, Search the init program in the file system (or the program specified by the init= command line parameter) and load the EXECUTE INIT program using the EXECVE () system call. By the end of this init () function, the boot part of the kernel has ended,
Part II: Running init

Init process number is 1, it can be seen from this point, the INIT process is the starting point of all processes of the system, Linux after the completion of the kernel boot, began to run the INIT program. The INIT program needs to read the configuration file/etc/inittab. Inittab is a non-executable text file that consists of several lines of instructions. In the Redhat system, the contents of the Inittab are as follows (added in the comments starting with "# # #"):
#
# Inittab This file describes how the INIT process should set up
# The system in a certain run-level.
#
# Author:miquel van Smoorenburg,
# ModifIEd for RHS Linux by Marc Ewing and Donnie Barnes
#
# Default RunLevel. The runlevels used by RHS is:
# 0-halt (do not set Initdefault to this)
# 1-single User mode
# 2-multiuser, without NFS (the same as 3, if you don't havenetworking)
# 3-full Multiuser mode
# 4-unused
# 5-x11
# 6-reboot (do not set Initdefault to this)
#
# # #表示当前缺省运行级别为5 (Initdefault);
Id:5:initdefault:
# # #启动时自动执行/etc/rc.d/rc.sysinit script (sysinit)
# System initialization.
Si::sysinit:/etc/rc.d/rc.sysinit
L0:0:WAIT:/ETC/RC.D/RC 0
L1:1:WAIT:/ETC/RC.D/RC 1
L2:2:WAIT:/ETC/RC.D/RC 2
L3:3:WAIT:/ETC/RC.D/RC 3
L4:4:WAIT:/ETC/RC.D/RC 4
# # #当运行级别为5时, run the/ETC/RC.D/RC script with 5 as the parameter, and Init will wait for it to return (wait)
L5:5:WAIT:/ETC/RC.D/RC 5
L6:6:WAIT:/ETC/RC.D/RC 6
# # #在启动过程中允许按CTRL-alt-delete Restart System
# Trap Ctrl-alt-delete
Ca::ctrlaltdel:/sbin/shutdown-t3-r now
# when our UPS tells us Power had failed, assume we have a few minutes
# of Power left. Schedule a shutdown for 2 minutes.
# This does, the course, assume you have Powerd installed and your
# UPS connected and working correctly.
Pf:owerfail:/sbin/shutdown-f-H +2 "Power Failure; System shutting down "
# If Power was restored before the shutdown kicked in, cancel it.
pr:12345 owerokwait:/sbin/shutdown-c "Power restored; Shutdown Cancelled "
# # #在2, 3, 4, 5 level on the Ttyx as the parameters to execute the/sbin/mingetty program, open Ttyx terminal for user login,
# # #如果进程退出则再次运行mingetty程序 (respawn)
# Run Gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty Tty2
3:2345:respawn:/sbin/mingetty Tty3
4:2345:respawn:/sbin/mingetty Tty4
5:2345:respawn:/sbin/mingetty Tty5
6:2345:respawn:/sbin/mingetty Tty6
# # #在5级别上运行xdm程序, provide XDm graphical login interface, and re-execute on exit (respawn)
# Run XDm in RunLevel 5
X:5:respawn:/etc/x11/prefdm-nodaemon
Take the Inittab file above as an example to illustrate the format of Inittab. Lines where # begins with # are comment lines, and each row has the following format in addition to the comment line:
Id:runlevel:action rocess
The detailed explanations of the above items are as follows:
1. Id
The ID refers to the entry identifier, which is a string, and for other login program items such as Getty or Mingetty, the ID is the same as the TTY number, otherwise the Getty program will not function properly.
2. RunLevel
RunLevel is the identity of the runlevel at which Init is located, typically using 0-6 and s or S. 0, 1, 6 operation level is reserved by the system: 0 as Shutdown action, 1 as restart to single-user mode, 6 for restart, s and s mean the same, the single-user mode, and no need to inittab files, and therefore does not appear in the Inittab, in fact, into the single-user mode, Init runs/sbin/sulogin directly on the console (/dev/console). In the general system implementation, the use of 2, 3, 4, 5 levels, in the Redhat system, 2 represents a multi-user mode without NFS support, 3 represents a full multi-user mode (also the most commonly used level), 4 reserved for user-defined, 5 represents the XDm graphical login method. 7-9 levels are also available, and traditional UNIX systems do not define these levels. RunLevel can be multiple values in parallel to match multiple runlevel, and for most actions, only if RunLevel matches the current runlevel is successful.
3. Action
An action is a description of how the subsequent process works. Action-desirable values include: Initdefault, Sysinit, boot, bootwait, and so on:
Initdefault is a special action value that identifies the default boot level, and when Init is activated by the core, it reads the Initdefault item in the Inittab, obtains runlevel in it, and acts as the current runlevel. If there is no Inittab file, or there are no Initdefault entries in it, INIT will request input runlevel on the console.
Actions such as sysinit, boot, bootwait, and so on, will run unconditionally when the system starts, ignoring the runlevel.
The rest of the action (without initdefault) is related to a runlevel. The definitions of each action are described in detail in the Inittab Man Handbook.
4. Process
Process is the specific execution procedure. The program can be followed with parameters.
Part III: System initialization
There is a line in the init configuration file:
Si::sysinit:/etc/rc.d/rc.sysinit
It calls the execution of/etc/rc.d/rc.sysinit, and Rc.sysinit is a bash shell script, which is mostly done with some system initialization, and Rc.sysinit is an important script to run every run level first. Its main tasks are: Activating the swap partition, checking the disk, loading the hardware modules, and some other priorities that need to be performed.
Rc.sysinit has about 850 rows, but each single feature is relatively simple, with comments, suggesting that interested users can read the file on their own machine in order to understand the details of the initialization of the system. Because this file is longer, it is not listed in this article, and does not make a specific introduction.
When the Rc.sysinit program finishes executing, it will return to Init to continue to the next step.

Part IV: Start the daemon for the corresponding runlevel

After Rc.sysinit executes, it will return to Init to continue with other actions, usually followed by the/ETC/RC.D/RC program. For example, run Level 3, Init executes the following line in the configuration file Inittab:
L5:5:WAIT:/ETC/RC.D/RC 5
This line indicates that running with the 5 parameter/ETC/RC.D/RC,/ETC/RC.D/RC is a shell script that accepts 5 as a parameter to execute all RC startup scripts under the/etc/rc.d/rc5.d/directory,/etc/rc.d/rc5.d/ These startup scripts in the directory are actually some linked files, not the real RC startup scripts, the real RC?? Scripts are actually placed in the/etc/rc.d/init.d/directory. These RC startup scripts have a similar usage, and they generally accept start, stop, restart, status, and so on.
The RC startup script in/etc/rc.d/rc5.d/is usually a link file starting with K or S, and will run with the start parameter for startup scripts starting with S. If it is found that the corresponding script also has a K-link, and is already in the running state (the file under/var/lock/subsys/as the flag), the stop is the first parameter to stop these started daemons, and then rerun. This is done to ensure that when Init changes the RunLevel, all associated daemons are restarted.
As to which Daemons will be run at each run level, the user can be set from the row by using "System Services" in Chkconfig or Setup. Common daemon processes are:
AMD: Automatically install the NFS daemon
APMD: Advanced Power Management Daemon
Arpwatch: Log and build an Ethernet address and IP address to the database that you see on the LAN interface
AutoFS: Automatic installation of the management process AutoMount, related to NFS, dependent on NIS
The daemon of the scheduled task under Crond:linux
Named:dns Server
NETFS: Installing NFS, Samba, and NetWare network file systems
Network: Activating a scripted program that has a configured networking interface
NFS: Open NFS Service
PORTMAP:RPC Portmap Manager, which manages RPC service-based connections
SendMail: Mail server SendMail
Smb:samba file sharing/Printing service
Syslog: A script that lets the system boot up syslog and klogd the system log waiting process
xfs:x window font server, providing font sets for local and remote X servers
XINETD: Support the core daemon of various network services, can manage Wuftp, sshd, Telnet and other services
These daemons also start to complete, the RC program is finished, and then return to Init to proceed to the next step.
Part V: Setting up the terminal

After the RC finishes executing, return to init. At this point the basic system environment has been set up, various daemons have been started. Init then opens 6 terminals so that the user can log on to the system. You can switch between the 6 terminals by pressing ALT+FN (n corresponds to 1-6). The following 6 lines in Inittab define 6 terminals:
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty Tty2
3:2345:respawn:/sbin/mingetty Tty3
4:2345:respawn:/sbin/mingetty Tty4
5:2345:respawn:/sbin/mingetty Tty5
6:2345:respawn:/sbin/mingetty Tty6
From the above can be seen in the 2, 3, 4, 5 of the operating level will be respawn to run the Mingetty program, mingetty program can open terminal, set mode. At the same time it will display a text login interface, which is the login interface we often see, in this login screen will prompt the user to enter a user name, and the user input user will be passed as a parameter to the login program to verify the identity of the user.
Part VI: Login to the system, start to complete
For graphical users with a run level of 5, their login is via a graphical login interface. After successful login, you can go directly to KDE, GNOME and other window manager. And this article is mainly about the text mode of login situation:
When we see the login screen of Mingetty, we can enter the user name and password to log into the system.
Linux Account Verification Program is Login,login will receive mingetty from the user name parameters. Login then parses 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 then exit. This is typically used for system maintenance to prevent non-root users from logging on. Only the terminal registered in/etc/securetty allows the root user to log on, and if the file does not exist, root can log on at any terminal. The/etc/usertty file is used to make additional access restrictions to the user, and there are no additional restrictions if the file does not exist.
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 what the home directory is and what shell to use. If you do not specify a home directory, the default is the root directory, and if you do not specify a shell, the default is/bin/bash.
When the login program succeeds, it will output the most recent login information (recorded in/var/log/lastlog) to the corresponding terminal, and check whether the user has new mail (in/usr/spool/mail/'s corresponding user list). Then start setting up the 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, in which case other configuration files may be called. After all the configuration files have been executed, the various environment variables are set up, and a familiar command prompt will appear, and the entire boot process is over.
It is hoped that the above analysis of the Linux boot process will help those who want to learn more about Linux users to establish a relevant Linux startup process, and then can further study how Linux works next.

Linux system Boot Process