Shulou(Shulou.com)06/03 Report--

1 operating system startup process and boot 1.1 GRUB boot manager for centos6 and centos7

GNU GRUB (GRand Unified Bootloader referred to as "GRUB") is a multi-operating system startup program from the GNU project. GRUB is an implementation of the multi-boot specification, which allows users to have multiple operating systems in the computer at the same time and choose which operating system they want to run when the computer starts. GRUB can be used to select different kernels on operating system partitions or to pass boot parameters to those kernels.

GNU GRUB and GRUB are abbreviations for GRand Unified Bootloader, which is a multiple operating system boot manager. Used to boot different systems, such as windows,linux.

The predecessor of GNU GRUB is Grand Unified Bootloader. It is mainly used for Unix-like systems; like most Linux distributions, GNU systems use GNU GRUB as its initiator. Solaris has also used GNU GRUB as the initiator on x86 systems since version 06.

Note: GRUB is currently divided into GRUB legacy and GRUB 2. Version number 0.9x and previous versions are called GRUB Legacy, and those starting with 1.x are called GRUB 2.

In X86 architecture machines, Linux, BSD or other Unix operating systems GRUB, LILO is the most commonly used, should be said to be the mainstream.

When the computer starts, the self-test is first performed by the program in BIOS. After the self-test passes, the Boot Loader program in the MBR of the first bootable disk is found according to the configuration of CMOS (usually in the first physical sector of the boot disk, accounting for 416 bytes), and the control is given to Boot Loader, and Boot Loader further completes the loading of the operating system kernel. When Boot Loader finds the kernel, it gives control to the operating system kernel, and the kernel continues to boot the system.

It can be seen that Boot Loader is the second program to be executed in computer startup, and it is the key program to boot the operating system. The Boot Loader that can boot the operating system mainly includes LiLo, GRUB and MBR programs under Windows. Among them, GRUB is currently the most widely used and excellent boot loader.

The naming of devices by GRUB

First of all, the name of the device in GRUB must be included in parentheses (); secondly, GRUB does not distinguish between IDE hard disk and SCSI hard disk, using hdx, where x specifies the number of the hard disk in BIOS, and counts from 0, and the IDE hard disk number is smaller than the SCSI hard disk; third, GRUB specifies the floppy disk device with fdx, and x is the floppy disk drive number. Here are some examples of device naming by GRUB:

Q (fd0) represents the first floppy disk

Q (hd0,1) represents the second partition of the first hard disk

Q (hd0,0) / boot/vmlinuz represents the vmlinuz file in the boot/ directory under the first partition of the first hard disk. If no partition is specified, the entire device is used, otherwise only the specified partition is used

Q (hd0,2,a) is dedicated to FreeBSD,FreeBSD there is a slice concept that further divides a partition into several slice, which is specified here as slice an in the third partition of the first hard disk.

The execution process of GRUB

When the system is powered on, the program solidified in BIOS first checks the system hardware. After the self-test passes, the MBR on the boot disk is loaded, and the control is handed over to the program (stage1) in MBR. Stage1 executes to determine whether it is GRUB. If it is and configured with stage1_5, load stage1_5, otherwise, load the boot sector. Then, stage2 is loaded and executed, and stage2 drives the file system with the help of stage1_5. And find the grub.conf, display the boot menu for the user to choose, then load the operating system kernel according to the user's choice or default configuration, and give control to the operating system kernel, and the kernel completes the startup of the operating system.

GRUB involves several important files:

The first one is stage1. It is installed in the MBR sector (the first sector of track 0 on face 0) and has a size of 512 bytes (446 byte code + 64 byte partition table + 2 byte flag 55AA). It is responsible for loading the start program stored in the second sector of face 0.

The second one is stage1_5. Stage1_5 is responsible for identifying file systems and loading stage2, so there are often multiple stage1_5 to support reads from different file systems. When installing GRUB, GRUB loads the corresponding stage1_5 to sector 3 of track 0 on side 0, depending on the current / boot/ partition type. Stage1_5 is loaded by start.

The third one is stage2. It is responsible for displaying the startup menu and providing a user interface, and loading the operating system kernel according to the user's choice or default configuration. Unlike the previous two files, stage2 is stored on disk / under boot/grub.

The fourth is menu.lst (link to / boot/grub/grub.conf). Grub.conf is a script-based text file that contains the configuration displayed by the menu and the kernel loading configuration for each operating system. GRUB displays the startup menu according to grub.conf and provides an interactive interface with the user. GRUB loads the corresponding kernel program according to the user's choice or default configuration and the kernel configuration of grub.conf, and gives control to the kernel program, which makes the kernel program complete the startup of the real operating system.

Other important files, GRUB in addition to the main files described above, also include some disk programs that support interactive functions. It mainly includes grub, grub-install, grub-md5-crypt and grub-terminfo and / usr/bin/mbchk under / sbin/, and device image file (device.map) and menu background image file (splash.xpm.gz) under / boot/grub.

From the above analysis and summary, it is easy to see that GRUB actually consists of two parts, one installed in a special sector of the disk and the other in the form of a file. In order for GRUB to start the operating system, you must first install GRUB's stage1 and stage1_5 (automatically choose whether to install or not according to the file system) to a special sector of the disk. In addition, there are grub.conf, device.map and other files and interactive programs under the / boot/grub of the disk, and these programs must be in the path specified by the PATH environment variable. With this knowledge, I believe that it is not very difficult to install, configure, back up or repair GRUB.

Install GRUB to MBR

GRUB's working directory is under / boot/grub, and make install does not install it to / boot/grub. Therefore, after the installation is complete, do the following:

A) copy all the files in the / usr/local/share/grub/i386-pc/ directory to the / boot/grub/ directory (first download the source package for. / configure,make, make install)

# cp / usr/local/share/grub/i386-pc/* / boot/grub/

B) create the grub.conf file under / boot/grub and establish a soft link menu.lst to grub.conf

# cd / boot/grub

# touch grub.conf

# ln-s grub.conf menu.lst

Be careful! If a grub.conf already exists, it's best not to create it again, but to modify it as needed.

C) verify that / usr/local/sbin and / usr/local/bin are in the value of the PATH variable, and execute the following command to check

# env | grep PATH

If you find that / usr/local/sbin and / usr/local/bin are not in the PATH variable, you can modify them with the following command:

# export PATH=$PATH / usr/local/sbin:/usr/local/bin

D) install GRUB to MBR

GRUB is called by BIOS during startup and can only be called if it is placed in MBR, so GRUB must be installed in MBR for BIOS to call. You are actually installing stage1 into MBR, or you may have installed stage1_5 depending on the file system. Here are a few examples of installing GRUB:

# grub-install / dev/hda / / install GRUB to the MBR of the first IDE hard drive

# grub-install / dev/sda// install GRUB to the MBR of the first SCSI hard drive

# grub-install / dev/fd0// install GRUB to floppy disk

# grub-install / dev/hda1// installs GRUB to sector 0 of the first fast disk, which is often chosen when booting the system with other bootstrap programs so as not to overwrite other bootstrap programs.

E) install GRUB in the command line mode of GRUB

For more information about the GRUB command line mode and how to operate it, please refer to section 3. Press c when the startup menu is displayed, or execute the / usr/sbin/grub program on the command line after the system starts, you can enter the command line mode of GRUB. The basic procedure for installing GRUB in command line mode is as follows:

-specify the boot device

Grub > root (hd0,0) # except that there must be spaces after root, there can be no spaces in any other position!

Here (hd0,0) refers to the first partition of the first hard disk. If you cannot determine the partition of the stage1 file that contains GRUB, you can find it through the find directive:

Grub > find / boot/grub/stage1# find stage1

GRUB will look for the file / boot/grub/stage1 and display the name of the device that contains the file, which is the device to be used above.

-install GRUB

Grub > setup (hd0) # except that there must be spaces after setup, there can be no spaces in any other position!

This command will install GRUB on the MBR of the first hard disk. If you do not want to install GRUB in MBR, but want to install GRUB in the boot sector of a partition, you can install it with the following command:

Grub > setup (hd0,0) # except that there must be spaces after setup, there can be no spaces in any other position!

This will install GRUB in the boot sector of the first partition of the first hard disk.

-exit GRUB

Grub > quit

F) restart the machine and the newly installed GRUB will take effect

GRUB profile exampl

Grub.conf is the configuration file of GRUB, its structure is relatively simple, can be divided into two parts, the first step is the global configuration, the other part is the startup configuration of each operating system. There can be menu configurations for multiple operating systems. Here is a concrete example.

# = / sample boot/grub/grub.conf file =

Timeout 30 # time to wait for the user to select a menu item (in seconds), timeout will lead to the default option

Default 0 # default option, first item

Fallback 1 # if the first item goes wrong, start the following backup option

Splashimage= (hd0,0) / grub/splash.xpm.gz # GRUB Startup screen

# the following is the configuration for starting Linux

TitleRed Hat Linux Enterprise AS3 for syd168 # menu title of startup item

Root (hd0,0) # specifies the root file system, the / boot in the first sector of the first hard disk.

The kernel / vmlinuz-2.4.18 ro root=LABEL=/ # kernel is in / boot

Initrd / initrd-2.4.18-14.img # Boot RAM disk under / boot

# the following is the configuration for starting Windows, which is not required if there is only Linux

Title Windows2003 Enterprise for syd168 # Windows launch menu title

Root noverify (hd0,1) # the second partition of the operating system in hd0, not mount

Chainloader + 1 # Boot Windows from the second partition of the first hard drive

# = / sample boot/grub/grub.conf file

The above example simply illustrates the configuration method to start Linux and Windows in GRUB. Please refer to the following for more startup configuration.

5. Boot multi-system configuration

GRUB supports multi-operating system booting. After booting with GRUB, you can enter command line mode or menu mode. You can choose the operating system to boot each partition through flexible command line mode and specify boot parameters. GRUB supports three boot methods, one is to boot the operating system kernel directly, the other is to boot indirectly through chainload, and the third is to boot the operating system through the network.

Linux,FreeBSD,OpenBSD,NetBSD,GUN Mach that GRUB can support can be done through direct boot, but for operating systems that GRUB does not support (such as Windows), the second method, chainload, is needed. Let's take a look at these boot methods:

(1) Direct guidance

The configuration process is usually as follows:

A) use the root command to set the root device that contains the operating system kernel

B) load the kernel image file with the kernel command. If the kernel boots with parameters, you can add the parameters directly to the kernel file name.

C) load the kernel module with module or modulenounzip

D) boot starts booting

(2) chainload boot

A) set the root device of GRUB, and specify it with rootnoverify (hdx,y)

B) start booting, specified with chainloader + 1, where "+ 1" is the boot record that instructs GRUB to read into the first sector of the partition.

C) execute boot to start boot

The above is the general chainloader mode, for DOS and WINDOWS, you can simply boot with two instructions: chainloader (hdx,y) + 1, and then boot, where xmemy is used to indicate the partition number.

(3) Boot from the network:

In order for GRUB to support booting from the network, you need to turn on the network support option at compile time (see netboot/README.netboot in the source file). In addition, two services are set up in the network: the dynamic IP service (BOOTP, DHCP, or RARP) and the FTP service. Then, run bootp,dhcp or rarp for different servers BOOTP,DHCP or RARP. If everything is set up correctly, GRUB will give the IP and gateway IP addresses of the IP,IP netmask and TFTP servers. Finally, the image file of the operating system is obtained from the Internet. Here is an example:

Grub > bootp

Probing... [NE*000]

NE2000 base...

Address: 192.168.110.23 Netmask: 255.255.255.0

Server: 192.168.110.14 Gateway: 192.168.110.1

Grub > root (nd)

Grub > kernel / tftproot/gnumach.gz root=sd0s1

=

The following is a summary of the analysis and discussion of each player on this issue.

Let's first look at the traditional startup process of loading and running the contents of the Master Boot Record (MBR) main boot area (such as lilo, etc.). Then scan the partition table, locate the active partition, and load the contents of the boot sector on the active partition into memory for execution.

The system boot process mainly consists of the following steps (take hard disk boot as an example)

1. Turn on the system

2. BIOS power-on self-test (POST--Power On Self Test), memory address is 0fff:0000

3. Read the first sector of the hard disk (0 0 channel 1 sector, that is, Boot Sector) into the memory address 0000:7c00

4. Check whether (WORD) 0000:7dfe is equal to 0xaa55. If it is not equal, try other media; if there is no other boot media, display "No ROM BASIC" and then crash

5. Jump to 0000:7c00 to execute the program in MBR

6. MBR first copies itself to 0000Rank 0600, and then continues execution

7. Search the primary partition table for partitions marked active. If no active partition or more than one active partition is found, stop

8. Read the first sector of the active partition into the memory address 0000:7c00

9. Check whether (WORD) 0000:7dfe is equal to 0xaa55, if not, display "Missing Operating System", then stop, or try floppy boot

10. Jump to 0000:7c00 to continue to execute the startup program for a specific system

11. Start the system.

If you install grub to a logical partition, make sure that the logical partition loaded by grub is active. At this point, however, grub takes over the action after 11 steps: reading the grub.conf from stage 1.5. Then it is up to the configuration and user choice to determine the next step of the boot behavior.

Generally, there are two ways to install grub. In the case of installing to MBR, GRUB directly overwrites the original MBR bootstrapper. This is why it is necessary to switch back to the "original windows boot mode" and simply boot fdisk / mbr with dos. Why can you do this? notice that 0000:7c00 appears in two places in steps 1-11. Whether it's dos boot sector or nt loader, it itself runs from 0000:7c00. In fact, the Mini Program that ms developed and managed in that year is equivalent to being plugged into the bios boot boot sector. Because grub is also written from 0000:7c00, a memory-based subroutine, it is reasonable to understand that it can be loaded by both BIOS and dos's MBR.

After post, the boot power is given to the MBR of the hard drive, and the grub starts. Either windows / linux can be booted by grub. Note: linux does not have to be installed in the active partition because the bootstrap is in MBR! But windows must be installed in the active partition (bootable windows). The second windows may not be installed in the active partition, but its boot file must be in the active partition.

The general order is:

Grub-- > windows- > find Boot File-Boot load-start windows

Grub-- > linux- > find Boot File (/ boot)-> Boot load-start linux

So, what if grub is installed on another partition, not MBR? This is the primary partition in which grub is installed. It must be made active. Because there is no OS-related boot program in MBR (physical Master Boot Partition), usually MBR just scans and reads the subsequent partition table, finds the corresponding active partition, reads the 512-byte program of the first sector of the corresponding active partition and runs it, which is responsible for further booting the corresponding system of the corresponding partition. Therefore, the approximate order of operation is

BIOS- > MBR-- > GRUB-- > menu.

In this way, the general real process can be summarized as follows:

1. Turn on the system

2. BIOS power-on self-test (POST--Power On Self Test), memory address is 0fff:0000

3. Read the first sector of the hard disk (0 0 channel 1 sector, that is, Boot Sector) into the memory address 0000:7c00

4. Check whether (WORD) 0000:7dfe equals 0xaa55. If it is not equal, try other media; if there is no other boot media, display "No ROM BASIC" and then crash

5. Jump to 0000:7c00 to execute the program in MBR

6. MBR first copies itself to 0000Rank 0600, and then continues execution If you install XP first and then install LINUX, and LINUX is not installed in MBR, then the data in this MBR is the data written by WIN, and its role is the role described in the next step, that is, to search for the partition marked as active in the main partition table, then you must set the primary partition where GRUB is located as the active partition, and then you can start GRUB normally, and then the STAGE1 of GRUB is adjusting STAGE1.5 and other, so as to boot the entire system. If you install XP first and then install LINUX, but GRUB is installed in MBR, then STAGE1 is called into memory directly, and STAGE1 is adjusting STAGE1.5 and STAGE2, so as to boot the system. At this time, there is no need to set the primary partition where other GRUB files are located as the active partition, it directly adjusts STAGE1.5, etc., and then STAGE2, etc., to identify the file system, so as to achieve multi-boot.

7. Search the primary partition table for partitions marked active. If no active partition or more than one active partition is found, stop

8. Read the first sector of the active partition into the memory address 0000:7c00

9. Check whether (WORD) 0000:7dfe is equal to 0xaa55, if not, display "Missing Operating System", then stop, or try floppy boot

10. Jump to 0000:7c00 to continue to execute the startup program for a specific system

11. Start the system.

A little bit of information:

The grub that works properly should include the following files: stage1, stage2, * stage1_5, menu.lst.

The size of stage1 must be 512 bytes, which is to be installed (that is, written to the master boot record of a hard disk) or the boot sector of an active partition (which is marked bootable with fdisk). The main and only function of stage1 is to find the stage2 file that you store somewhere on your hard drive to do the rest of the work.

Stage2 files can exist in a particular file system, for example, you divide a linux partition, create an ext2 file system on it, and then copy the file to a directory in that partition. You can also store the stage2 directly in a location on your hard disk, that is, somewhere that is not partitioned. But not many people seem to do that.

Because of the limited capacity of stage1 (the size of the master boot record MBR and boot sector can only be 512 bytes), it is not recognized by the file system, so if you store stage2 on a file system in ext2 or fat format, how does it find this file? This is going to use the stage1_5 files mentioned above, which are responsible for interpreting the file system. What format of file system your stage2 is on, call the corresponding stage1_5 file. For example, if you store stage2 on a file system in ext2 format, you need e2fsstorage stage 1, stage 1 and stage 2 on a file system in fat format, and you need fat_stage1_5.

1.2 how is CentOS6 started

The startup process of Linux is actually very similar to that of windows, but we cannot see the startup information for windows. When Linux starts, we will see a lot of startup information, such as whether a service is started or not. Generally speaking, the startup process of Linux system can be divided into five parts: kernel boot, running init, system initialization, establishing terminal and user login system.

1. Kernel boot

When the computer is powered on, the first is the BIOS post, which starts according to the boot device (usually the hard drive) set up in BIOS. Then the grub program on the boot device starts to boot the Linux. When the bootstrap successfully completes the boot task, the Linux takes over the control of the CPU from them, and then the CPU starts to execute the core image code of the Linux and starts the Linux startup process. That is, the so-called kernel boot begins, in fact, the kernel boot process is very complicated, we will regard it as a black box, anyway, the Linux kernel has done a series of work, and finally the kernel call loads the init program, and the kernel boot work is completed. To the next protagonist, init.

two。 Run init

The init process is the starting point of all processes in the system. You can compare it to the ancestors of all processes in the system. Without this process, no process in the system will start. The main function of init is to prepare the environment for software execution, including the hostname of the system, network settings, language, file system format and the startup of other services. All actions are planned through init's configuration file / etc/inittab, and there is an important setting in inittab, which is the default runlevel (boot run level). First, let's take a look at the run-level Run level,Linux, which is to set run level to specify that the system uses different services to start, so that the use environment of Linux is different. Let's take a look at the support levels in this inittab file.

# inittab is only used by upstart for the default runlevel.

#

# ADDING OTHER CONFIGURATION HERE WILL HAVE NO EFFECT ON YOUR SYSTEM.

#

# System initialization is started by / etc/init/rcS.conf

#

# Individual runlevels are started by / etc/init/rc.conf

#

# Ctrl-Alt-Delete is handled by / etc/init/control-alt-delete.conf

#

# Terminal gettys are handled by / etc/init/tty.conf and / etc/init/serial.conf

# with configuration in / etc/sysconfig/init.

#

# For information on how to write upstart event handlers, or how

# upstart works, see init (5), init (8), and initctl (8).

#

# Default runlevel. The runlevels used 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 have networking)

# 3-Full multiuser mode

# 4-unused

# 5-X11

# 6-reboot (Do NOT set initdefault to this)

#

Id:3:initdefault:

The inittab configuration file format has changed a lot from previous versions of CentOS5 or older. There are seven levels of Runlevels. 0 indicates shutdown, 1 indicates single user, 2 indicates no network command line level, 3 command line level (most servers use this level), 4 is reserved level, 5 is graphical level, and 6 is restart. Except for the last line, all the other lines in this file are comment lines, that is, the last line is the key, it is used to specify which level the server runs, and no other level can be set here except 2, 3, 5 and 5. In the previous section of the file, you can see that many lines refer to a configuration file, and all configuration files are in the / etc/init/ directory.

3. System initialization

System initialization is to execute each configuration file under / etc/init/. There is a line "System initialization is started by / etc/init/rcS.conf" in the inittab configuration file, which means that the system initialization executes / etc/init/rcS.conf first, and there is a line "exec / etc/rc.d/rc.sysinit" in the configuration file. So, the center of gravity shifts to this rc.sysinit file, and it does the following work: activate the swap partition and check the disk. Loading hardware modules and other tasks need to be given priority. When the rc.sysinit program is finished, it will return to init to continue to the next step, to / etc/init/rc.conf, in this configuration file, the most critical behavior is "exec / etc/rc.d/rc $RUNLEVEL" and $RUNLEVEL is defined in / etc/inittab (the bottom line), take our / etc/inittab as an example It means $RUNLEVE=3, so the "/ etc/rc.d/rc3" is actually executed under / etc/rc.d/rc3.d/ at this time, and then / etc/rc.d/rc.local is also executed, and usually we put the boot command under this script. After the service is executed, the system initialization is completed. Next, it's time to set up the terminal.

4. Establish a terminal

The establishment of the terminal is accomplished by configuration files such as / etc/init/tty.conf, / etc/init/serial.conf and / etc/sysconfig/init. The mingetty program will be run in respawn mode in the run levels of 2, 3, 4 and 5, and the mingetty program can open the terminal and set the mode. At the same time, it displays a text login interface, which is the login interface we often see, in which the user is prompted for a user name, and the user entered by the user is passed as a parameter to the login program to verify the user's identity.

5. User login system

For graphical users running level 5, their login is through a graphical login interface. After logging in successfully, you can go directly to KDE, Gnome and other window managers. This article is mainly about text login: when we see the login interface of mingetty, we can enter the user name and password to log in to the system.

Linux's account verifier is that login,login accepts the user name from mingetty as the user name parameter. Login then analyzes the user name: if the user name is not root and the "/ etc/nologin" file exists, login will output the contents of the nologin file and exit. This is usually used to prevent non-root users from logging in during system maintenance. Only terminals registered in "/ etc/securetty" allow root users to log in, and if this file does not exist, root can log in on any terminal. The "/ etc/usertty" file is used to impose additional access restrictions on users, and if this file does not exist, there are no other restrictions.

After analyzing the user name, login will search for "/ etc/passwd" and "/ etc/shadow" to verify the password and other information about setting up the account, such as what the home directory is and what Shell to use. If no home directory is specified, it defaults to the root directory; if no Shell is specified, it defaults to "/ bin/bash".

After the login program succeeds, it outputs the last login information (recorded in "/ var/log/lastlog") to the corresponding terminal, and checks whether the user has any new mail (under the corresponding user name directory of "/ usr/spool/mail/"). Then start setting various environment variables: for bash, the system first looks for the "/ etc/profile" script file and executes it Then, if the .bash _ profile file exists in the user's home directory, it is executed, and other configuration files may be called in these files. After all the configuration files are executed, various environment variables are also set, and the familiar command line prompt appears, and the whole startup process is over.

Switch between graphical interface and command line interface

The Linux preset provides six command window terminals for us to log in. By default, we log in to the first window, that is, tty1, and the six windows are tty1,tty2. Tty6, you can press Ctrl + Alt + F1 ~ F6 to switch them. If you install a graphical interface, which is entered by default, you can press Ctrl + Alt + F1 ~ F6 to enter one of the command window interfaces. When you enter the command window interface and return to the graphical interface, just press Ctrl + Alt + F7 and you will be back. If you use a vmware virtual machine, the shortcut key for the command window toggle is Alt + Space + F1~F6. If you are in the graphical interface, press Alt + Shift + Ctrl + F1~F6 to switch to the command window.

Type of init program:

SysV: init, before CentOS 5, configuration file: / etc/inittab.

Upstart: init,CentOS 6, configuration file: / etc/inittab, / etc/init/*.conf.

Systemd: systemd, CentOS 7, configuration files: / usr/lib/systemd/system, / etc/systemd/system.

Finally, the startup process of CentOS system is summarized.

Post (power-on self-test)-> BootSequence (implemented in boot sequence selection BIOS)-> bootloder (boot loader, implemented in MBR-> Kernel (load kernel, generate ramdisk-> rootfs (load root file system in readonly)-> / sbin/init (run the first application (equivalent to small butler))-> set default allow level-> allow system initialization script Complete system initialization-> close the services to be stopped at the corresponding level, and start the services to be enabled at the corresponding level-> set login terminal-> [start graphics terminal]

The difference and function of systemd and Upstart (Centos6)

System V init run level

Systemd target name

Action

0

Runlevel0.target, poweroff.target

Shutdown

one

Runlevel1.target, rescue.target

Single user mode

two

Runlevel2.target, multi-user.target

Equivalent to level 3

three

Runlevel3.target, multi-user.target

Multi-user text interface

four

Runlevel4.target, multi-user.target

Equivalent to level 3

five

Runlevel5.target, graphical.target

Multi-user graphical interface

six

Runlevel6.target, reboot.target

Restart

Emergency

Emergency.target

Emergency Shell

If you want to change the default running target of the system to "multi-user, no graphics" mode, you can directly connect the multi-user mode target file to the / etc/systemd/system/ directory with the ln command:

[root@localhost~] # ln-sf / lib/systemd/system/multi-user.target / etc/systemd/system/default.target

1.3 Centos7 startup process

1. What is the startup process of CentOs system

The startup process of the CentOs system is that the CentOs host is in a normal working state from the power-on self-test to the whole system (including the application).

Macroscopically, the whole process can be divided into two levels: hardware and system, and the system can be divided into kernel space and user space startup, each of which runs automatically according to certain rules.

2. How is it helpful for us to understand the startup process of CentOS system

In practical work, the CentOs host will inevitably be unable to start or start abnormally. After understanding the startup process of the CentOs system, we can prescribe the right medicine to the problem, and after learning the startup process of the CentOs system, we can master part of the Linux working mechanism and lay a solid foundation for solving Linux failures in the future.

3. Detailed explanation of the startup process of CentOs system

Before explaining the startup process of the CentOs system, let's talk about the composition of the Linux system and the layering of the system environment in operation, which is helpful to grasp the principle of the startup process.

Composition of Linux system: kernel + root file system

The kernel can achieve the following functions: process management, memory management, network protocol stack, file system, security functions, drivers.

The kernel is the whole core of linux. To be exact, the kernel is Linux. Other programs realize its function by scheduling the kernel.

System environment layering in operation: kernel space bootfs + user space rootfs

Kernel space: consists of kernel code, has system-level permissions, and can directly change the hardware

User space: composed of a variety of applications, by calling the kernel to complete a variety of complex tasks.

The startup process of the Centos7 system:

1. Initialize uefi or BIOS and start post

This process is the stage of hardware check by BIOS or UEFI after boot.

2. Load mbr into memory

When there is no problem with the self-test hardware, take BIOS as an example, BIOS will directly find the first sector of the hard disk, find the first 446 bytes, load the MBR into memory, and MBR will tell the program where to find the system's grub boot in the next stage. This stage belongs to the first stage of grub. Grub also has 1.5 stages and 2 stages.

3. The stage of loading GRUB program

Bootloader, centos7 is grub2

Load the configuration file for the loader: / etc/grub.d/ / etc/default/grub

/ boot/grub2/grub.cfg, select multiple operating systems to boot, and load the Linux kernel

4. Load Linux kernel and inintamfs module

When the kernel is loaded, the kernel begins to decompress and starts some of the most core programs.

It can be seen that after the kernel mounts the root file system, start the init process. The init process is the first process started by the linux system, so what is the first process in CentOS7?

# decompress and view CentOS7 kernel files:

Mkdir-p / data/img

The kernel version number of the impassable version may be different.

Cp / boot/initramfs-3.10.0-693.11.6.el7.x86_64.img / data/img

Cd / data/img

/ usr/lib/dracut/skipcpio initramfs-3.10.0-693.11.6.el7.x86_64.img | zcat | cpio-id-- no-absolute-filenames

The decompressed directory is as follows

Lrwxrwxrwx. 1 root root 7 Jan 24 10:27 bin-> usr/bin

Drwxr-xr-x. 2 root root 42 Jan 24 10:27 dev

Drwxr-xr-x. 12 root root 4096 Jan 24 10:27 etc

Lrwxrwxrwx. 1 root root 23 Jan 24 10:27 init-> usr/lib/systemd/systemd

Lrwxrwxrwx. 1 root root 7 Jan 24 10:27 lib-> usr/lib

Lrwxrwxrwx. 1 root root 9 Jan 24 10:27 lib64-> usr/lib64

Drwxr-xr-x. 2 root root 6 Jan 24 10:27 proc

Drwxr-xr-x. 2 root root 6 Jan 24 10:27 root

Drwxr-xr-x. 2 root root 6 Jan 24 10:27 run

Lrwxrwxrwx. 1 root root 8 Jan 24 10:27 sbin-> usr/sbin

-rwxr-xr-x. 1 root root 3117 Jan 24 10:27 shutdown

Drwxr-xr-x. 2 root root 6 Jan 24 10:27 sys

Drwxr-xr-x. 2 root root 6 Jan 24 10:27 sysroot

Drwxr-xr-x. 2 root root 6 Jan 24 10:27 tmp

Drwxr-xr-x. 7 root root 61 Jan 24 10:27 usr

Drwxr-xr-x. 2 root root 27 Jan 24 10:27 var

It can be seen that the init process softlink to systemd. At this point, systemd becomes the first process of linux (PID=1) and takes over the system startup.

In order to make the kernel light enough, the hardware driver is not placed in the kernel file.

The kernel kernel initializes and replaces centos6's previous init programs with systemd

First execute initrd.target (/ usr/lib/systemd/system/initrd.target) all units, including the system in the mount / etc/fstab file, and after mounting, you can change to the root directory.

Switch from the initramfs root file system to the root of the disk

5. Systemd executes the default target configuration

Centos7 has the concept of "runlevel" on the surface, but it is actually to be compatible with previous systems. Each so-called "runlevel" has a corresponding soft connection point, and the default boot level / etc/systemd/system/default.target can find out which mode the system wants to enter according to its direction.

[root@localhost img] # ll / etc/systemd/system/default.target

Lrwxrwxrwx. 1 root root 37 10 hours 21 05:33 / etc/systemd/system/default.target-> / lib/systemd/system/multi-user.target

As you can see in the multi-user character interface, it points to multi-user.target

[root@localhost img] # cat / lib/systemd/system/multi-user.target

[Unit]

Description=Multi-User System

Documentation=man:systemd.special (7)

Requires=basic.target

Conflicts=rescue.service rescue.target

After=basic.target rescue.service rescue.target

AllowIsolate=yes

The configuration item Requires=multi-user.target in the file gives control to multi-user.target (equivalent to the run level of the old concept).

Centos6 mode and 7 correspondence:

Init 0 = = > runlevel0.target, poweroff.target

Init 1 = = > runlevel1.target, rescue.target

Init 2 = = > runlevel2.target, multi-user.target

Init 3 = = > runlevel3.target, multi-user.target

Init 4 = = > runlevel4.target, multi-user.target

Init 5 = = > runlevel5.target, graphical.target

Init 6 = = > runlevel6.target, reboot.target

Systemd executes sysinit.target (/ usr/lib/systemd/system/sysinit.target) initialization system and basic.target (/ usr/lib/systemd/system/basic.target.wants/) prepares the operating system.

Systemd starts native and server services under multi-user.target (/ etc/systemd/system/multi-user.target.wants)

Systemd executes / etc/rc.d/rc.local under multi-user.target

Systemd executes getty.target and login services under multi-user.target (/ usr/lib/systemd/system/multi-user.target.wants/)

Getty.target, which is the systemd object that starts the terminal. If at this step, the system does not specify to start the graphical desktop, it can be over.

If you need to start the graphical interface, start the desktop program on this basis.

Systemd performs the services required for graphical graphing

At this point, the system has been started and can be used normally.

Officially give the start-up flow chart.

Centos 7 operating system startup process

POST-- > BIOS (boot)-- > Bootloader (MBR (446))-- > kernel (initrd)-- > init (systemd) à (systemd initiation process: / usr/lib/systemd/system/default.target-> multi-user.target- > basic. Target targets. Target-à local-fs.target- à getty.target)

Although systemd references target in the same order, the real boot order is from bottom to top, where the snap-in can be started in parallel, thus greatly improving efficiency.

To see the specific startup sequence, you can enter it into the file with the following command, and then open it through the browser to view.

Systemd-analyze plot > boot.html

Lists all running units, sorted by the time it takes from initialization to startup.

Systemd-analyze blame

1.4 detailed explanation of Centos7 Systemd

I. the origin of systemd

Linux has always adopted the init process, but init has two disadvantages:

1. Long start-up time. The Init process is started serially, and the next process will not be started until the previous process has been started. (this is also the main feature of CentOS5)

2. The startup script is complex. The Init process simply executes the startup script, regardless of anything else. The script needs to handle a variety of situations on its own, which makes the script long and complex.

Init:

Centos 5 Sys init is the slowest startup process, regardless of whether the processes are dependent on each other or not.

The Centos6 Upstart init is improved compared to the faster startup speed. Processes that have dependencies are started in turn, while others that are not dependent on them are started synchronously in parallel.

Centos7 Systemd is different from the above. All processes, with or without dependencies, are started in parallel (of course, many times the process is not really started, but only a signal or flag, which is really started when it is really used. )

II. Systemd

Systemd was born to solve the above problems. Its goal is to provide a complete solution for the startup and management of the system. According to linux convention, the letter d is an abbreviation for daemon (daemon). The name Systemd is meant to protect the entire system.

Systemd replaced init in Centos 7 and became the first process of the system. PID is 1. All other processes are its child processes. Systemd has the advantages of powerful function and easy to use, while the disadvantage is that the system is huge and very complex. In fact, there are still many people who oppose the use of Systemd on the grounds that it is too complex, strongly coupled with the rest of the operating system, and violates the Unix philosophy of "keep simple, keep stupid".

Systemd architecture diagram

III. Service management

1 、 systemctl

Systemctl is the main command of systemd and is used to manage the system.

Centos 7: service unit

Note: compatible with earlier service scripts

Command format

# systemctl COMMAND name.service

Restart the system

# systemctl reboot

Shut down the system, cut off the power.

# systemctl poweroff

CPU stops working

# systemctl halt

Pause the system

# systemctl suspend

Put the system into hibernation

# systemctl hibernate

Put the system into interactive hibernation

# systemctl hybrid-sleep

Start to enter the rescue state (single user status)

# systemctl rescue

Start the service

# service name start = = > systemctl start name.service

Out of Service

# service name stop = = > systemctl stop name.service

Restart the service

# service name restart = = > systemctl restart name.service

View service status

# service name status = = > systemctl status name.service

Conditional restart: restart only after it has been started, otherwise no action will be taken.

# service name condrestart = = > systemctl tryrestart name.service

Reload or restart the service: load first, then start

# systemctl reload-or-restart name.service

Reload or conditional restart service:

# systemctl reload-or-try-restart name.service

Disable automatic and manual startup:

# systemctl mask name.service

To lift the prohibition:

# systemctl unmask name.service

2. Service View:

Check the post status of all services:

Chkconfig-- list = = > systemctl list-unit-files-- type service

Used to list the runlevels under which the service is enabled and disabled

Chkconfig sshd-list = = > ls / etc/systemd/system/*.wants/sshd.service

Check whether the service boots automatically:

Systemctl is-enabled name.service

Other commands:

View the dependencies of the service:

Systemctl list-dependencies name.service

Kill the process:

Systemctl kill process name

Displays all the underlying parameters of a Unit

# systemctl show httpd.service

Displays the value of the specified property of a Unit

# systemctl show-p CPUShares httpd.service

Set the specified properties of a Unit

# sudo systemctl set-property httpd.service CPUShares=500

3. Service status:

Display statu

Systemctl list-unit-files-- type service-all

Loaded:Unit configuration file has been processed

Active (running) one or more runs of continuous processing

Active (exited) successfully completed the one-time configuration

Active (waiting) is running, waiting for an event

Inactive does not run

Enabled boot up

Disabled boot does not start

Static does not boot up, but can be activated by another enabled service

4 、 hostnamectl

The hostnamectl command is used to view information about the current host.

Displays information about the current host

# hostnamectl

Sets the hostname.

# hostnamectl set-hostname Centos7

5 、 localectl

The localectl command is used to view localization settings.

View localization settings

# localectl

# set localization parameters.

# localectl set-locale LANG=en_GB.utf8

# localectl set-keymap en_GB

6 、 timedatectl

123456789 timedatectl

The timedatectl command is used to view the current time zone settings.

View current time zone settings

Show all available time zones

# timedatectl list-timezones

# set the current time zone

$# timedatectl set-timezone America/New_York

# timedatectl set-time YYYY-MM-DD

# timedatectl set-time HH:MM:SS

7 、 loginctl

The loginctl command is used to view the currently logged in user.

# list the current session

# loginctl list-sessions

# list the currently logged in users

# loginctl list-users

# list and display the information of the specified user

# loginctl show-user (ruanyf) users

IV. Unit

Systemd can manage all the resources in the system. Different resources are collectively referred to as unit. Unit represents different types of systemd objects that are identified and configured by the configuration file process; the file mainly contains system services, listening socket, saved system snapshots, and other init-related information.

1. Unit type

There are 12 kinds of Unit.

Sysstemctl-t help to view unit types

Service unit: the file extension .Service is used to define system services

Target unit: the file name is extended to .target and is used to simulate the implementation of "run level"

Device unit: .device, used to define the file kernel identification device

Mount unit: .mount defines the file system mount point.

Socket unit: .socket, which is used to identify the socket file used for inter-process communication. It can also delay starting the service when the system is started, so as to start on demand.

Snapshot unit: .snapshot to manage system snapshots

Swap unit: .swap, used to identify swap devices

Automount unit: .automount, the automatic mount point of the file system

Path unit: .path, which defines the use of a file or directory in a file system, and is often used to delay activating services, such as spool directories, when the file system changes

Scope unit: an external process that is not started by systemd

Slice unit: process group

Timer unit: timer

2. The systemctl list-units command can view all the Unit of the current system.

List the Unit that is running

# systemctl list-units

List all Unit, including those that did not find the configuration file or failed to start

# systemctl list-units-all

List all Unit that are not running

# systemctl list-units-all-state=inactive

List all Unit that failed to load

# systemctl list-units-failed

List all running Unit of type service

# systemctl list-units-type=service

3. Unit status

The systemctl status command is used to view the status of the system and the status of a single Unit.

Display system statu

# systemctl status

Displays the status of a single Unit

# sysystemctl status bluetooth.service

Displays the status of a Unit on a remote host

# systemctl-H root@Centos7.example.com status httpd.service

In addition to the status command, systemctl provides three simple ways to query status, which are mainly used by judgment statements within the script.

Displays whether a Unit is running

# systemctl is-active application.service

Displays whether a Unit is in a failed startup state

# systemctl is-failed application.service

Displays whether a Unit service has established a startup link

# systemctl is-enabled application.service

4. Dependency relationship

There is a dependency between Unit: a depends on B, which means that when Systemd starts A, it starts B.

The # systemctl list-dependencies command lists all the dependencies of an Unit.

# systemctl list-dependencies nginx.service

Some of the output of the above command depends on the Target type (see below), which is not displayed by default. If you want to expand Target, you need to use the-- all parameter.

# systemctl list-dependencies-all nginx.service

5. Unit configuration file

1. Overview

Each Unit has a configuration file that tells Systemd how to start the Unit.

Systemd reads the configuration file from the directory / etc/systemd/system/ by default. However, most of the files stored in it are symbolic links, pointing to the directory / usr/lib/systemd/system/, where the real configuration files are stored.

The systemctl enable httpd.service command is used to establish a symbolic link between the above two directories. (Created symlink from / etc/systemd/system/multi-user.target.wants/httpd.service to / usr/lib/systemd/system/httpd.service.) is equivalent to ln-s / usr/lib/systemd/system/httpd.service / etc/systemd/system/multi-user.target.wants/httpd.service. Of course, systemdctl diable httpd.service is equivalent to deleting the soft connection.

/ usr/lib/system/system: the main startup script setting for each service, similar to the previous / etc/init.d/

/ run/system/system: the service script generated during the execution of the system will be run preferentially with the directory above.

/ etc/systemd/system: the execution script established by the administrator, similar to the function of / etc/rc.d/rcN.d/Sxx, takes precedence over the above directory.

2. Profile status

The systemctl list-unit-files command lists all configuration files.

List all profiles

# systemctl list-unit-files

Lists profiles of the specified type

# systemctl list-unit-files-type=service

Systemctl list-unit-files this command outputs a list from which you can see the status of each profile.

Unit config filestatus

Lvm2-lvmetad.service disabled

Lvm2-lvmetad.socket enabled

Lvm2-lvmpolld.service disabled

Lvm2-lvmpolld.socket enabled

This list shows the status of each profile, with a total of four.

Enabled: startup link established

Disabled: no startup link has been established

Static: this profile has no [Install] section (cannot be executed) and can only be used as a dependency on other configuration files

Masked: this configuration file is prohibited from establishing startup links

Note that it is not possible to tell from the status of the configuration file whether the Unit is running. This must execute the systemctl status command mentioned earlier.

# systemctl status httpd.service

3. Configuration file format

1) unit configuration file format

[Unit]

Description=backup / etc

Requires=atd.service

[Service]

Type=simple

ExecStart=/bin/bash-c "echo / testdir/bak.sh | at now"

[Install]

WantedBy=multi-user.target

[unit]: define general options independent of Unit type; used to provide unit description information, unit behavior and dependencies, etc.

[Service]: special options related to a specific type; here is the Service type

[Install]: defines some options used by the "systemctl enable" and "systemctl disable" commands to enable or disable the service

2. Common options for Unit segment: Description: short description

Description: description information

After: defines the startup order of the unit, indicating which current unit should be later than

Unit starts, and its function is opposite to that of Before

Requires: other dependent units, strongly dependent, when the dependent units cannot be activated, the current unit cannot be activated.

Wants: other units that you depend on, weak dependency

Conflicts: define conflicting relationships between units

BindsTo: similar to Requires, if the specified Unit exits, it will cause the current Unit to stop running

Before: if the Unit specified in this field is also to be started, it must be started after the current Unit

Conflicts: the Unit specified here cannot run simultaneously with the current Unit

Condition...: the conditions that must be met for the current Unit run, otherwise it will not run

The conditions that must be met for the current Unit operation of Assert...:, otherwise startup failure will be reported.

3. Options commonly used in service

Type: defines the startup types of unit processes that affect the functions of ExecStart and related parameters

Simple: default value. This daemon is mainly started by the instruction string connected to ExecStart and resides in memory after startup.

Forking: programs initiated by ExecStart extend other subroutines through spawns as the primary service of this daemon. The original parent program terminates after it is started.

Oneshot: similar to simple, except that this program ends after the work is finished and does not reside in memory

Dbus: similar to simple, but the daemon must have a D-Bus name before it continues to operate. Therefore, you usually have to set BusNname= at the same time.

Notify: a notification message is sent after the startup is complete. You also need to cooperate with NotifyAccess to make Systemd receive messages.

Idle: similar to simple, to execute this daemon, all the work must be done smoothly before it is executed. This kind of daemon connection

A service that is often powered on to the end.

EnvironmentFile: environment Profil

ExecStart: indicates the absolute path to start unit to run a command or script

ExecStartPre: run before ExecStart

ExecStartPost: run after ExecStart

ExecRsload: the command executed when the current service is restarted

ExecStopPost: commands executed after the current service is stopped

ExecStartSec: the number of seconds between restarting the current service automatically

ExecStop: indicates the command or script to stop unit to run

Restart: when Restart=1 is set, when the daemon service terminates unexpectedly, the service will be started automatically again.

TimeoutSec: defines the number of seconds to wait before Systemd stops the current service.

Environment: specifies the environment variable.

4. Common options for install

Common options for the Install section:

Alias: alias, you can use systemctl command Alias.service

RequiredBy: which units depends on and strongly depends on

WantedBy: which units depends on and weakly depends on

Also: other related services should be installed when this service is installed

Note: for newly created unit files, or modified unit files, tell systemd to reload this configuration file, and then choose to restart.

# systemctl daemon-reload

# systemctl daemon-reload

# systemctl restart httpd.service

For more detailed unit configuration file format, please refer to the official documentation.

Https://www.freedesktop.org/software/systemd/man/systemd.unit.html

VI. Target

When you start your computer, you need to start a large number of Unit. If every startup, it is obviously very inconvenient to specify which Unit is needed for this startup. Systemd's solution is Target.

In a nutshell, Target is a Unit group that contains many related Unit. When you start a Target, Systemd starts all the Unit in it. In this sense, the concept of Target is similar to a "state point", starting a Target is like starting to a certain state.

In the traditional init startup mode, there is the concept of RunLevel, which is very similar to the function of Target. The difference is that RunLevel is mutually exclusive and it is not possible for multiple RunLevel to start at the same time, but multiple Target can be started at the same time.

1. Target command

View all Target of the current system

# systemctl list-unit-files-type=target

View all the Unit contained in a Target

# systemctl list-dependencies multi-user.target

View the default Target at startup

# systemctl get-default

Set the default Target at startup

# systemctl set-default multi-user.target

When switching Target, the process started by the previous Target is not closed by default, and the systemctl isolate command changes this behavior.

Close the systemctl isolate multi-user.target of all processes in the previous Target that do not belong to the latter Target

2. The corresponding relationship between Target and traditional RunLevel is as follows.

Traditional runlevel New target name Symbolically linked to...

Runlevel 0 | runlevel0.target-> poweroff.target

Runlevel 1 | runlevel1.target-> rescue.target

Runlevel 2 | runlevel2.target-> multi-user.target

Runlevel 3 | runlevel3.target-> multi-user.target

Runlevel 4 | runlevel4.target-> multi-user.target

Runlevel 5 | runlevel5.target-> graphical.target

Runlevel 6 | runlevel6.target-> reboot.target

3. The main differences between it and init process are as follows.

(1) the default RunLevel (set in the / etc/inittab file) is now replaced by the default Target at / etc/systemd/system/default.target, usually with symbolic links to graphical.target (graphical interface) or multi-user.target (multi-user command line).

(2) the location of the startup script used to be the / etc/init.d directory, symbolic links to different RunLevel directories (such as / etc/rc3.d, / etc/rc5.d, etc.), and now stored in the / lib/systemd/system and / etc/systemd/system directories.

(3) the location of the configuration file. The previous configuration file of the init process is / etc/inittab, and the configuration files of various services are stored in the / etc/sysconfig directory. The current configuration file is mainly stored in the / lib/systemd directory, and the changes in the / etc/systemd directory can overwrite the original settings.

VII. Log management

Systemd uniformly manages startup logs for all Unit. The benefit is that you can view all the logs (kernel logs and application logs) with a single command called journalctl. The configuration file for the log is / etc/systemd/journald.conf.

1. Journalctl has powerful functions and has many uses.

View all logs (by default, only the logs for this startup are saved)

# journalctl

View kernel log (application log is not displayed)

# journalctl-k

View the log of this startup of the system

# journalctl-b

# journalctl-b-0

View the log of the last startup (need to change the setting)

# journalctl-b-1

View the log at a specified time

# journalctl-- since= "2012-10-30 18:17:16"

# journalctl-since "20 min ago"

# journalctl-since yesterday

# journalctl-since "2015-01-10"-- until "2015-01-11 03:00"

# journalctl-- since 09:00-- until "1 hour ago"

Show the latest 10 lines of log at the tail

# journalctl-n

Displays the log with the specified number of lines at the end

# journalctl-n 20

Scrolling the latest log in real time

# journalctl-f

View the log of the specified service

# journalctl / usr/lib/systemd/systemd

View the log of the specified process

# journalctl _ PID=1

View the log of a script for a path

# journalctl / usr/bin/bash

View the log of the specified user

# journalctl _ UID=33-- since today

View the log of a Unit

# journalctl-u nginx.service

# journalctl-u nginx.service-- since today

Scrolling the latest log of a Unit in real time

# journalctl-u nginx.service-f

Merge and display logs of multiple Unit

# journalctl-u nginx.service-u php-fpm.service-- since today

2. View logs with specified priority (and above), with a total of 8 levels

0: emerg

1: alert

2: crit

3: err

4: warning

5: notice

6: info

7: debug

# journalctl-p err-b

Log default paging output,-- no-pager is changed to normal standard output

# journalctl-no-pager

Output in JSON format (single line)

# journalctl-b-u nginx.service-o json

Output in JSON format (multi-line) for better readability

# journalctl-b-u nginx.serviceqq

-o json-pretty

Displays the hard disk space occupied by the log

# journalctl-disk-usage

Specify the maximum space occupied by the log file

# journalctl-vacuum-size=1G

Specify how long the log file will be saved

# journalctl-vacuum-time=1years

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.