부팅 프로세스, 모듈 관리 및 로더
1. Linux 부팅 프로세스 분석
1.1 부팅 프로세스 개요
시스템 부팅 프로세스는 다음과 같이 요약 할 수 있습니다.
- BIOS의 하드웨어 정보를로드하고 자체 테스트를 수행하고 설정에 따라 첫 번째 부팅 장치를 얻습니다.
- 첫 번째 부팅 장치 (즉, grub2, spfdisk와 같은 프로그램)에서 MBR의 부트 로더를 읽고 실행합니다.
- 부트 로더 설정에 따라 커널을로드하면 커널이 하드웨어를 감지하고 드라이버를로드하기 시작합니다.
- 하드웨어 드라이브가 성공하면 Kernel은 적극적으로 systemd 프로그램을 호출하고 default.target 프로세스로 시작합니다.
- systemd는 sysinit.target을 실행하여 시스템을 초기화하고 basic.target을 실행하여 운영 체제를 준비합니다.
- systemd는 multi-user.target에서 로컬 및 서버 서비스를 실행합니다.
- systemd는 multi-user.target에서 /etc/rc.d/rc.loacl 파일을 실행합니다.
- systemd는 multi-user.target에서 getty.target 및 로그인 서비스를 실행합니다.
- systemd는 그래픽에 필요한 서비스를 수행합니다.
1.2. BIOS, 부트 로더 및 커널 로딩
먼저 고유 명사를 설명해 봅시다.
- BIOS : 기존 BIOS와 UEFI BIOS를 모두 줄여서 BIOS라고합니다.
- MBR : 파티션 테이블은 기존 MBR과 새로운 GPT로 구성되어 있지만 GPT도 일부 MBR 호환 블록을 예약하므로 부트 로더 설치를 위해 아래 지침을 MBR이라고합니다. 간단히 말해 MBR은 부트 로더를 설치할 수있는 디스크의 첫 번째 블록을 나타냅니다 .
1.2.1, BIOS, 부팅 자체 테스트 및 MBR / GPT
개인용 컴퓨터 아키텍처 에서 전체 시스템을 시작하려면 먼저 시스템이 BIOS를로드하고 BIOS를 통해 CMOS 정보를로드 한 다음 CPU와 같은 CMOS의 설정에서 호스트의 하드웨어 구성을 가져와야합니다. 인터페이스 장치와의 통신 빈도, 부팅 장치의 검색 순서, 하드 디스크 크기 및 유형, 시스템 시간 등
이 정보를 얻은 후 BIOS는 POST (Power-On Self-Test)도 수행합니다 . 그런 다음 하드웨어 감지 초기화를 시작하고 PnP 장치를 설정 한 다음 부팅 가능한 장치 시퀀스를 정의한 다음 부팅 장치의 데이터 읽기를 시작합니다 .
우리의 시스템 소프트웨어는 대부분 하드 디스크에 있기 때문입니다! 따라서 BIOS는 디스크에서 운영 체제 커널을 읽을 수 있도록 부팅 장치를 지정합니다. 그러나 운영 체제마다 파일 시스템 형식이 다르기 때문에 커널 파일로드 문제를 처리하기 위해 부팅 관리 프로그램을 사용해야하므로이 부팅 관리 프로그램을 Boot Loader라고 합니다. 이 부트 로더 는 어디에 설치되어 있습니까? 그것은 우리가 항상 MBR (Master Boot Partition) 이라고 말했던 부팅 장치의 첫 번째 섹터에 있습니다.
커널 파일을 읽기 위해서는 Loader가 필요하기 때문에 각 운영 체제의 Loader가 다른데이 경우 BIOS는 MBR에서 Loader를 어떻게 읽습니까? 실제로 BIOS는 하드웨어 INT 13 인터럽트 기능을 통해 MBR을 읽습니다 . 즉, BIOS가 디스크 (디스크가 SATA 또는 SAS 인터페이스인지 여부)를 감지 할 수있는 한 INT 13 채널을 전달할 수있는 방법이 있습니다. 디스크의 첫 번째 섹터에서 MBR 소프트웨어를 읽으려면.
1.2.2, 부트 로더 기능
I 방금 언급 로더의 주요 기능은 오퍼레이팅 시스템의 파일 형식을 인식하고 그에 따라 실행을 위해 메모리에로드한다 . 다른 운영 체제의 파일 형식이 일치하지 않기 때문에 각 운영 체제에는 자체 부트 로더가 있으며 자체 부트 로더를 통해서만 자체 커널 파일을로드 할 수 있습니다 ! 그래서 질문은, 당신은 여러 시스템에 대해 들어 보았어야 했죠? 즉, 여러 다른 운영 시스템은 호스트에 설치되어있다. 이후 ( 1) 자신의 운영 체제 커널을로드하기 위해 자신의 로더를 사용한다 (2) 단일 호스트를 할 수있는 방법 다음, 하나의 MBR이? 동시에 여러 시스템을 설치하는 것은 어떻습니까?
파일 시스템의 기능을 재 호출 할 필요가 있습니다. 사실, 모든 파일 시스템은 부트 로더를 설치 운영 시스템을 제공하는 부트 섹터를 예약한다 , 보통 운영 시스템은 루트 디렉토리가 기본적으로있는 파일 시스템의 부트 로더에 로더의 사본을 설치합니다 . 호스트 중 하나에 Windows와 Linux를 설치하는 경우 부트 섹터, 부트 로더 및 MBR 간의 상관 관계는 다음과 같습니다.
위의 그림에서 볼 수 있듯이 각 운영 체제는 기본적으로 자체 파일 시스템 (즉, 각 파일 시스템의 왼쪽 하단에있는 상자)에 부트 로더 세트를 설치하며 Linux 시스템을 설치할 때 부트 로더를 설치하도록 선택할 수 있습니다. MBR로 이동하여를 설치하지 않도록 선택할 수도 있습니다 . MBR에 설치하도록 선택하면 이론적으로 MBR과 부트 섹터 모두에 부트 로더 프로그램의 사본을 보관하게됩니다. Windows 설치의 경우 기본적으로 MBR과 부트 섹터 모두에 부트 로더를 자동으로 설치합니다 ! 따라서 여러 운영 체제를 설치할 때 MBR이 다른 운영 체제의 부트 로더에 의해 덮어 쓰기되는 경우가 많습니다 .
방금 언급 한 문제는 아직 해결되지 않았습니다! 각 운영 체제는 부트 로더를 부트 섹터에 설치할 수 있지만 운영 체제는 자체 부트 로더를 통해 커널을로드 할 수 있습니다 . 문제는 시스템에 MBR이 하나뿐이라는 것인데 부트 로더에서 로더를 어떻게 실행 합니까? 이를 위해서는 Boot Loader의 주요 기능을 이해해야 합니다 .
- 메뉴 제공 : 사용자는 다양한 부팅 항목을 선택할 수 있으며, 이는 멀티 부팅의 중요한 기능이기도합니다!
- 커널 파일로드 : 부팅 가능한 프로그램 섹션을 직접 가리켜 운영 체제를 시작합니다.
- 다른 로더 로 전송 : 관리를 위해 부팅 관리 기능을 다른 로더로 전송합니다.
메뉴 기능으로 인해 부팅 할 다른 커널을 선택할 수 있습니다. 그리고 제어 전달 기능으로 인해 다른 부트 섹터에 로더를로드 할 수 있습니다 ! 그러나 Windows 로더에는 기본적으로 제어 전송 기능이 없으므로 Windows 로더를 사용하여 Linux 로더를로드 할 수 없습니다 .
위의 그림에서 볼 수 있듯이 MBR은 Linux의 grub2 부팅 관리 프로그램을 사용하며 이미 세 개의 메뉴가 있다고 가정합니다. 첫 번째 메뉴는 Linux 커널 파일을 직접 가리키고 커널을 직접로드하여 부팅 할 수 있습니다. 두 번째 메뉴는 Windows에 부팅 관리 제어 권한을 부여합니다. 이때 Windows Loader가 부팅 프로세스를 인수합니다. 이때 Windows를 시작할 수 있습니다. 세 번째 메뉴는 Boot Loader에서 Linux의 부팅 관리 프로그램을 사용하는 것입니다. 이때 또 다른 grub2 메뉴가 나타납니다.
- 단일 선택 : MBR (grub2) → 커널 파일 → 부팅
- 메뉴 2 : MBR (grub2) → 부트 섹터 (Windows 로더) → Windows 커널 → 부팅
- 메뉴 3 : MBR (grub2) → 부트 섹터 (grub2) → 부팅
1.2.3, 커널을로드하여 하드웨어 및 initramfs 기능 감지
Boot Loader의 관리하에 커널 파일을 읽기 시작하면 Linux는 커널 파일을 메모리로 압축하고 커널의 기능을 사용 하여 저장 장치, CPU, 네트워크 카드, 사운드 카드 등 이때 Linux 커널은 자체 기능으로 하드웨어를 다시 감지하며 BIOS에서 감지 한 하드웨어 정보를 반드시 사용하지는 않습니다. 즉, 커널이 공식적으로 BIOS 작업을 인수했습니다. 그렇다면 코어 파일은 일반적으로 어디에 저장됩니까? 일반적으로 말해서, / boot에 위치하고 이름은 / boot / vmlinuz 입니다.
[root@li ~]# ls --format=single-column -F /boot
config-3.10.0-1127.el7.x86_64 #此版本内核被编译时选择的功能与模块配置文件
efi/
grub/ #旧版的
grub2/ #就是开机管理程序 grub2 相关数据目录
initramfs-0-rescue-1b1f29b2be3d4dafbdcac2da7f5a3c15.img #底下是虚拟文件系统文件！
initramfs-3.10.0-1127.el7.x86_64.img
symvers-3.10.0-1127.el7.x86_64.gz
System.map-3.10.0-1127.el7.x86_64
vmlinuz-0-rescue-1b1f29b2be3d4dafbdcac2da7f5a3c15*
vmlinuz-3.10.0-1127.el7.x86_64* #内核文件。最重要的文件！
하드웨어 개발자와 다른 커널 함수 개발자의 편의를 위해, 리눅스 커널은 동적으로 커널 모듈을로드 할 수 있습니다 , 일반적으로 / lib / modules 디렉토리에 배치됩니다 . 모듈은 디스크의 루트 디렉토리에 위치하므로 ( / lib는 / ! 와 별도의 파티션에 배치 할 수 없음을 기억하십시오 ), 부트 프로세스 중에 루트 디렉토리에 중단되어야 커널 모듈이 드라이버 기능을 제공합니다. . 그리고 디스크의 파일 시스템에 영향을 미치는 것에 대해 걱정하기 위해 루트 디렉토리는 부팅 프로세스 동안 읽기 전용으로 마운트됩니다 .
가상 파일 시스템은 일반적으로 파일 이름 / boot / initrd 또는 / boot / initramfs를 사용합니다. 이 파일의 특징은 부트 로더를 통해 메모리로로드 할 수 있으며, 그런 다음 파일이 압축되고 메모리의 루트 디렉토리로 시뮬레이션된다는 것입니다. 그리고 메모리에있는이 시뮬레이션 된 파일 시스템은 부팅 프로세스 중에 가장 필요한 커널 모듈을로드하는 실행 프로그램을 제공 할 수 있습니다. 일반적으로 이러한 모듈은 USB, RAID, LVM, SCSI 및 기타 파일 시스템과 디스크 인터페이스입니다. 드라이버 . 도움말 커널이 systemd를 다시 호출하여 후속 일반 부팅 프로세스를 시작하기를 기다립니다.
위 그림과 같이 부트 로더는 커널과 initramfs를로드 한 다음 루트 디렉토리라는 메모리에서 initramfs의 압축을 풀 수 있으며 커널은 여기에서 적절한 드라이버를로드하고 마지막으로 가상 파일 시스템을 해제하고 실제 루트 디렉토리를 마운트 할 수 있습니다. 파일 시스템은 후속 일반 부팅 프로세스를 시작할 수 있습니다.
커널이 완전히로드되면 호스트가 올바르게 작동하기 시작하고 시스템의 첫 번째 프로그램 인 systemd 실행을 시작해야합니다 .
1.3, 첫 번째 프로그램 systemd 및 default.target을 사용하여 부팅 프로그램 분석 시작
커널이로드 된 후 하드웨어 감지 및 드라이버로드가 완료되면 호스트 하드웨어가 준비되어 있어야합니다. 이때 커널은 systemd 인 첫 번째 프로그램을 적극적으로 호출합니다. 이것이 pstree -p 명령을 사용할 때 systemd의 PID 번호가 1임을 알게되는 이유 입니다. systemd의 주요 기능은 시스템의 호스트 이름, 네트워크 설정, 언어 처리, 파일 시스템 형식 및 기타 서비스의 시작을 포함하여 소프트웨어 실행을위한 환경을 준비하는 것입니다 . 모든 작업은 systemd의 기본 시작 서비스 세트, 즉 /etc/systemd/system/default.target을 통해 계획됩니다 . 또한 systemd는 수년 동안 사용 된 런레벨을 포기했습니다.
1.3.1, 공통 운영 환경 대상 및 호환성 및 실행 수준
사전 설정된 운영 환경으로 사용할 수있는 주요 항목은 multi-user.target 및 graphics.target입니다. 물론, rescue.target, shutdown.target, emergency.target 등, initrd.target을 포함한 더 특별한 운영 환경이 있습니다.
그러나 과거에 systemV는 시스템을 시작하기 위해 runlevel이라는 개념을 사용했으며, 이전 방식의 systemV 작동 동작과 호환되도록 systemd는 runlevel과 운영 환경을 결합했습니다.
| SystemV | 체계 |
|---|---|
| 초기화 0 | systemctl 전원 끄기 |
| 초기화 1 | systemctl 구조 |
| 초기화 [234] | systemctl은 다중 사용자를 격리합니다. |
| 초기화 5 | systemctl은 graphics.target을 분리합니다. |
| 초기화 6 | systemctl 재부팅 |
1.3.2, 시스템 처리 흐름
/etc/systemd/system/default.target의 기본 작동 인터페이스를 얻은 후 시스템은 다음으로 무엇을할까요? 먼저 / usr / lib / systemd / system / 디렉토리에 링크하여 multi-user.target 또는 graphics.target 중 하나를 얻습니다. graphic.target을 사용한다고 가정하면 systemd는 다음 디렉토리 인 두 위치에서 설정을 찾습니다.
- /etc/systemd/system/graphic.target.wants/： 사용자가로드 된 단위 설정
- /usr/lib/systemd/system/graphical.target.wants/ : 기본적으로로드되는 단위
그런 다음 구성 파일 /usr/lib/systemd/system/graphical.target에서 다음 내용을 찾을 수 있습니다.
[root@li ~]# cat /usr/lib/systemd/system/graphical.target
[Unit]
Description=Graphical Interface
Documentation=man:systemd.special(7)
Requires=multi-user.target #必须先加载 multi-user.target
Wants=display-manager.service #启动完 graphical.target 之后，还必须启动 display-manager.service
Conflicts=rescue.service rescue.target
After=multi-user.target rescue.service rescue.target display-manager.service
AllowIsolate=yes
[root@li ~]# cat /usr/lib/systemd/system/multi-user.target
[Unit]
Description=Multi-User System
Documentation=man:systemd.special(7)
Requires=basic.target #必须先加载 basic.target
Conflicts=rescue.service rescue.target
After=basic.target rescue.service rescue.target
AllowIsolate=yes
시스템은 기본적으로 어떤 장치를로드합니까?
[root@li ~]# ls /usr/lib/systemd/system/multi-user.target.wants/
dbus.service plymouth-quit-wait.service systemd-update-utmp-runlevel.service
getty.target systemd-ask-password-wall.path systemd-user-sessions.service
plymouth-quit.service systemd-logind.service
사용자 정의 단위는 무엇입니까?
[root@li ~]# ls /etc/systemd/system/multi-user.target.wants/
auditd.service kdump.service rhel-configure.service vmtoolsd.service
crond.service NetworkManager.service rsyslog.service
firewalld.service postfix.service sshd.service
irqbalance.service remote-fs.target tuned.service
실제로 시스템의 서비스 시작 프로세스를 알 수있는 가장 쉬운 방법은 systemctl list-dependencies graphics.target 명령 입니다. 그러나 그 뒤에있는 구성 파일의 의미를 알고 싶다면, 각각 / etc 및 / usr / lib 아래에있는 graphics.target.wants / 디렉토리에서 데이터를 찾아야합니다! 물론 구성 파일에서 요구 사항 값으로 표시되는 서비스도 먼저로드해야합니다.
1.3.3, systemd는 multi-user.target에서 서비스를 시작합니다.
커널 드라이버 하드웨어가로드 된 후 sysinit.target의 초기화 과정을 통해 시스템에 액세스 할 수 있으며, 시스템을 운영 체제의 기반으로 만들기 위해 basic.target을 추가 한 다음 서버가 원활하게 실행되는 데 필요한 다양한 호스트 서비스를 제공합니다. 그리고 서버 기능을 제공하는 네트워크 서비스의 시작입니다. 이러한 서비스의 시작은 대부분 multi-user.target 운영 환경에 연결되어 있습니다. /etc/systemd/system/multi-user.target.wants/로 이동하여 기본 시작 서비스를 볼 수 있습니다. 즉, 일반적으로 서비스 시작 스크립트 설정은 다음 디렉터리에 있습니다 .
- / usr / lib / systemd / system : 시스템 기본 서비스 시작 스크립트 설정
- / etc / systemd / syetem : 관리자가 개발하고 설정 한 시작 스크립트
사용자가 호스트의 로컬 서비스와 서버 네트워크 서비스의 다양한 단위를 enbale하려면 /etc/systemd/system/multi-user.target.wants/ 디렉토리에 넣고 링크를 만드십시오. 부팅시 자동으로 시작할 수 있습니다 .
[root@li lib]# systemctl enable vsftpd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/vsftpd.service to /usr/lib/systemd/system/vsftpd.service.
[root@li lib]# systemctl disable vsftpd.service
Removed symlink /etc/systemd/system/multi-user.target.wants/vsftpd.service.
1.3.4, 호환되는 systemV rc-local.service
과거에 Linux를 사용한 적이있는 사용자는 시스템이 부팅 된 후 시스템이 추가 프로그램을 실행하도록 하려면 프로그램 명령 또는 스크립트의 절대 경로 이름을 /etc/rc.s/rc에 쓸 수 있음을 알고있을 것입니다. .local을이 파일에 추가합니다. 새로운 systemd 메커니즘에서는 systemd 시작 스크립트 구성 파일을 / etc / systemd / system에 직접 작성한 다음 rc.local 파일을 직접 사용하는 대신 systemctl enable 메서드를 사용하여 설정하고 시작하는 것이 좋습니다!
새 버전의 systemd와 호환되는 방법이 있습니까? 물론 이것이 rc-local.service 서비스의 기능입니다. 이 서비스는 시작할 필요가 없으며 /etc/rc.d/rc.local에이 서비스를 시작할지 여부를 결정하는 실행 권한이 있는지 여부를 결정합니다.
#1、先看一下 /etc/rc.d/rc.local 的权限，然后检查一下 multi-user.target 有没有这个服务
[root@li lib]# ll /etc/rc.d/rc.local
-rw-r--r--. 1 root root 473 8月 7 01:30 /etc/rc.d/rc.local
[root@li lib]# systemctl status rc-local.service
● rc-local.service - /etc/rc.d/rc.local Compatibility
Loaded: loaded (/usr/lib/systemd/system/rc-local.service; static; vendor preset: disabled)
Active: inactive (dead)
[root@li lib]# systemctl list-dependencies multi-user.target | grep rc-local
#明明就有这个服务，但是 rc.local 不具有执行的权限，因此这个服务不会被执行
#2、加入 x 权限后，再看一下 rc-local 是否可被执行
[root@li lib]# chmod a+x /etc/rc.d/rc.local; ll /etc/rc.d/rc.local
-rwxr-xr-x. 1 root root 473 8月 7 01:30 /etc/rc.d/rc.local
[root@li lib]# systemctl daemon-reload
[root@li lib]# systemctl list-dependencies multi-user.target | grep rc-local
● ├─rc-local.service #这个服务确实被记录到启动的环境下了
chmod a + x /etc/rc.d/rc.local을 사용하면 많은 스크립트를 /etc/rc.d/rc.local 파일에 배치 할 수 있으며 시스템은 시스템이 부팅 될 때마다이 파일의 파일을 실행합니다. 교수.
1.3.5 부팅 프로세스에 사용되는 주요 구성 파일
기본적으로 systemd에는 자체 구성 파일 처리 방법이 있지만 systemV와 호환되기 위해 많은 스크립트 설정은 여전히 / etc / sysconfig /에있는 환경 구성 파일을 읽습니다. 공통 구성 파일 :
-
모듈 정보 : /etc/modprode.d/ .conf 및 /etc/modules-load.d/ .conf
사실, 모듈 로딩 문제를 다룰 두 곳이 있습니다 :
- /etc/modprode.d/*.conf : 단순히 모듈을로드 할 커널의 위치를 원합니다.
- /etc/modules-load.d/*.conf : 모듈 매개 변수의 위치를 추가 할 수 있습니다.
-
/ etc / sysconfig / *
-
authconfig
이 파일은 주로 로컬 / etc / passwd, / etc / shadow 등을 사용할지 여부와 / etc / shadow 암호 레코드에 사용되는 알고리즘 암호화를 포함하여 사용자의 신원 인증 메커니즘을 규제하는 데 사용됩니다.
-
cpupower
이 파일은 cpupower.service 서비스가 시작될 때 읽 힙니다.
-
firewalld ， iptables-config ， etables-config
방화벽 관련 매개 변수
-
네트워크 스크립트 /
-
이 파일은 주로 로컬 / etc / passwd, / etc / shadow 등을 사용할지 여부와 / etc / shadow 비밀번호 레코드를 암호화하는 알고리즘을 포함하여 사용자의 신원 인증 메커니즘을 규제합니다.
-
cpupower
이 파일은 cpupower.service 서비스가 시작될 때 읽 힙니다.
-
firewalld ， iptables-config ， etables-config
방화벽 관련 매개 변수
-
네트워크 스크립트 /
네트워크 카드 설정 매개 변수