Analyze Linux system startup process _unix Linux

Content Summary
Taking the RedHat9.0 and i386 platforms as an example, this paper analyzes the entire Linux boot process from the user powering up to the command prompt at the screen. It also introduces the various files involved in startup.

Reading Linux source code is undoubtedly the best way to learn Linux in depth. In this article on the Linux startup process, we also try to more in-depth analysis of the Linux boot process from the source point of view, so it is also a simple part of the relevant Linux source code, Linux start this part of the source of the main use of the C language, but also involved a small number of compilations. The startup process also performed a number of scripts written by the shell, primarily the bash shell. In order to facilitate readers to read, the author will be the entire Linux start-up process into the following sections to introduce one by one, you can refer to the following figure:

When the user turns on the PC's power supply, the BIOS posts, starts with the boot device (usually the hard drive) set up in the BIOS, and then starts the boot on the device, LILO or grub starts booting the Linux,linux first to boot the kernel, then executes the INIT program, Init program called Rc.sysinit and RC programs, Rc.sysinit and RC when the system initialization and operation of the task, return to Init;init started Mingetty, opened the terminal for user login system, the user login successfully entered the shell, so that completed from the boot to the login Recording of the entire start-up process.

Here are a few of the key parts:

Part I: Core guidance (core guidance)

Red Hat9.0 can start booting the Linux system with a boot program such as Lilo or grub, and when the bootstrapper completes the boot task, Linux takes control of the CPU from them, and then the CPU starts to execute the Linux core Image code and starts the Linux boot process. Here are a few assembler programs to boot Linux, this step into the Linux source tree in the "Arch/i386/boot" under the several files: Bootsect. S, Setup. S, video. S and so on.

Which bootsect. S is the assembly source that generates the boot sector and jumps directly to setup after it completes the loading action. The program entrance of S. Setup. The main function of S is to copy the system parameters (including memory, disk, etc. from the BIOS) to special memory so that these parameters can be read by code in protected mode later. In addition, Setup. s also includes code in the VIDEO.S to detect and set the display and display modes. Finally, Setup. s converts the system to protection mode and jumps to 0x100000.

So what code is stored in this memory address, 0x100000? And where does this code come from?

0x100000 This memory address is the unpacked kernel, because Red Hat provides a kernel that contains a number of drivers and features that appear larger, so the "makebzimage" approach is used in kernel compilation to generate a compressed kernel, In Redhat, the kernel is often named Vmlinuz, which is through the head of "arch/i386/boot/compressed/" during the initial boot process 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 the startup_32, it is also the entrance of Vmlinux, and then jump to Start_kernel (). Start_kernel () is the function defined in "INIT/MAIN.C", and a series of initialization functions are called in Start_kernel () to complete the setting of the kernel itself. In the Start_kernel () function, a lot of work is done to build the basic Linux core environment. If Start_kernel () is successfully executed, the basic Linux core environment is already in place.

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 completes the file system initialization and the root file system installation.

When the Do_basic_setup () function returns init (), Init () opens the/dev/console device again, redirecting three standard input and output files stdin, stdout and stderr to the console, and finally, Searches the init program in the file system (or the program specified by the init= command-line argument) and loads the EXECUTE INIT program using the EXECVE () system call. By the end of this init () function, the boot part of the kernel is over,

Part II: Running init

Init's process number is 1, from which we can see that the init process is the starting point for all of the system's processes, and Linux begins to run the INIT program after the kernel boot is completed. The INIT program needs to read the configuration file/etc/inittab. Inittab is a text file that is not executable and consists of several lines of instructions. In the Redhat system, the contents of the Inittab are as follows (added in the annotation in "###"):

#
# 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 are:
# 0-halt (Don't 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 (Don't 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/ETC/RC.D/RC script with 5 parameters, Init waits for it to return (wait)
L5:5:WAIT:/ETC/RC.D/RC 5
L6:6:WAIT:/ETC/RC.D/RC 6

# # #在启动过程中允许按CTRL-alt-delete reboot System
# Trap Ctrl-alt-delete
Ca::ctrlaltdel:/sbin/shutdown-t3-r now

# When we are UPS tells us Power has failed, assume we have a few minutes
# of Power left. Schedule a shutdown for 2 minutes from now.
# This does, the course, assume you have Powerd installed and your
# UPS connected and working correctly.
PF::p owerfail:/sbin/shutdown-f-H +2 "power failure; System shutting down "

# If Power is restored before the shutdown kicked in, cancel it.
Pr:12345:powerokwait:/sbin/shutdown-c "Power restored; Shutdown cancelled "

# # #在2, 3, 4, 5 level on the Ttyx as a parameter to execute/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 rerun when exiting (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 the Inittab. The lines that start with # are comment lines, and each row has the following format in addition to the comment line:
Id:runlevel:action:process

The detailed explanations for the above are as follows:

1. Id

ID refers to the entry identifier, which is a string that requires the same ID as the TTY number for other login program items such as Getty or Mingetty, otherwise the Getty program will not function correctly.

2. RunLevel

RunLevel is the identity of the running level at which Init is located, typically using 0-6 as well as s or S. 0, 1, 6 run levels are reserved by the system: 0 as a shutdown action, 1 as a reboot to Single-user mode, 6 for restart; s and s mean the same, and it does not have to inittab files and therefore does not appear in Inittab, in fact, when entering Single-user mode, Init runs the/sbin/sulogin directly on the console (/dev/console). In the general system implementation, are used in 2, 3, 4, and 5 levels, in the Redhat system, 2 represents multiuser mode without NFS support, 3 represents full multiuser mode (also the most commonly used level), 4 is reserved for user customizations, and 5 represents XDM graphics login. The 7-9 level is also available, and traditional UNIX systems do not define these levels. RunLevel can be multiple values in parallel to match multiple levels of execution, and for most action, only if the RunLevel matches the current run level successfully.

3. Action

An action is a description of how the subsequent process works. Action-desirable values include: Initdefault, Sysinit, boot, bootwait, etc.:

Initdefault is a special action value that identifies the default startup level, and when Init is activated by the core, it reads the Initdefault entry in Inittab, obtains the runlevel, and acts as the current run level. If there are no inittab files, or if there are no Initdefault entries, init will request input runlevel on the console.

Sysinit, boot, bootwait, and so on will run unconditionally when the system starts, ignoring the runlevel.

The rest of the action (excluding Initdefault) is associated with a runlevel. The definition of each action is described in detail in the Inittab Man Handbook.

4. Process

The process is the specific execution procedure. The program can be followed with parameters.

Part III: System initialization

There is one line in the configuration file for init:

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

It calls execution/etc/rc.d/rc.sysinit, and Rc.sysinit is a bash shell script that basically completes some system initialization, Rc.sysinit is an important script that runs every run level. Its main tasks are to activate swap partitions, check disks, load hardware modules, and other priorities.

Rc.sysinit is about 850 lines, but each single feature is relatively simple and annotated, suggesting that interested users can read the file on their own machine to understand the details of system initialization. Because this file is longer, it is not listed in this article, nor does it make a specific introduction.

When the Rc.sysinit program finishes executing, it returns INIT to continue to the next step.

Part Four: Start a daemon that corresponds to the run level

After Rc.sysinit executes, it returns INIT to continue with other actions, usually followed by the execution of the/ETC/RC.D/RC program. For example, run Level 3, Init will execute the following line in the configuration file Inittab:

L5: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/rc5.d/ These startup scripts in the directory are actually link files instead of real RC startup scripts, and the real RC startup scripts are actually placed in the/etc/rc.d/init.d/directory. These RC startup scripts have similar usage, and they generally accept parameters such as start, stop, restart, status, and so on.

The RC startup script in/etc/rc.d/rc5.d/is usually a link file that starts with K or S, and starts with a start script that begins with S. If the corresponding script is found to have a K-linked link and is already in a running state (with a file in/var/lock/subsys/as a flag), the daemon that has started will be stopped first with the Stop argument 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 be run at each run level, users can come from the row setting through Chkconfig or "System Services" in Setup. Common daemon processes are:

AMD: Automatic installation of the NFS daemon
APMD: Advanced Power Management Daemon
Arpwatch: Logs and builds a database of Ethernet addresses and IP addresses that are seen on the LAN interface
AutoFS: Automatic installation of the management process AutoMount, NFS dependent, dependant on NIS
The daemon for scheduled tasks under Crond:linux
Named:dns Server
NETFS: Installing NFS, Samba, and NetWare network file systems
Network: script that activates the configured network interface
NFS: Open NFS Services
PORTMAP:RPC Portmap Manager, which manages the connections based on RPC services
SendMail: Mail server SendMail
Smb:samba file sharing/printing services
Syslog: A script that lets the system boot the syslog and KLOGD system log waiting process
xfs:x window font server, providing font sets for local and remote X servers
XINETD: Support a variety of network services Core Daemon, can manage wuftp, sshd, Telnet and other services

These daemons are also started, the RC program is done, and then it returns to Init to continue to the next step.

Part V: Establishing terminals

After the RC has finished executing, return init. At this point the basic system environment has been set up, and various daemons have been started. Init will then open 6 terminals for the user to log on to the system. You can switch between these 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 at 2, 3, 4, 5 running level will be respawn way to run the Mingetty program, mingetty program can open the terminal, set mode. At the same time it will display a text login interface, which we often see the login interface, in this login interface will prompt the user to enter the user name, and the user entered the user as a parameter to the login program to verify the identity of the user.

Part VI: Login system, Boot complete

For users with a graphical way to run at level 5, their login is through a graphical login interface. After the successful login can go directly to KDE, GNOME and other window manager. And this article is mainly about the text of the way to log in:

When we see the Mingetty login interface, we can enter the username and password to login to the system.

Linux Account Verification Program is Login,login will receive mingetty from the user name of the username parameters. Login then analyzes 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 when the system is maintained. 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 searches/etc/passwd and/etc/shadow to verify the password and set other information about the account, such as what the home directory is, and what shell to use. If no home directory is specified, the default is the root directory, and if no shell is specified, the default is/bin/bash.

When the login program succeeds, it outputs the most recent login information (recorded in/var/log/lastlog) to the corresponding terminal, and checks to see if the user has any new mail (in/usr/spool/mail/'s corresponding user's list). Then start 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. After all the configuration files have been executed, the various environment variables are set up, and a familiar command prompt appears, and the entire startup process is over.

It is hoped that the above analysis of Linux startup process will help those who want to learn more about Linux users to build a relevant Linux startup process of clear concepts, and then can further study how Linux next work.