Standard process for booting Linux systems

system Start-up refers to the whole process of power-up from the computer to display the user's login prompt. We will be here to discuss the whole process and some of the related content . The process can be divided into two stages: loading the kernel and preparing the operating environment, we discuss separately. The discussion in this section is based only on the i386 hardware architecture, but most of the content is common.

Figure A Overview of the startup process

load the kernel (load the kernel into memory and pass control over to it)

computer power to boot loader began to work, the hardware content is much larger than the software content, so it is not mentioned here, if you really care about friends, please do not worry, we will discuss it in the next issue.

This stage is the main battlefield of Boot Loader. It must upload the executable kernel image and the additional data information needed for the kernel boot from the storage media into memory, which is not an easy task, as it is possible to upload from external media such as the network boot server, in addition to loading from the hard disk. A variety of miscellaneous file system types also pose a huge challenge to onboarding.

The Boot Loader may also need to change the operating privilege level of the CPU, and then the kernel can be put into operation.

In addition to this, boot Loader has other functions such as obtaining system information from the BIOS, or extracting information from command-line parameters at startup. Some boot Loader also play the role of the boot selection tool, allowing users to choose different operating systems.

Boot Loader's Responsibilities:

L determine exactly what to load, which can require the user to choose

L Load the kernel and the related data it may need, such as INITRD or other parameters

L Prepare the operating environment for the kernel, for example, to get the CPU into privileged mode

L put the kernel to work

The historical changes of Boot loader:

Early Linux only supported the floppy boot sector and shoelace two boot Loader. Shoelace is a file system-related Boot Loader inherited from Minix. It only supports the Minix file system. Linux used only Minix A file system at that time, so it was no problem doing so. However, the Minix file system cannot save the creation, modification, and access time information; The file name length is limited to 14 bytes and so on. With the development of Linux, these shortcomings of the traditional UNIX file system are more and more unbearable, it is not suitable for Linux as the main file system.

To support the implementation of other file systems, Linux introduces the VFS (virtual file system). This move quickly aroused a warm response, a large number of new file system implementation appeared. One of the   minix   variant of File system, extended file system   Xiafs (named according to its author) broke through   minix   file system filename length limit, which increases this length to all 30 characters at a stroke. The competition between the file systems was fierce, and it was hard to see who would win, or whether there would be a final "winner".

Despite the uncertainty, one thing is clear: regardless of which filesystem is favored, no one can boot from the hard disk except Minix as the root file system. Because shoelace only supports Minix file systems. Lilo was born. Due to the support of a variety of file systems (then the kernel supported by the mainstream file system has Minix , extended file system ext, Xiafs. There are people who transplant BSD FFS, it is impossible to see when the end of time is too difficult to achieve and maintenance, and the boot Loader should not become a stumbling block for people to test the new file system, so Lilo took a file-system-independent design.

This design has withstood the test of time and proved to be very successful. Even today, Lilo can still boot from the hard disk of most file systems supported by the kernel. However, since ext2 after such a long period of time has not greatly evolved, became the de facto standard, so with the file system-related boot loader gradually became popular.

Although Ext2 has been able to meet the daily needs of most people, file system Designers are developing new file systems characterized by logging mechanisms and have made considerable progress. The need for a file system-independent boot loader may become stronger again, given the current possibility of multiple file system implementations coexisting simultaneously.

Initializing the basic operating environment

Once the kernel starts running, it initializes the internal data structure, detects the hardware, and activates the appropriate driver for the application's ready-to-run environment. The period contains an important action-the application software must have a file system in its operating environment, so the kernel must first load the root file system. Since our goal is to introduce the basic process, the relevant hardware initialization details are no longer discussed, and the relevant content will be detailed in the next issue of the magazine.

after the hardware initialization is complete, the kernel begins to create the first process-the initial process. Say is created, not really, the process is actually the entire hardware on the initialization process of the continuation, but the implementation here, the logic of the process is complete, so we will follow the process to create the way it is "normalized"-we have this initial process is also called "Hardware Process", It occupies the first position of the process descriptor, so it can be represented by task[0][K1] or Init_task . The process will then create a new process to execute the init () function, in fact, this new process is the first practical process of the system, it will be responsible for the next phase of the initialization operation, and the initial process (Init_ Task) itself begins an idle loop, which means that the only task for the initial process after kernel initialization is to consume idle CPU time when no other process needs to be executed (so the initial process is also known as the Idle process).

The next phase of initialization is a little easier than the previous one, because it is now up to a real process to take over, and the previous phase was done manually by the hardware process. At this stage, the new process created by Init_task needs to initialize the bus, the network, and start the various system kernel background threads in the system, then initialize the peripherals, set the file format, and after that, it will be the final preparation for entering the system-initializing the filesystem, installing the root file system, opening/ Dev/console devices, redirect stdin, stdout, and stderr to the console, then search the init program in the file system and use the execve() system call to load the EXECUTE INIT program. The system has since entered the user state.

Loading the root file system

In order to load the file system, the kernel needs:1, know that the root file system is located on that storage medium, 2 have access to the media driver.

The most common scenario is that the root file system is a ext2 file system located on the IDE's hard disk. The operation required in this case is simple: give the device number as a parameter to the kernel, and the IDE's device drivers are usually compiled into the kernel.

If the kernel does not have a driver for the associated media, the problem becomes more complex. This is not uncommon, as is often the case with the "GENERIC" kernel used by the Linux installation disk. If the kernel contains device drivers for all supported hardware, it will become a monster, and some drivers will affect other devices when detecting hardware.

This problem can be solved by the INITRD mechanism, which allows the Ram file system to be used before loading the actual root file system. In addition to the above two reasons, the introduction of INITRD can also solve the problem of dynamic synthesis of the kernel. (See Resources First .) )

However, we should note that the InitRd is not always available throughout the boot process, it can be said to be a plug-in, in order to solve the above problems, and was added to the boot process, like As shown in figure I, The Linux system can also be started without selecting it.

Why introduce INITRD?

Kernel mirroring must be loaded during Linux boot, and some elements must be considered in this process:

First, the kernel image cannot be too large. Because of the variety of hardware and compatibility limitations, Linux kernel image can not be too large, but this is not easy to do. The core portion of the Linux kernel itself is not small, and it must also include the drivers that will be used.

Second, to support as many hardware devices as possible. We have an important job in the boot process: mount the root filesystem because further data and application software are on it, so our kernel must be able to access the root filesystem. For general users, there is no problem if they use the Ext2 file partition on the IDE hard disk as the root file system. Because either the IDE hard disk or the Ext2 file system, their drivers will certainly be included in the kernel image itself. However, there are some special cases: for example, if we want to release the installation CD for a Linux system, then the drive to the disc is not necessarily included in the kernel. (Some people may be surprised, hey, the kernel image in the CD-ROM not has been read in, how can the kernel also access to the CD?) Note that the boot Loader is read into the kernel image, and the kernel does not have the boot Loader function. If there is no disc driver, how can we install the package on the CD to the user's computer? Pre-compile the driver into the kernel? Sounds good, but if we have some other installation media in addition to the CD, then all of these drivers will make the kernel image huge.

Moreover, there are more serious problems, the various drivers are likely to conflict, especially when the former ISA equipment market dominance, this conflict is simply unavoidable.

The solution at that time was for publishers to provide pre-compiled different cores that supported various devices, put each core into a floppy disk, and hand it over to the user with the release package, and the user chose a floppy disk with the appropriate kernel to boot. or provide users with the tools to make the boot disk, so that users to create their own startup disk before installation. Of course, there is no one way to be satisfied.

The only hope is to use a modular mechanism. When the kernel starts, it calls the appropriate module to load the driver, and then accesses the root file system. Whether through the kernel to further analysis of the device or directly from the user to obtain configuration information, first configure the method of loading the module, can effectively avoid the occurrence of conflicts.

In addition to calling the appropriate modules before installing the root file system, we may still need to call some modules before installing the root file system on the system that completes the installation. This is mainly for the configuration of the computer-generally to different computers for the kernel configuration.

Ideally, the user configures the compiled files according to their actual situation , recompile the kernel, a Step-by-step completion of this work. But few users like this lengthy and highly error-prone job. And the tools are needed to compile and build the kernel, but most users don't need them.

a monolithic kernel can be compiled directly during the installation, but this does not solve the problem well: first, all the compiler tools are needed, and secondly, the probability of failure to complete the task is too great to make a mistake during the compilation process. Therefore, we still need to use the module mechanism: The module mechanism is very reliable, the error is only not to load the corresponding module, will not cause the entire task to fail. Loading the module, as mentioned earlier, is also necessary to get the module before mounting the root filesystem.

For these reasons, Linux introduces the INITRD mechanism.

What do initrd do?

INITRD allows the system to load a RAM disk when it is started, which can be used as a root file system on which the program can run. (There are two meanings, first, the procedure is above; second, the file system environment of the program is also above.) After that, you can mount a new root file system from another device, and the previous root filesystem (INITRD) will be moved to a directory and eventually uninstalled.

Why use a RAM disk? First of all, the use of RAM disk can easily support the future changes, but also to keep the boot Loader work as simple as possible. In addition to kernel mirroring, boot loader reads all relevant information into memory as a file during system boot, and the kernel treats the file as a contiguous block of memory in the boot. That is to use it as a RAM disk. Because of this, this mechanism is called "Initial RAM disk (initial RAM disk)", abbreviated to INITRD.

The INITRD is primarily used to divide the boot of the system into two stages: the initial boot kernel simply retains the minimal set of drivers, and after that, it is loaded from INITRD when the additional module must be loaded when booting.

Operations performed by the INITRD

When using INITRD, a typical system-initiated process becomes:

1) Boot Loader read into kernel image and Initrd file

2) The kernel turns the initrd file into a "normal" RAM disk and frees up the memory used by the Initrd file.

3) INITRD is treated as a root filesystem and is installed in a read-write (read-write) manner.

4) /LINUXRC is executed (it can be any executable file, including scripts; it executes as uid0, and basically does all the work that the INIT program can do)

5) LINUXRC Installing the "actual" root file system

6) The root file system is placed in the root directory by the LINUXRC pivot_root system call.

7) A common startup process, such as calling /sbin/init, starts execution.

8) Uninstall the Initrd file system.

Note that this is a typical process. In fact, the INITRD mechanism can be used in two ways: either as a normal root file system, so that 5th, 62 steps can be skipped, direct execution /sbin/init ( Our test system is to use this method), either as a staging environment, through which the kernel can continue to load the "real" root filesystem.

Standard process for booting Linux systems