Linux operating system boot process
table of Contents
Linux operating system boot process
Forgotten the password of the root user
POST
After the server host is turned on, the CPU, memory, graphics card, keyboard and other devices will be initially tested according to the settings in the motherboard BIOS. After the test is successful, the system control will be transferred according to the preset startup sequence, and most of the time will be transferred to the local hard disk.
Summary: The first device capable of booting the system is detected, such as a hard disk or an optical drive
MBR boot
When starting the system from the local hard disk, first transfer the system control right to the partition containing the operating system boot files according to the MBR (Master Boot Record) setting in the first sector of the hard disk; or directly according to the boot in the MBR record The information calls the boot menu (such as GRUB).
Summary: Run the boot GRUB boot program placed in the MBR sector
GRUB menu
For the Linux operating system, GRUB (Unified Boot Loader) is the most widely used multi-system bootloader program. After the system control is passed to GRUB, the boot menu will be displayed for the user to choose, and the Linux kernel file will be loaded according to the selected option (or the default value), and then the system control will be transferred to the kernel.
CentOS 7 uses the GRUB2 boot loader.
Summary: The GRUB boot program reads the GRUB configuration file /boot/grub2/grub.cfg to obtain the kernel and mirror file system settings and path locations
Load the Linux kernel
The Linux kernel is a pre-compiled special binary file, between various hardware resources and system programs, responsible for resource allocation and scheduling. After the kernel takes over the control of the system, it will fully control the running process of the entire Linux operating system.
In CentOS 7 system, the default kernel file is located at "/boot/vmlinuz-3.10.0-514.el7.x86_64".
Summary: Load the kernel and mirror file system into memory
init process initialization
In order to complete the further system boot process, the Linux kernel first loads the "/sbin/init" program in the system into the memory to run (the running program is called a process), the init process is responsible for completing the initialization of the entire system, and finally waits for the user to proceed log in.
Summary: Load the hardware driver, the kernel loads the init process into the memory to run
Traditional sysvinit relies on serial execution of Shell scripts to start services, resulting in low efficiency and slow system startup.
Systemd can start more service processes in parallel, and has the ability to provide on-demand startup services, so that fewer processes can be started, thereby improving System startup speed.
System initialization process
init process
The /sbin/init program
is loaded and run by the linux kernel. The init process is the first process in the system. The
PID (process tag) number of the init process is always 1
Systemd
Systemd is a kind of init software of the Linux operating system.
CentOS7 adopts a new Systemd startup method, replacing the traditional SysVinit
. The first init process running in CentOS is /lib/systemd/systemd
Systemd unit type
- .services: A service unit describes how to manage a service or application on the server. This will include how to start or stop the service, under which circumstances it should be started automatically, and related software dependencies and sequencing information.
- .socket: A socket unit file describes a network or IPC socket or a FIFO buffer used by systemd for basic socket activation. The .services file will start when the socket defined in this unit is active.
- .devic: Describes a device designated by udev or sysfs as the unit of the systemd manager. Not all settings have .device files. In some cases, the .device unit may be necessary to command, mount, and access the device.
- .mount: This unit defines a mount point managed by systemd on the system. These files are named after the mount path, and the slashes are changed to dashes. The entries in /etc/fstab will have automatically created units.
- .automount: An .automount unit is configured with a mount point that will be automatically mounted. These must be ordered according to the mount point involved and must have a matching .mount unit to define the details of the mount.
- .swap: This unit describes the swap space in the system. The names of these files must reflect the device or space file.
- .target: A target unit provides synchronization points for other units when it starts or changes state. They can also be used to bring the system into a new state. Other units specify their equivalent targets to bind the operations of the target.
- .path: This unit defines a path that can be used for path-based activation. By default, a .service unit with the same base name will start when the path reaches the specified state. This uses inotify to monitor path changes.
- .timer: A .timer unit defines a timer managed by systemd, similar to a cron job to delay or schedule activation. A matching unit will start when the timer arrives.
- .snapshot: A .snapshot unit is automatically created by the systemctl snapshot command. It allows you to rebuild the current state of the system after making changes. Snapshots do not survive across sessions. Snapshots are used to roll back the temporary state.
- .slice: A .slice unit is associated with the Linux Control Group node, allowing resources to be restricted or assigning matching time slices to the associated process. The name reflects its hierarchical position in the cgroup tree. Units are placed in certain positions by default according to their type.
- .scope: The scope unit is automatically created by systemd based on the information received from its bus interface. These are used for the management set of externally created system processes.
- .target describes a set of systemd units
Troubleshoot startup faults
Repair MBR sector failure
cause of issue
Damage caused by viruses, Trojan horses, etc., incorrect partition operations, disk read and write errors
Failure phenomenon
Cannot find the boot program, start interrupted, unable to load the operating system, black screen after booting
Solutions
The backup file should be prepared in advance, boot into the emergency mode with the installation CD, and then restore from the backup file
Fix GRUB boot failure
cause of issue
The GRUB boot program in the MBR is damaged, the grub.conf file is missing, and the boot configuration is incorrect
Failure phenomenon
System booting stalls and the "grub>" prompt is displayed
Solutions
Try to manually enter the boot command to enter the rescue mode, rewrite or restore grub.conf from the backup, and then rebuild the grub program into the MBR sector
Fix GRUB boot failure
The package in the /boot/grub/ directory is used for the background image and style of the boot menu
/boot/grub2/grub.cfg #GRUB configuration file
Method 1: Manually enter the guide command (clumsy and cumbersome, not recommended)
grub> insmod xfs #load the specified module to the kernel
grub> linux16 /vmlinuz-3.10.0-693.el7.x86_64 root=UUID=8fd74986-ae66-4ffd-b7d8-a19f2eca7b6f ro rhgb quiet LANG=zh_CN.UTF-8 #Kernel name and location and other information
grub> initrd16 /initramfs-3.10.0-693.el7.x86_64.img #Mirror system file
grub> boot #boot boot
Method 2: Enter emergency mode and restore GRUB boot program
MBR is located at the first physical sector of the first hard disk (/dev/sda), a total of 512 bytes, the first 466 bytes are the master boot record, the partition table is stored in the 477-510 bytes in the MBR sector in.
mkdir / look
mount /dev/sdb1 /bak
dd if=/dev/sda of=/bak/grub.bak bs=446 count=1
#Simulate the destruction of the GRUB boot program in the MRB, but does not destroy the partition table
dd if=/dev/zero of=/dev/sda bs=446 count=1
#The boot interface enters emergency mode and restores the GRUB boot program from the backup file
sh-4.2# mkdir /backupdir
sh-4.2# mount /dev/sdb1 /backupdir
sh-4.2# dd if=/backupdir/grub.bak of=/dev/sda
sh-4.2# exit
Method 3: Enter the emergency mode and rebuild the GRUB menu configuration file
rm -rf /boot/grub2/grub.cfg
# Enter rescue mode, image loading system, the system is switched to the root environment
sh-4.2 # chroot / mnt / sysimage
# Re GRUB boot installed to the first hard disk (/ dev / sda) of MRB sector
bash-4.2 # grub2-install / dev / sda
# Rebuild GRUB menu configuration file
bash-4.2 # grub2-mkconfig -o /boot/grub2/grub.cfg
# Exit the chroot environment and reboot the
bash-4.2 # Exit
SH-4.2 # reboot
Forgotten the password of the root user
Enter the emergency mode, load the system image, switch to the system root environment
sh-4.2# chroot /mnt/sysimage
reset the root user password
bash-4.2# passwd root
systemctl tool
It does not provide interactive and visual windows, and it is more efficient to manage a single service
View the startup status of system services
systemctl is-enabled service name
Set the startup status of the system service on/off
systemctl enable/disable service name
Permanently modify the host name
hostnamectl set-hostname newname
View the status of the hostname
hostnamectl status
Set the system language to Chinese
localectl set-locale LANG=zh_CN.utf8
View the language used by the current system
localectl [status]
View system startup time
systemd-analyze