A detailed description of the Linux operating system boot process

As the operating system is becoming more and more complex, the process of booting and shutting down power is becoming more and more intelligent. Moving from a simple DOS system to a Windows NT system, people have experienced these changes-not just the boot and shutdown of the core operating system, but also the need to start or shut down a significant number of service items at the same time. Similar to the Windows Nt,linux system startup process, the number of service items that need to be opened is also significant.

Here, we assume that you are already familiar with the boot process of other operating systems and understand the self-test boot steps of the hardware, starting with the boot loader of the Linux operating system (usually lilo for personal computers) and introducing the Linux boot steps.

Load kernel

After Lilo starts, if you choose Linux as the boot-ready operating system, the first thing to be loaded is the kernel. Keep in mind that there are no operating systems in the computer's memory at this time, and the PC (because of their natural design flaws) has not yet been able to access all the memory on the machine. As a result, the kernel must be fully loaded into the first megabyte of available RAM. To achieve this, the kernel is compressed. The header of this file contains the necessary code to set the CPU into Safe mode (to remove the memory limit) and then decompress the remainder of the kernel.

Execute kernel

After the kernel has been decompressed in memory, it can start running. At this point the kernel only knows its own built-in functions, that is, the kernel part of the module is compiled to not be used. Most fundamentally, the kernel must have enough code to set up its own virtual memory subsystem and root filesystem (usually the ext2 file system). Once the kernel is up and running, the hardware detection determines which device drivers need to be initialized. From here, the kernel is able to mount the root filesystem (a process similar to that used by Windows to identify and access C-disk). After the kernel has mounted the root file system, a program called Init is started and run.

Note: Here we deliberately omit many of the details of the Linux kernel boot, and these details are only of interest to the kernel developers. If you are curious, you can visit the "Kernel Hackers Guide" at the http://www.redhat.com:8080 address.

Init process

The init process is first run in a non-kernel process, so its process number PID value is always 1. Init reads its configuration file/etc/inittab, which determines the RunLevel (Runlevel) that needs to be started. Fundamentally, the runlevel specifies the behavior of the system as a whole, with each level (represented by an integer from 0 to 6) that satisfies a specific purpose. If the initdefault level is defined, the value is directly selected, otherwise the user is required to enter a numeric value that represents the run level.

After entering a number representing the run level, Init executes a command script based on the definition in the/etc/inittab file. The default runlevel depends on the selection of the logon program during the installation phase: whether to use text-based or X-window-based login programs.

RC Command Script Program

We already know that when the runlevel changes, it is up to the/etc/inittab file to define which command script to run. These command scripts are responsible for starting or stopping various services that are specific to that runlevel. Because of the large number of services that need to be managed, you need to use the RC command script. One of the most important is/ETC/RC.D/RC, which is responsible for invoking the appropriate command script for each runlevel in the correct order. We can imagine that such a command script could easily become unmanageable! In order to prevent such events from happening, a well-designed scheme is needed.

for each runlevel, there is a subordinate directory within the/ETC/RC.D subdirectory. The naming method for the subordinate subdirectories of these runlevel is RCX.D, where x is the number representing the run level. For example, all command scripts running level 3 are stored in the/ETC/RC.D/RC3.D subdirectory.

in each run-level subdirectory, a symbolic link to the command script in the/ETC/RC.D/INIT.D subdirectory is established, but these symbolic links do not use the original name of the command script in the/ETC/RC.D/INIT.D subdirectory. If the command script is used to start a service, its symbolic link name begins with the letter S; if the command script is used to close a service, its symbolic link will begin with the letter K.

To write your own RC command script

In the days of maintaining the Linux system, it is certain that the system administrator will need to modify the boot or shutdown command scripts. There are two ways to achieve the purpose of the modification:

If the changes are only useful when booting the boot, and the changes are not significant, consider simply editing the/etc/rc.d/rc.local script. This command script is executed at the last step of the boot process.

If you make a fine-grained modification, or require the shutdown process to be explicitly stopped, you need to add a command script to the/ETC/RC.D/INIT.D subdirectory. This command script must be able to accept the start and stop parameters and complete the appropriate operation.

The first method, edit the/etc/rc.d/rc.local script, of course, is relatively simple in both methods. If you want to add content to this command script, just open it with your favorite editor program and append the command you intend to execute to the end of the file. This is really handy for the one or two-line revision.

If you do need to use a command script, you must select the second method. The process of writing an RC command script is not as difficult as it might seem. Let's give an example to see how it's done (by the way, you can use our example as a template to modify and add as you want).

Suppose you intend to call a special program every 60 minutes to pop up a message reminding yourself that you need to take a break from the front of the keyboard, and the command script will include the following sections:

A description of the command script function (so that it will not be forgotten after one year);

Verify that this command script exists before attempting to run it;

Accept the start and stop parameters and perform the required actions.

After the parameter is given, we can write a script for the command. This program is very simple, you can write it yourself, I do not give it here.

After you have written a new command script, you can control the start or stop of the command script by adding the necessary symbolic links from the relevant run-level subdirectories. In my mind, I just want it to start at run Level 3 or run Level 5, because I think only these two levels of runlevel are the work of the day. Finally, it is expected that this command script will be turned off when it enters RunLevel 6 (reboot).

Activating or prohibiting a service item

Sometimes it is found that a particular service is not required to be started at boot time. This is especially true if you are considering replacing Windows NT file and print servers with Linux.

We already know that by changing the name of a symbolic link in a specific runlevel subdirectory, you can let the service not be started, such as changing the first letter of its name from S to K. Once you have mastered the command line and symbolic links, you will find that this is the quickest way to activate or disable the service.

When learning this renaming method, you may find the graphical interface ksysv easier to master. Although it was originally designed for use in KDE environments, it also works well in the GNOME environment, which is installed by default in Red Hat Linux 7.2. If you want to start it, simply open a xterm window and enter the KSYSV command. A window appears, listing all the parameters that can be modified, including online help when needed.

Warning: If you are learning the knowledge of this article in a real-world system, use common sense. When trying to make changes to the startup script, keep in mind that the changes you make may cause your system to not work properly and that it cannot be resumed with a restart. Do not experiment with new settings on a functioning system, and back up all the files you are ready to modify. The most important thing is to prepare a boot disk safekeeping at hand.

This article from "Jacksky blog" blog, declined reprint!

A detailed description of the Linux operating system boot process