Linux (RHEL6) boot process detailed

Linux (RHEL6) boot process detailed

Linux (Red Hat RHEL6) boot process detailed:
An important and powerful aspect of RHEL is that it is open source, and the system's startup process is user configurable. Users are free to configure many aspects of the startup process, including the ability to specify which programs to run at startup. Similarly, the process to be terminated when the system shuts down is also organized and configured, even if the customization of the process is seldom required.
Understanding how the system's startup and shutdown processes are implemented not only allows customization, but also makes it easier to handle failures related to startup or shutdown of the system.

1. Start-up process
Here are a few basic stages of the startup process:
The ① system loads and allows boot loader. The details of this process depend on the architecture of the system. For example:
BIOS-based x86 system This first stage of running boot loader begins with the MBR of the primary hard disk, and then an additional boot loader, grub, is loaded.
UEFI-based x86 system to mount an EFI system partition that contains the Grub boot loader. The EFI Boot Manager loads and runs the Grub bootstrapper in the form of an EFI application.
For power systems servers, you need to mount a PPC prep partition that contains the Yaboot boot loader. The Yaboot bootstrapper is loaded and run by the System Management Services (SMS) boot manager.
For IBM System Z (IBM mainframe), it runs Z/IPL boot loader from a DASD or fcp-connected device.
②boot loader loads the kernel into memory and then loads any required modules in this way and mounts the root partition as read-only.
The ③ kernel transfers control of the boot process to the/sbin/init program.
The ④/sbin/init program loads all the services and user space tools and mounts all the partitions listed in the/etc/fstab.
⑤ the login screen appears and the user logs on to the newly launched system.

2. Details of the startup process
The initial stages of the start-up process vary depending on the hardware platform. However, once the kernel is discovered and loaded by boot loader, then the boot process is the same on all the architecture platforms. The following are mainly described in the x86 architecture platform.
㈠ Firmware Interface

① BIOS-based x86 system
The BIOS is a first step in controlling not only the boot process, but also the firmware interface that provides the lowest interface for peripherals. On x86 system devices equipped with a BIOS, the BIOS program is written to read-only and permanently stored memory (that is, ROM) and remains available. When the system starts, the processor (that is, the CPU) reads the BIOS program from the last (or highest) address segment of the memory and runs it.
Once the BIOS program is loaded, the BIOS verifies the system, locates and detects peripherals, and then locates a device that can effectively boot the system. Typically, it checks the optical drive or whether the USB device can boot, if the check fails, and then detects the system hard disk. In most cases, the lookup order of bootable drives is controlled by the relevant settings in the BIOS. In an IDE device, it looks at whether the primary IDE device on the primary IDE bus can start the system. On a SATA device, it will see which SATA device has the boot tag set. The BIOS then loads the program (called MBR, master boot record) that is saved in the first sector on the device to the memory. The MBR has a size of only 512 bytes, which contains machine code instructions for starting the machine, called boot loader, and also contains a partitioned table. Once the BIOS finds and loads the boot loader into memory, the BIOS transfers control of the boot process to it.

The first stage of the boot loader is a small piece of binary machine code on the MBR. Its only function is to locate the second stage of boot loader (GRUB) and load the first part of it (grub) into memory.


(Note: When the machine is a power-up BIOS program will be loaded into main memory in a known shadow RAM in the storage area, because the address in the shadow RAM is the ROM BIOS address space mapping, both of the address space is identical, so the CPU directly to shadow RAM for access, and much faster than directly accessing the ROM. ）
② UEFI-based x86 system
UEFI (i.e., Unified extensible Firmware Interface, Universal Firmware Interface) like the BIOS, It is designed to control the startup process (provided by starting the service) and provides an interface between the system firmware and the operating system (provided through the runtime Service). Unlike the BIOS, it has its own architecture, does not depend on the CPU, and it has its own device drivers. UEFI can mount partitions and read some file systems.

When a UEFI-equipped x86 computer starts, UEFI will look for a system storage partition marked with a GUID (globally unique identifier) and mark the partition as ESP (that is, EFI System Partition). This partition contains the applications that are compiled into the EFI architecture, which contain the system's bootloader and utility software. The UEFI system contains an EFI boot manager that can start the system from a default configuration, or prompt the user to select a system to boot. When a system is selected, either manually or passively, Uefi reads the corresponding bootloader into memory and transfers control of the boot process to bootloader.

㈡ boot loader--the boot Loader
①x86 boot loader for system architecture Grub
The system loads grub into memory, how grub is loaded as in memory: one is booting directly from the first stage of the bootloader to grub in the machine with the BIOS installed, or it is read directly from the EFI system partition on a UEFI-equipped machine.

At boot time, Grub bootloader can read the partition of the Ext2,ext3,ext4 file system and load its configuration file--/boot/grub/grub.conf (for BIOS-based) or/boot/efi/efi/redhat/ Grub.conf (for UEFI).
(Note: In RHEL6, the GRUB bootloader supports the Ext2,ext3,ext4 file system.) It does not support other like vfat,btrfs or XFS, or LVM, which means that the filesystem containing the/boot directory must be the Ext2,ext3,ext4 file system, and the rest is not possible. ）

Once the second stage of bootloader enters memory, it will display graphically on the screen to require a different operating system, or the kernel, to allow the user to select the system or kernel to boot (note: When updating the kernel, the bootloader configuration file will be automatically updated).

Once the second phase of the bootloader determines which kernel to start. It will find the corresponding kernel binaries in the/boot directory. The naming format for kernel binaries is:/boot/vmlinuz-<kernel-version>. Where <kernel-version> as long as the/boot/grub/grub.conf, the same can be specified.

Then, Bootloader is putting the INITRAMFS image into memory. The Initramfs is used by the kernel to load the necessary drivers and modules for booting the system. This image file is very important for computers that have SCSI or that use the Ext3,ext4 file system.

Once the kernel and INITRAMFS images are loaded into memory, bootloader transfers control of the boot process to the kernel. The kernel then transfers control over the boot process to the init command.

② boot loader for other system architectures
Except for the boot program that is used to find and load the kernel, the other boot process is exactly the same.

㈢ kernel
When the kernel is loaded, it initializes and configures the computer's memory immediately, configuring various hardware that is attached to the system, including the CPU,I/O subsystem and storage devices. Then find the Initramfs image file and load it into memory, then unzip it directly to the/sysroot/and load all the necessary drivers. Next, it initializes the devices associated with the file system, such as LVM and soft raid. Then the kernel creates a root device and mounts it in a read-only manner. In this, the kernel has basically done all the work and can operate. However, because the user is not allowed to enter the operation at this time, it is not possible to do more. Therefore, in order to set up the user environment, the kernel starts executing the/SBIN/INIT program.

㈣/sbin/init Program
The/sbin/init program completes the rest of the boot process and configures the user environment.
When the init command is started, it becomes the parent process for all automatically started processes. First, it runs the/etc/rc.d/rc.sysinit script, which is the role of setting environment variables, starting swap, checking the file system, and performing all the other steps necessary for system initialization. For example, most systems want to use a clock, and Rc.sysinit also reads the/etc/sysconfig/clock configuration file to initialize the hardware's clock. Again, if there is a more special serial port process needs to be initialized, then, Rc.sysinit will also execute/etc/rc.serial files and so on.

The init command then processes the jobs under the/ETC/EVENT.D directory, which is used to describe how the system sets the runlevel of each SYSV init. RunLevel is a state or pattern defined by the various services listed in the/etc/rc.d/rc<x>.d/directory, where <x> represents the level of operation. Immediately after, the init command sets the source function library--/etc/rc.d/init.d/functions, which is used to configure how to start, stop the process, and determine the program PID.

The INIT program uses the runlevel specified in/etc/inittab to find the corresponding RC directory, and then launches all background processes under the corresponding directory. For example, if the RunLevel in/etc/inittab is 5, the INIT program will find the/ETC/RC.D/RC5.D directory and then decide which processes to start or stop based on the list of/etc/rc.d/rc5.d directories. In fact, there is no real script to start or stop the service in the/ETC/RC.D/RC5.D directory, all files under the/ETC/RC.D/RC5.D directory are just symbolic links to the corresponding files in the/ETC/RC.D/INIT.D directory. Each of these symbolic link files begins with ' K ' or ' S '. Linked files that begin with ' K ' are not started at the corresponding runlevel. The link file that begins with ' S ' is started at the corresponding runlevel.

The init command begins by sending the/etc/rc.d/init.d/<command> Stop command to stop all symbolic link files that begin with ' K ' in all corresponding runlevel directories, where,<command> Refers to a service or process that needs to be stopped. Then, by sending/etc/rc.d/init.d/<command> start, all symbolic link files beginning with ' S ' in the directory corresponding to the RunLevel are started.

The starting order of each symbolic link file is determined by the number behind ' K ' or ' S '. The lower the number, the sooner it starts. If the numbers are the same, they are started sequentially in the order of the letters following the numbers. We can determine the order in which the service or process starts by modifying the size of the number.

Note: One of the last files of the INIT program to execute is the/etc/rc.d/rc.local file. This file is used primarily for user-defined use.

After the init command finishes processing all the services in the RC directory at the corresponding runlevel, Init immediately invokes a/sbin/mingetty program for each virtual Console and assigns it to the corresponding runlevel defined in the/ETC/EVENT.D directory. Run level 2-5 has six virtual consoles. Run Level 1 has one, running levels 0 and 6 are not. The/sbin/mingetty process opens the path of communication with the TTY device, which allows you to set the mode of the TTY device, print the login prompt, receive the user's username and password, and initialize the login process. At run Level 5, Init runs a script called/ETC/X11/PREFDM, and the script launches the X Display Manager (GDM,KDM,XDM) based on what is configured in the file/etc/sysconfig/desktop.

㈤job definition
Previously, the Sysvinit package provided the default configuration for the init daemon. When the system starts, the init daemon runs the/etc/inittab script and runs the service process at the corresponding runlevel. The default configuration for the init daemon now uses the event-driven form, which is provided by the upstart package. Whenever a special event occurs, the init daemon processes the jobs stored in the/ETC/EVENT.D directory. The init daemon identifies the boot of the system as an event.

Typically, each job specifies a program, and the program is run or stopped in the form of an event that triggers the init. Some jobs are like batch tasks, performing actions and terminating when another triggering event triggers the job. Some jobs, like services, are always running until another event or user stops it.

This article is from the "Everything Possible" blog, please be sure to keep this source http://noican.blog.51cto.com/4081966/1656582

Linux (RHEL6) boot process detailed