Initial Linux startup process

When the user powers on the PC, BIOS boot self-check, start according to the boot device set in BIOS (usually hard disk), then start the boot program lilo or grub installed on the device to boot Linux, linux first performs kernel boot, and then executes the init Program. the init Program calls rc. sys...

When the user powers on the PC, BIOS boot self-check, start according to the boot device set in BIOS (usually hard disk), then start the boot program lilo or grub installed on the device to boot Linux, linux first performs kernel boot, and then executes the init Program. the init Program calls rc. sysinit and rc programs, rc. after completing system initialization and running service tasks, sysinit and rc return init; init starts mingetty and opens the terminal for users to log on to the system. after the user logs on to the system, the user enters Shell, this completes the entire startup process from boot to login.

 

The following describes several key parts one by one:

Part 1: kernel boot (kernel boot)

Red Hat9.0 can use boot programs such as lilo or grub to start guiding the Linux system. after the boot program successfully completes the boot task, Linux takes control of the CPU from them, then the CPU starts to execute the Linux core image code and starts the Linux startup process. Here we use several assembler programs to guide Linux. This step is generic to the files under "arch/i386/boot" in the Linux source code tree: bootsect. s, setup. s, video. s.

Bootsect. S is the source code for generating the boot sector. after loading, it directly jumps to the program entry of setup. S. The main function of setup. S is to copy system parameters (including memory and disk, which are returned by the BIOS) to the special memory so that the codes in the protected mode of these parameters can be read in the future. In addition, setup. S includes the code in video. S to detect and set the display and display modes. Finally, setup. S converts the system to the protection mode and jumps to 0x100000.

So what code is stored in the memory address 0x100000? Where did these codes come from?

The memory address 0x100000 stores the decompressed kernel, because the kernel provided by Red Hat contains a large number of drivers and functions, therefore, the "makebzImage" method is used in kernel compilation to generate a compressed kernel. in RedHat, the kernel is often named vmlinuz. during the initial Linux boot process, is passed through the head in "arch/i386/boot/compressed. S uses misc. run the decompress_kernel () function defined in c to decompress the kernel vmlinuz to 0x100000.

When the CPU jumps to 0x100000, startup_32 in "arch/i386/kernel/head. S" will be executed. it is also the entrance of vmlinux, and then jumps to start_kernel. Start_kernel () is a function defined in "init/main. c". start_kernel () calls a series of initialization functions to complete the setting of the kernel itself. The start_kernel () function does a lot of work to build a basic Linux core environment. If start_kernel () is successfully executed, the basic Linux core environment has been established.

At the end of start_kernel (), by calling the init () function, the system creates the first core thread and starts the init process. The core thread init () is mainly used to initialize peripherals, including calling do_basic_setup () to load and initialize peripherals and their drivers. Complete file system initialization and root file system installation.

When the do_basic_setup () function returns init (), init () opens the/dev/console device again and redirects the three standard input/output files stdin, stdout, and stderr to the console. finally, search for the init Program in the file system (or the program specified by the init = command line parameter), and use the execve () system call to load and execute the init Program. The init () function ends, and the kernel boot part ends,

 

Part 2: run init

The init process number is 1. from this point, we can see that the init process is the starting point of all processes in the system. After Linux completes the kernel boot, it starts to run the init Program ,. The init Program needs to read the configuration file/etc/inittab. Inittab is an unexecutable text file consisting of several lines of commands. In the Redhat system, the content of the inittab is as follows (comments starting with "###" are added to the author ):

#
# Inittab This file describes how the INIT process shocould 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 (Do NOT set initdefault to this)
#1-Single user mode
#2-Multiuser, without NFS (The same as 3, if you do not havenetworking)
#3-Full multiuser mode
#4-unused
#5-X11
#6-reboot (Do NOT set initdefault to this)
#
### Indicates that the current default running level is 5 (initdefault );
Id: 5: initdefault:

### Automatically execute the/etc/rc. d/rc. sysinit script (sysinit) at startup)
# 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
### When the running level is 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

### Allow restarting the system by CTRL-ALT-DELETE during startup
# Trap CTRL-ALT-DELETE
Ca: ctrlaltdel:/sbin/shutdown-t3-r now

# When our 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, of course, assume you have powerd installed and your
# UPS connected and working correctly.
Pf: powerfail:/sbin/shutdown-f-h + 2 "Power Failure; System Shutting Down"

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

### Run the/sbin/mingetty program with ttyX as the parameter at level 2, 3, 4, and 5, and enable the ttyX terminal for user login,
### If the process exits, run the mingetty program (respawn) again)
# 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

### Run The xdm program at level 5, provide the xdm graphical login interface, and re-execute (respawn) upon exit)
# Run xdm in runlevel 5
X: 5: respawn:/etc/X11/preofdm-nodaemon

 

The preceding inittab file is used as an example to describe the inittab format. The row starting with # is a comment row. Each row has the following format except the comment row:

Id: runlevel: action: process

The detailed explanations of the above items are as follows:

1. id

Id refers to the entry identifier, which is a string. for other login program items such as getty or mingetty, the id must be the same as the tty number; otherwise, the getty program will not work properly.

2. runlevel

Runlevel is the identifier of the running level of init. it is generally 0-6 and S or s. The running levels 0, 1, and 6 are retained by the system. among them, 0 is used as the shutdown action, 1 is used as the restart to the single-user mode, and 6 is used as the restart; S and s share the same meaning, indicating the single-user mode, the inittab file is not required, so it does not appear in inittab. In fact, when you enter single-user mode, init runs/sbin/sulogin directly on the console (/dev/console. In general system implementation, 2, 3, 4, and 5 are used. in the Redhat system, 2 indicates that the multi-user mode is not supported by NFS, 3 indicates full multi-user mode (also the most common level), 4 is reserved for user customization, and 5 indicates XDM graphical login mode. The 7-9 level can also be used. traditional Unix systems do not define these levels. Runlevel can be multiple parallel values to match multiple running levels. for most actions, runlevel is executed only when it matches the current running level.

3. action

Action describes the running mode of the subsequent process. Optional values of action include initdefault, sysinit, boot, and bootwait:

Initdefault is a special action value used to identify the default startup level. when init is activated by the core, it reads the initdefault item in inittab and obtains the runlevel, as the current running level. If there is no inittab file or there is no initdefault item, init will request to enter runlevel on the console.

Actions such as sysinit, boot, and bootwait will run unconditionally when the system is started, ignoring runlevel.

Other actions (excluding initdefault) are related to a certain runlevel. The definitions of each action are described in detail in the man manual of inittab.

4. process

Process is the specific execution program. The program can be followed by parameters.

Part 3: System initialization

There is such a line in the init configuration file:

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

It calls/etc/rc. d/rc. sysinit, while rc. sysinit is a bash shell script mainly used to complete system initialization, rc. sysinit is an important script to run at every running level. It mainly includes activating swap partitions, checking disks, loading hardware modules, and other tasks that require priority.

Rc. sysinit has more than 850 lines, but each single function is relatively simple and has annotations. it is recommended that interested users read the file on their own machines, to learn more about system initialization. This file is long, so it is not listed in this article, and will not be described in detail.

After the rc. sysinit program is executed, the system returns init to continue the next step.

 

Part 4: Start the running daemon

After rc. sysinit is executed, init will be returned to continue other actions. Normally, the/etc/rc. d/rc program will be executed next. Taking runtime level 3 as an example, init will execute the following line in the configuration file inittab:

L5: 5: wait:/etc/rc. d/rc 5

This line indicates running/etc/rc with 5 as the parameter. d/rc,/etc/rc. d/rc is a Shell script that accepts 5 as the parameter and executes/etc/rc. d/rc5.d/all rc startup scripts in the directory,/etc/rc. in the d/rc5.d/directory, these startup scripts are actually some link files, rather than the real rc startup scripts. The real rc startup scripts are actually stored in/etc/rc. d/init. d/directory. These rc boot scripts have similar usage. they generally accept parameters such as start, stop, restart, and status.

The rc startup script in/etc/rc. d/rc5.d/is usually a link file starting with K or S. for a startup script starting with S, it will run with the start parameter. If the corresponding script is found to have a K-header link, and it is already in the running state (marked by a file under/var/lock/subsys ), stop the started daemon with the stop parameter and run the Daemon again. This ensures that all related daemon will be restarted when init changes the running level.

You can use chkconfig or "System Services" in setup to set which daemon will run at each running level. Common daemon processes include:

Amd: automatically installs the NFS daemon.
Apmd: advanced power management daemon
Arpwatch: records logs and constructs an Ethernet address and IP address pair database that is visible on the LAN interface.
Autofs: automatically installs the management process automount, which is related to NFS and relies on NIS.
Crond: the Daemon of scheduled tasks in Linux
Named: DNS server
Netfs: install NFS, Samba, and NetWare network file systems
Network: activate the script program with configured network interfaces
Nfs: enable the NFS service
Portmap: RPC portmap manager, which manages RPC-based connections
Sendmail: sendmail
Smb: Samba file sharing/printing service
Syslog: a script that enables syslog and klogd system logs to wait for processes during system boot.
Xfs: X Window Server, which provides a font set for local and remote X servers
Xinetd: supports core daemon processes of multiple network services and manages services such as wuftp, sshd, and telnet.

These daemon processes are also started, the rc program is executed, and the init is returned to continue the next step.

 

 

Part 5: establish a terminal

After the rc is executed, init is returned. At this time, the basic system environment has been set and various daemon processes have been started. Init will then open six terminals so that users can log on to the system. You can switch between the six terminals by pressing Alt + Fn (n corresponds to 1-6. The following six lines in the inittab define six 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, we can see that the mingetty program will be run in the respawn mode in the 2, 3, 4, and 5 running levels. the mingetty program can open the terminal and set the mode. At the same time, it will display a text logon interface, which is a logon interface we often see. in this logon interface, a user is prompted to enter the user name, the user input will be passed as a parameter to the login program to verify the user's identity.

Part 6: log on to the system and start the system

For graphical users with a running level of 5, their logon is through a graphical logon interface. After successful logon, you can directly go to the KDE, Gnome, and other window managers. This article focuses on text-based logon:

When we see the mingetty logon interface, we can enter the user name and password to log on to the system.

In Linux, the account verification program is login. login receives the username sent from mingetty as the username parameter. Login analyzes the user name. if the user name is not root and the/etc/nologin file exists, login outputs the content of the nologin file and then exits. This is usually used to prevent non-root user logon during system maintenance. Only terminals registered in/etc/securetty allow the root user to log on. If this file does not exist, the root user can log on to any terminal. The/etc/usertty file is used to add access restrictions to users. If this file does not exist, there are no other restrictions.

After the username is analyzed, login searches for/etc/passwd and/etc/shadow to verify the password and set other information about the account, such as what is the main directory and what shell is used. If no main directory is specified, the root directory is used by default. If no shell is specified,/bin/bash is used by default.

After the login program is successful, the last logon information (recorded in/var/log/lastlog) is output to the corresponding terminal ), check whether the user has any new emails (in the directory of the corresponding user name of/usr/spool/mail ). Then set various environment variables: For bash, the system first looks for the/etc/profile script file and runs it. then, if the user's main directory exists. execute the bash_profile file. other configuration files may be called in these files. after all the configuration files are executed, various environment variables are also set, A familiar command line prompt will appear, and the entire startup process ends.

We hope that the analysis of the Linux startup process will help those who want to learn more about the Linux startup process, and further study how Linux will work next.

Author: Birds"