Linux Boot Process

Steps for the boot process

The typical boot process for a Linux system consists of the following 6 different phases:

Loading and initializing the kernel

Detecting and configuring devices

Creating Kernel Threads

Operator intervention

Execute the System startup script

Multi-user mode operation

System administrators have little control over most of these steps. We can influence most boot configurations by editing the system startup script.

Initializing the kernel

The Linux kernel itself is a program, and the first task in the system boot process is to load the program into memory in order to execute it. The path name of the kernel is usually/vmlinuz or/boot/vmlinuz.

The Linux system implements a two-stage loading process. In the first stage, the system ROM loads a small boot program from disk into memory. Then, the program is then scheduled to load into the kernel.

The kernel performs memory detection to determine how much RAM is available. Some internal data structures of the kernel allocate their memory statically, so when the kernel starts, it divides itself into a fixed-size

The actual storage space. This space is reserved for kernel use and user-level processes cannot be used. The kernel prints a message on the console that reports the total amount of physical memory and the amount of memory available to the user process.

Configuring hardware

One of the first tasks that the kernel performs involves checking the machine's environment to determine what hardware the machine has. When you build a kernel for your own system, it's a good way to find out what hardware devices it finds. When the kernel starts executing, it

Try to find and initialize every device that has been told about it. Most cores print a single line of specialized information for each device they find. The current release contains kernels that can run on most Sohu machine configurations.

Just do the minimum amount of customization.

The device information provided during kernel configuration is often not clear. In such a case, the kernel tries other information it needs by detecting the device bus and seeking information from the appropriate driver. Those that didn't detect the device

Drivers, or those that do not respond to probing, will be disabled. If a device is later connected to the system, it is still possible to load or start its driver at any time.

Kernel threads

Once the basic initialization task has been completed, the kernel creates several "spontaneous" processes in the user space. They are referred to as spontaneous processes because these processes do not pass the formal fork of the system

Created by the mechanism.

The number and characteristics of spontaneous processes vary with the system. On Linux, there are no PID 0 processes to see. Together with the process Init are a few memory and kernel processing processes, these processes are relatively small PID

Their names are enclosed in brackets in the output of the PS command. Sometimes the names of these processes end with a slash and a number. This number indicates which processor the thread is running on,

This interesting situation can occur on multiprocessor systems.

In all of these processes, only Init is a fully-validated user process. Other processes are actually part of the kernel, dressed up for scheduling or structural reasons, to make them look

It's like a process.

Once the spontaneous process has been created, the kernel's task in the boot phase is complete. However, none of the processes that handle the basic operations have been created, and most Linux daemons are not started. This one

The task is the responsibility of init.

Operator intervention

If the system is booted in single-user mode, the command-line flag (single) given by the kernel when Init is started notifies the init that the actual boot is in one-user mode. Process Init will end up controlling the power

To Sulogin, which is a "middle but not controllable" version of login, which prompts the user to enter the root password. If you enter the correct password, the system will generate a root shell.

The way commands are executed in a single-user shell is similar to that of executing commands on a fully booted system. However, on SuSE, Debian, and Ubantu systems, the root is usually installed

Partition. In order to use programs that are not in/bin,/sbin, or/etc, the user must manually install additional file systems.

In many but user environments, the root directory of the file system is installed as read-only. If/TMP is part of the root file system, many commands to use temporary files cannot be executed. In order to solve

This problem, you must first reinstall the root file system read-write, and then start the interactive operation of user mode. The following command usually implements this technique.

Mount-o REMOUNT,RW/

Execute startup script

By the time the system is ready to run its startup script, we can see that it is a Linux system. Although it does not look much like a fully-booted system, there is nothing in the next boot process

"Wonderful" step. The startup script is a normal shell script that is selected and run by Init based on the moving algorithm, although the algorithm is sometimes complicated, but the box is easy to understand.

The processing, feeding, and categorization of startup scripts are described in their own special section.

Multi-user Run

After the initialization script has run, the system is fully operational, but now the user cannot log in. In order to accept user login on a specific terminal, there must be a Getty Process listening terminal

or console. Init generates these Getty processes directly, completing the boot process. Init is also responsible for generating graphical login systems, such as XDM or GDM.

Linux Boot Process