Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

Linux startup process and what are the basic commands

2025-04-01 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >

Share

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

What is the Linux startup process and what are the basic commands? for this question, this article introduces the corresponding analysis and solutions in detail, hoping to help more partners who want to solve this problem to find a more simple and easy way.

Firmware (firmware) refers to the program code of the device layer that allows the device to run. The simple understanding is: software fixed on hardware. Many devices in computers have firmware (such as hard drives, mice, optical drives, USB drives, etc.). During computer startup, * * reads the firmware located on the motherboard, which is currently available in two types: the traditional BIOS and the new more versatile UEFI.

In the previous article, we mentioned that another disk partition format, GTP, is also part of the UEFI standard. Therefore, in the current computer startup, there are two different ways: BIOS/MBR and UEFI/GTP.

In the world of linux operating system, it is also undergoing changes, and the system initialization software sysvinit is gradually replaced by systemd.

This article will mainly talk about the traditional BIOS/MBR-- > sysvinit startup mode, at the same time, as a supplement, will also briefly describe the UEFI/GTP-- > systemd startup mode.

BIOS/MBR-- > sysvinit

1. BIOS stage

The contents of BIOS will be read and executed immediately after the system is powered on. The execution of the program in BIOS includes two steps:

1) Power-on self-test POST (power-on self test), which is mainly responsible for checking whether the peripherals of the system (such as CPU, memory, graphics card, keyboard and mouse, etc.) are normal. If there is a problem with the hardware, the motherboard will beep with different meanings and start and terminate. If there is no problem, the screen will display CPU, memory, hard drive and other information.

2) after the self-test is complete, BIOS will execute a program to enumerate local devices (such as CD, U disk, hard disk, network, etc., which can be set in BIOS) to find the location of the next stage of the startup program. BIOS gives control to the device in the boot sequence (Boot Sequence), where the computer reads the first 512 bytes of the device. If the two bytes are 0x55 and 0xAA (Magic Number), the device can be used for startup; if not, it indicates that the device cannot be used for startup, and control is transferred to the next device in the boot sequence. As mentioned in the previous article, the first 512 bytes in the hard disk is the master boot record MBR.

2. MBR stage

In the previous article, we described the structure of MBR, including 446 bytes of Bootloader,64 bytes of DPT and 2 bytes of Magic Number.

One of the more common types of Bootloader (boot loader) is that grub,grub bootstrap is divided into two phases (some grub defines 1.5 phases):

1) BIOS loads stage1 into the specified location (0x7C00) in memory and jumps to execute. The content of stage1 is the beginning of 446 bytes in MBR. The main function of this phase is to load the contents of hard disk 0 head 0 track 2 sector into memory 0x8000 and jump to execute.

1.5) because the code of stage2 (larger) is stored in the / boot partition under the file system (or / boot does not have a separate partition / etc/), it requires a file system environment to identify stage2 files (at this time, you can only directly read the contents of the specified location of the hard disk, and can not identify the file system). The purpose of stage1.5 is to provide a file system environment for stage2 so that the system can find stage2 files located in the file system.

2) when stage2 is loaded into memory and executed, it will first parse the grub configuration file menu.lst, namely / boot/grub/grub.conf, which specifies the location of the system kernel file. If the file is not found, a shell will be executed, waiting for the user to specify the location of the kernel file manually. The final state of this phase is to execute the boot command, load the kernel and initrd image into memory, and then hand over control to the kernel.

Grub.conf content (version: GNU GRUB 0.97):

# grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a / boot partition. This means that # all kernel and initrd paths are relative to / boot/, eg. # root (hd0,0) # kernel / vmlinuz-version ro root=/dev/sda3 # initrd / initrd-version.img # boot=/dev/sda default=0 timeout=5 splashimage= (hd0,0) / grub/splash.xpm.gz hiddenmenu title CentOS (2.6.18-407.el5) root (hd0,0) kernel / vmlinuz-2.6.18-407.el5 ro root=LABEL=/ rhgb quiet initrd / initrd-2.6.18-407 .el5.img title CentOS (2.6.18-398.el5) root (hd0,0) kernel / vmlinuz-2.6.18-398.el5 ro root=LABEL=/ rhgb quiet initrd / initrd-2.6.18-398.el5.img

The line beginning with # in the file is the comment line, and the most important part is the two kernel locations specified under title and the specific files (kernel and initrd entries)

3. Kernel stage

Grub's stage2 loads the initrd file into memory, and the kernel starts executing the init file in initrd, which is a script that loads device drivers related to various storage media. When the required drivers are loaded, a root device is created and the root file system (rootfs) is mounted read-only. At the end of this step, release the unused memory, switch to the real root file system to run the program / sbin/init, and start the process with system PID 1. Control of the system is then handed over to the / sbin/init process.

4. Init stage

When the init process takes control of the system, it first reads the / etc/inittab file, which describes how the init process initializes the system at a specific run level (runlevel).

Seven levels of operation are defined in linux: 0 indicates shutdown 1 indicates single user mode 2 indicates no network multi-user mode 3 indicates that multi-user mode 4 does not use 5 indicates graphical interface mode 6 indicates restart

The default run level of the system is specified in the inittab file, such as id:3:initdefault: indicates that the default run level is 3 (multi-user mode).

The init process runs a series of specified initialization scripts based on the inittab file:

1) / etc/rc.d/rc.sysinit system initialization script, which includes setting the hostname and default gateway, deciding whether to enable SELinux, loading user-defined modules, setting kernel parameters according to file / etc/sysctl.conf, setting hard disk functions such as raid and LVM, re-mounting the root file system in read-write mode, etc.

2) execute the / etc/rc.d/rc file, which confirms the runlevel N specified by inittab and starts the services under the appropriate level (by executing the files in / etc/rc.d/rcN.d), for example, when runlevel 3, execute the file that begins with K under / etc/rc.d/rc3.d, and then executes the file that starts with S. These files point to symbolic links under / etc/init.d. Files that start with K represent the services that need to be shut down at this runlevel, and files that start with S represent the services that need to be turned on at this runlevel.

3) in runlevels 2, 3, 4 and 5, * an executed file all points to the file / etc/rc.local, where you can customize the startup content.

4) then run 6 terminals according to the settings in inittab so that the user can log in to the system, and if it is runlevel 5, / etc/X11/prefdm-nodaemon will be executed to start the corresponding desktop environment.

5) then execute the / bin/login program to receive and verify the username and password from mingetty.

At this point, the whole system is activated.

UEFI/GTP-- > systemd

UEFI appears to replace BIOS. Similarly, GTP and systemd are also to make up for the shortcomings of MBR and sysvinit. Unlike BIOS, which is only responsible for POST and finding MBR, UEFI will run through the whole process of power-up to shutdown of the system. Roughly divided, UEFI system startup is divided into four stages:

1. UEFI initialization phase

1) SEC (Security Verification): receives and processes system startup and restart signals, initializes the temporary storage area, and transfers system parameters to the next stage (i.e. PEI).

2) PEI (pre-EFI initialization): prepare the execution environment for DXE, form a HOB (Handoff Block) list of the information that needs to be passed to DXE, and finally transfer control to DXE.

3) DXE (driver execution environment): initializes the system service according to the HOB list, then traverses all the Driver in the firmware, and when the driver's dependent resources are satisfied, dispatch the Dirver to the execution queue for execution until all the Dirver that meets the conditions are loaded.

2. The operating system loader runs as a UEFI application

1) BDS (boot device selection): initialize the console device, load the necessary device drivers, load and execute startup items according to the system settings, after the user selects a startup item (or the system enters the default startup item), OS Loader starts, and the system enters the TSL phase.

Programs in UEFI can recognize partition information and file systems on storage media (such as fat32), and / EFI/boot/grub2.efi (a partition ESP on a GTP format hard disk, automatically generated during installation) will be run as a UEFI application.

2) TSL (temporary system loading): the * phase executed by the operating system loader (OS Loader is also located in the ESP partition), during which OS Loader runs as a UEFI application, and system resources are still controlled by the UEFI kernel. When the ExitBootServices () service that starts the service is called, the system enters the RT (Run Time) phase.

3. Operating system running phase

RT (runtime): control of the system is transferred from the UEFI kernel to OS Loader, various resources occupied by UEFI are recycled to OS Loader, and only UEFI runtime services are reserved for OS Loader and OS. With the implementation of OS Loader, OS finally gained control of the system.

When init is used as the system initialization program, services are managed and executed sequentially through scripts in / etc/rc.d/init.d. When systemd is used as the system initialization program, these scripts are replaced by service units and start the process in parallel as much as possible.

In systemd, a unit configuration file can describe one of the following:

System service (.service) mount point (.mount) socket (.sockets) system device (.device) swap partition (.swap) file path (.path) startup target (.target) timer (.timer) managed by systemd.

Systemd also retains some init commands and concepts to maintain downward compatibility, but the corresponding files are symbolic links to commands or files corresponding to systemd:

[root@centos7 temp] # ls-l / sbin/init lrwxrwxrwx. 1 root root 22 January 15 2016 / sbin/init->.. / lib/systemd/systemd [root@centos7 temp] # ls-l / usr/lib/systemd/system/runlevel*.target lrwxrwxrwx. 1 root root 15 January 15 2016 / usr/lib/systemd/system/runlevel0.target-> poweroff.target lrwxrwxrwx. 1 root root 13 January 15 2016 / usr/lib/systemd/system/runlevel1.target-> rescue.target lrwxrwxrwx. 1 root root 17 January 15 2016 / usr/lib/systemd/system/runlevel2.target-> multi-user.target lrwxrwxrwx. 1 root root 17 January 15 2016 / usr/lib/systemd/system/runlevel3.target-> multi-user.target lrwxrwxrwx. 1 root root 17 January 15 2016 / usr/lib/systemd/system/runlevel4.target-> multi-user.target lrwxrwxrwx. 1 root root 16 January 15 2016 / usr/lib/systemd/system/runlevel5.target-> graphical.target lrwxrwxrwx. 1 root root 13 January 15 2016 / usr/lib/systemd/system/runlevel6.target-> reboot.target

The * targets executed after systemd starts are default.target, but default.target is actually a symbolic link to graphical.target.

[root@centos7 temp] # ls-l / usr/lib/systemd/system/default.target lrwxrwxrwx. 1 root root 16 January 15 2016 / usr/lib/systemd/system/default.target-> graphical.target [root@centos7 temp] # cat / usr/lib/systemd/system/graphical.target # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1of the License, or # (at your option) any later version. [Unit] Description=Graphical Interface Documentation=man:systemd.special (7) Requires=multi-user.target Wants=display-manager.service Conflicts=rescue.service rescue.target After=multi-user.target rescue.service rescue.target display-manager.service AllowIsolate=yes

The requirements line indicates the dependencies of this unit (other meanings can be viewed through the command man systemd.unit). Along this file, you can find the units that need to be executed: multi-user.target, basic.target, sysinit.target, local-fs.target swap.target, local-fs-pre.target.

4. Shutdown phase

AL (After-life): when the system hardware or operating system fails to continue to function properly due to a serious error, the firmware attempts to fix the error, and the system enters the AL phase. The UEFI standard does not define behaviors and specifications at this stage. The system vendor can define it by itself.

Related command

Init

1 、 init

In addition to playing an important role in system initialization, init can also be used to perform shutdown, restart, and switch runlevel functions:

# shutdown init 0 # restart init 6 # switch to single user mode init 1

2. Runlevel displays the run level

[root@centos7 temp] # runlevel N 3 [root@centos7 temp] #

N in the output represents the current runlevel, and if the runlevel has been switched after the system is started, the output similar to 3 indicates that the runlevel was 3 before and now is 5.

3 、 halt reboot poweroff shutdown

# shutdown immediately shutdown-h now # perform shutdown at 11:50 shutdown-h 11:50 # if you want to cancel the shutdown at the specified time, execute in another terminal: shutdown-c # restart the system after 30 minutes, and restart without disk detection shutdown-fr + 30

4. Update or query the runtime information of the service by chkconfig

# list services (also list services managed by xinetd) chkconfig-- list # add a service chkconfig-- add httpd # to enable the service to self-start chkconfig at run levels 2, 3 and 5-- level 235 httpd on

5. Service runs the service script (the service script is located in / etc/init.d, and service itself is also a script, located in / sbin)

# list all service status service-- status-all # list a single service status service nginx status # start service service nginx start # stop service service nginx stop # restart service service nginx restart # reload configuration file service nginx reload

Systemd

Systemd is not a command, but a set of commands that cover all aspects of system management.

1. Systemctl controls systemd systems and management services

Systemctl [OPTIONS...] COMMAND [NAME...]

Such as switching the running level or switching on or off:

# restart (execute reboot.target) systemctl reboot # pause (execute suspend.target) systemctl suspend # hibernate (execute hibernate.target) systemctl hibernate # switch to rescue mode (single user, execute rescue.target) systemctl rescue # list runlevel systemctl get-default # switch to runlevel 5, that is, graphics mode systemctl isolate graphical.target

Related to the system service unit:

# list running Unit systemctl list-units # list all Unit systemctl list-units-- all # list all Unit systemctl list-units that failed to load-- failed # list the specified type systemctl list-units-- type=socket when listing Unit

System and service management:

# system status systemctl status # Service status (.service can be omitted) systemctl status nginx.service # start service systemctl start nginx # stop service systemctl stop nginx # restart service systemctl restart nginx # reload configuration file systemctl reload nginx # set service boot systemctl enable nginx # list all installed service systemctl list-unit-files # specify type systemctl list-unit-files-- type=target

There are many other options, which are not listed here.

2. Systemd-analyze to check the startup time

[root@centos7 ~] # systemd-analyze Startup finished in 730ms (kernel) + 1.904s (initrd) + 9.909s (userspace) = 12.544s

The output shows that each part of the system takes time during startup.

# when initializing services [root@centos7 ~] # systemd-analyze blame 5.424s NetworkManager-wait-online.service 1.830s dev-mapper-centos\ x2droot.device 1.055s firewalld.service 980ms kdump.service 549ms network.service. # output time details of each service and write to a file (this file can be opened with a browser or image viewer) [root@centos7 ~] # systemd-analyze plot > file.svg # serialize the detailed and complete status information of each service (there are many outputs) [root@centos7 ~] # systemd-analyze dump

3. Systemd-cgls recursively displays control group (Cgroups) information

Starting with version 2.6.24, the linux kernel introduced a feature called control group (control groups), which is a mechanism for limiting, recording, and isolating physical resources (such as cpu,memory,IO, etc.) used by process groups (process groups). This article will not expand on Cgroups.

[root@centos7] # systemd-cgls ├─ 1 / usr/lib/systemd/systemd-switched-root-system-deserialize 21 ├─ user.slice │ └─ user-0.slice │ ├─ session-182.scope │ │ ├─ 5165 sshd: root@pts/1 │ │ ├─ 5167-bash │ │ ├─ 5409 systemd-cgls. ....

4. Systemd-cgtop shows the usage of each control group (CPU, memory, IO)

The display effect is similar to the command top

[root@centos7] # systemd-cgtop Path Tasks% CPU Memory Input/s Output/s / 161 0.2 400.5M-/ system.slice/NetworkManager.service 1-- -- / system.slice/auditd.service 1-/ system.slice/crond.service 1-/ system.slice/dbus.service 1- -/ system.slice/firewalld.service 1 -....

5. Systemd-loginctl controls systemd login management

This command is a symbolic link to the command loginctl

# list the current session [root@centos7 ~] # systemd-loginctl list-sessions SESSION UID USER SEAT 1820 root 1540 root 2 sessions listed. # list the current login user [root@centos7 ~] # loginctl list-users UID USER 0 root 1 users listed. # list and display the information of the specified user [root@centos7] # loginctl show-user root UID=0 GID=0 Name=root Timestamp= three 2016-12-21 08:38:54 CST TimestampMonotonic=77015538361 RuntimePath=/run/user/0 Slice=user-0.slice Display=154 State=active Sessions=182 154IdleHint=no IdleSinceHint=0 IdleSinceHintMonotonic=0 Linger=no [root@centos7 ~] #

6. Time and date control of timedatectl system

[root@centos7] # timedatectl Local time: three 2016-12-21 13:47:31 CST Universal time: three 2016-12-21 05:47:31 UTC RTC time: three 2016-12-21 05:47:31 Time zone: Asia/Shanghai (CST + 0800) NTP enabled: NTP synchronized: no RTC in local TZ: no DST active: a # setting time [root@centos7 ~] # timedatectl set-time "2012-10-30 18:17:16" # list the time zone [root@centos7 ~] # timedatectl list-timezones Africa/Abidjan Africa/Accra Africa/Addis_Ababa Africa/Algiers Africa/Asmara. # set time zone [root@centos7 ~] # timedatectl set-timezone America/New_York

7. Hostname control of hostnamectl system

# status [root@centos7 ~] # hostnamectl status Static hostname: centos7 Icon name: computer-vm Chassis: vm Machine ID: 956ab824a02d489d85b079cb442d5442 Boot ID: 9016d7627d8148ecb7fb77afaa89aeab Virtualization: vmware Operating System: CentOS Linux 7 (Core) CPE OS Name: cpe:/o:centos:centos:7 Kernel: Linux 3.10.0-327.el7.x86_64 Architecture: x86-64 # set Master Hostname (kernel parameter / proc/sys/kernel/hostname and file / etc/hostname are updated immediately) [root@centos7 ~] # hostnamectl set-hostname MYHOST # the hostname becomes myhost (static hostname) [root@centos7 ~] # hostnamectl Static hostname: myhost Pretty hostname: MYHOST Icon name: computer-vm Chassis: vm Machine ID: 956ab824a02d489d85b079cb442d5442 Boot ID: 9016d7627d8148ecb7fb77afaa89aeab Virtualization: Vmware Operating System: CentOS Linux 7 (Core) CPE OS Name: cpe:/o:centos:centos:7 Kernel: Linux 3.10.0-327.el7.x86_64 Architecture: x86-64

All of the above systemd-related commands (except systemd-cgls and systemd-cgtop) can use the option-H to specify remote systemd-based hosts (using the ssh protocol):

[root@centos7] # hostnamectl-H 10.0.1.252 Static hostname: idc-v-71252 Icon name: computer-vm Chassis: vm Machine ID: 956ab824a02d489d85b079cb442d5442 Boot ID: 9016d7627d8148ecb7fb77afaa89aeab Virtualization: vmware Operating System: CentOS Linux 7 (Core) CPE OS Name: cpe:/o:centos:centos:7 Kernel: Linux 4.4.4-1.el7.elrepo.x86_64 Architecture: x86-64

Systemd is powerful and easy to use, but it is also complex and the system is huge.

The answers to the questions about the Linux startup process and basic commands are shared here. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

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.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Servers

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report