Linux 부팅 과정 요약
HW 단계
- 전원을 켬
- BIOS(or UEFI)에서 HW를 검색
BootLoader 단계
- BootLoader 위치 찾기 & 시작
- BootLoader에서 OS 고르기
Kernel 단계
- 4번 단계에서 선택한 OS에 맞는 Kernel과 초기 RAM 디스크(initrd) 시작
INIT 단계(SysV / Systemd)
- 초기화된 프로세스(init or systemd) 시작
- 선택된 Run Level이나 Target에 따라 서비스 시작
Linux에서 Booting은 위 모든 과정을 거쳐야지 일어난다.
Linux 부팅 프로세스 한눈에 보기
출처 : https://ocw.unican.es/pluginfile.php/681/course/section/340/topic_3.pdf
Linux 시스템의 부팅 프로세스는 위 사진과 같다.
크게 보자면 Hardware 단계, Bootloader 단계, Kernel 단계, Init 단계 순서로 이루어진다.
각 단계에서 어떤 일이 일어나는지 자세히 알아보자.
Hardware 단계
1. 전원 킴
Power 버튼을 눌러 전원이 공급되고 메인보드는 Reset Vector를 통해 CPU가 BIOS 코드를 호출하도록 하는 단계이다.
전원이 켜진 후 Reset Vector를 통해 접근한 BIOS나 UEFI를 "펌웨어(Firmware)"라고도 하는데, 이 펌웨어는 시스템의 HW 구성을 저장하고 있다.
Reset Vector를 통해 펌웨어에 접근한 후 CPU가 BIOS Code(펌웨어 코드)를 실행시켜 저장된 HW 구성을 불러오는 것이다.
2. HW 검색
BIOS(Firmware)에 저장된 HW 구성을 활용해 HW를 검색하는 과정인데 크게 "BIOS POST"와 "BOOT SECTOR" 단계로 나눌 수 있다.
POST(Power-on-selft-test) 과정은 BIOS 무결성 검사(Integrity check) 과정이라고도 부른다.
이 과정에선 CPU, RAM, 제어 장치, BIOS Code, 주변 장치 등 Linux에서 활용할 HW에 대한 검사를 진행한다.
만약 이 과정에서 일부 HW 장치가 감지되지 않거나 손상이 감지될 경우 개입하여 해결하라는 오류 메시지를 띄운다.
POST 과정을 통해 모든 HW가 예상했던 대로 존재하고 정상 동작한다는 것을 확인하면 BOOT Sector 단계로 넘어간다.
BOOT Sector 단계를 알아보기 전 "Boot Sector"의 단어 의미부터 알면 좋다.
부트 섹터(boot sector)는 디스크의 다른 부분에 저장되는 부팅 프로그램(보통 운영 체제 자체를 뜻하지만, 반드시 그러한 것은 아님)을 담을 수 있는 하드 디스크, 플로피 디스크, 또는 비슷한 기억 장치의 섹터를 말한다.
시동 섹터 또는 부트블록(bootblock)이라고 부르기도 한다
- 출처 : 위키피디아
좀 더 풀어서 말하자면 Boot Sector는 "컴퓨터나 디스크의 Booting Process 시 필요한 코드가 저장된 Sector"라고 할 수 있다.
이때 중요한 개념 2가지가 있는데 바로 "MBR"과 "VBR"이다.
MBR은 Master Boot Recorder의 약자로써 OS가 어디에 어떤 형식으로 위치해 있는지를 식별하여 컴퓨터의 주기억장치에 적재될 수 있도록 한 정보이다.
MBR에 대해 알기 전 "디스크 파티션"에 대한 개념을 살짝 알고 갈 필요가 있다.
디스크 파티션이란 하드디스크 드라이브의 기억 공간을 "Partition"이라고 부르는 별도의 데이터 영역으로 분할한 것을 말한다.
디스크 파티션에 대해서는 나중에 다시 다룰 기회가 있을 것이며 지금은 "하드디스크의 기억 공간을 용도에 따라 나눠 놓은 것"이라고만 알아두자.
분리해 놓은 Partition들은 내부적으로 다시 분리되는데 이때 다시 분리된 Block 중 첫 번째 Block 집합을 EBR(Extended Boot Recorder)라고 한다.
EBR 중 파티션 테이블(Partition Table)이 존재하는 Partition의 첫 번째 블록이 MBR이다.
MBR은 설정된 Partition에 관한 여러 정보를 저장하고 있으며 이 때문에 Partition Sector라고도 부른다.
MBR에 저장되어 있는 정보 중 가장 중요한 것은 "Boot Loader 코드(부트로더 코드)"이다.
MBR은 BootLoader Code를 찾으면 메모리에 로드시키고 이때부터 SW적인 Booting이 시작된다고 할 수 있다.
(Linux의 GRUB이 대표적인 BootLoader이다)
그렇다면 위에서 중요하다고 했던 또다른 개념인 VBR은 무엇일까?
위에서 "Partition Table이 발견될 경우" 첫 번째 Block이 MBR이라고 말했다. 그렇다면 만약 Partition Table이 없다면 어떨까? 즉, Partition을 수행하지 않아 Partition Table이 존재하지 않는 경우는 어떻게 될까?
Partition Table이 없으니 MBR도 없고 MBR이 저장하고 있는 BootLoader Code가 없으니 Booting이 불가능한 것은 절대 아닐 것이다. 만약 그렇다면 Partition을 수행하지 않은 초기 기기의 경우 영원히 킬 수 없는 상황이 벌어질 것이니 말이다.
이처럼 Partition되지 않은 장치의 Boot Sector 역할을 하는 것이 "VBR"이다.
VBR(Volume Boot Recorder)은 각 Primary Partition의 첫 번째 Block을 의미하며 만약 Partition Table이 존재하지 않을 경우 이곳에 BootLoader Code와 부트로더 코드의 고윳값인 Boot Signature(부트 시그니처) 값이 저장되어 있다.
그리고 Booting 과정에서 Partition Table을 가지지 않는 Partition 되지 않은 장치의 경우 VBR이 시동섹터 역할을 하여 MBR 없이도 Linux Booting이 가능한 것이다.
BootLoader 단계
Boot Sector 단계에서 BootLoader Code를 메모리에 적재시켰다.
이후 ROM-BIOS는 MBR의 BootLoader에 제어권을 넘겨주고 제어권을 넘겨받은 BootLoader가 Booting 과정을 담당하게 된다.
제어권을 넘겨받은 GRUB(Grand unified Boot Loader; Linux Bootloader 이름)은 GRUB 설정 파일을 찾고 3 ~ 5초 동안의 시간을 카운트하는데 이때 사용자는 아무 키나 눌러 GRUB에 개입할 수 있다.
만약 아무런 개입이 없다면 GRUB은 GRUB 설정 파일인 /boot/grub/grub.conf & /etc/grub.conf에 저장되어 있는 내용 대로 Booting을 수행하게 된다.
이 GRUB의 가장 큰 목표는 Linux 커널의 위치를 확인하고 확인된 커널들을 메모리(RAM)에 Load 시켜 다음 단계에서 Kernel들이 실행될 수 있는 상태로 만드는 것이다.
현재는 GRUB ver.2인 GRUB2가 가장 보편적으로 많이 활용되며 GRUB2는 GRUB Stage 1 > 1.5 > 2 총 3단계를 거치는 BootLoader이다.
각 GRUB Stage에 어떤 일이 일어나는지는 그렇게까진 중요하지 않으므로 간단히만 알고 넘어가자.
- GRUB Stage 1 : MBR(or VBR)에 저장된 부트 이미지(boot.img)가 메모리에 Load되고 실행
- GRUB Stage 1.5 : MBR과 첫 번째 Partition 사이에 있는 Block에 저장된 부트 이미지(core.img)가 메모리에 로드되고 실행되어 Configuration 파일과 파일 시스템을 위한 드라이버를 로드함
- GRUB Stage 2 : 커널 압축 파일(vmlinuz)을 풀어 메모리에 로드하고 드라이버, 모듈, 파일 시스템 등이 담긴 RAM 디스크 파일(initrd.img)을 메모리에 로드함
User가 Boot Loader에 개입하는 이유
- RunLevel 변경
- Kernel 단계에서 실행시킬 커널을 다른 것으로 변경시키고 싶음
- 기본 설정과 다른 OS로 Booting 시키고 싶음
- Booting Option을 추가시키고 싶음
Kernel 단계
Mount란?
Kernel 단계에 대해 공부하기 전 "Mount"라는 개념에 대해 알고 갈 필요가 있다.
Windows에서는 많이 활용되지 않지만 Linux에서는 필수라 해도 과언이 아닐 정도의 개념이다.
Linux에서는 하드디스크의 Partition, CD/DVD, USB 등의 물리적 장치를 사용하기 위해선 특정 위치에 연결을 시켜줘야 한다. 물리적 HW를 특정한 위치(대부분 Directory)에 연결시켜주는 과정을 Mount라고 한다.
예를 들어보자. "test.txt"라는 파일을 "/dev/sda1"이라는 물리적 장치에 저장할 것이다.
이 물리적 장치 "/dev/sda1"은 무조건 특정 위치에 Mount되어 있어야 사용 가능하며, 이 때문에 /dev/sda1을 /home/djlim이라는 디렉터리와 Mount 시켰다.
이 경우 /home/djlim이라는 디렉터리 아래 "test.txt"가 저장되어 있는 것이다.
만약 이후에 "/dev/sda1" 장치를 /home/dj라는 다른 디렉터리와 Mount 시켰다고 가정하자.
이 경우 "test.txt"는 /home/djlim 디렉터리와 Mount 되어 있을 때 저장한 파일이며 현재는 "/dev/sda1" 장치가 /home/dj와 Mount 되어 있기 때문에 /home/djlim에 접근할 수 없어 test.txt는 볼 수 없다.
하지만 test.txt 파일은 Path 접근할 수 없을 뿐 여전히 "/dev/sda1" 장치에 저장되어 있는 것이다.
Kernel 단계 수행 과정
Kenrel은 Linux 시스템의 핵심으로 컴퓨터와 각종 HW를 사용하는데 필요한 드라이버와 모듈을 로드시키고 기본 프로세스와 연결(Mount)시켜주는 역할을 한다.
이 과정에서 HW 관련 기능이 올바로 동작하지 않는 문제를 차단하기 위해 HW 실패를 찾는 과정을 거친다.
(ex. 설정되지 않은 다른 드라이버가 로드되는 문제)
BootLoader 단계까지 거치며 현재 주메모리(RAM)에는 vmlinux라는 커널 파일과 RAM 디스크 파일인 initrd.img 파일이 로드되어 있는 상태이다.
커널 단계는 메모리에 로드된 2개 파일을 실제 실행시키는 과정이라고 생각하면 된다.
커널 파일을 실행하는 단계는 아래와 같다.
- 주 메모리에 로드되었던 커널 파일 실행
- HW 실패를 찾아보고 결과를 /var/log/dmesg 파일에 기록
- HW 실패가 없을 경우 Kernel은 Swapper Process(PID 0)를 호출하여 커널이 사용할 각 장치 드라이버들을 초기화시킴
- Root File System("/")을 읽기 전용으로 마운트
- 커널이 문제없이 실행된다면 Unmount
- Root File System을 읽기+쓰기 모드로 다시 마운트
- Init Process(PID 1) 호출
"/sbin/init" 프로그램을 실행시킴으로써 PID 1이 할당된 Init 프로그램을 실행시킬 수 있다.
Init 프로그램은 다양한 Daemon을 생성하고 /etc/fstab 파일에 지정된 모든 Partition을 마운트 시키는 역할을 담당한다.
이후 커널은 실제 루트 파일 시스템이 마운트 되기 전까지 임시 루트 파일 시스템인 initrd(Initial Ram Disk)를 마운트 하여 임시 루트 파일 시스템(Temporary Root File System)으로 활용한다.
/var/log/dmesg에 기록된 내용 확인하기
위에서 /var/log/dmesg 파일에 커널 파일을 실행한 Log를 저장한다고 했다.
그렇다면 dmesg 내용을 어떻게 확인할 수 있는지 간단히 알아보자.
- dmesg | grep Memory : 메모리 정보만 출력
- dmesg | grep sda : 하드디스크 정보만 출력
- dmesg | grep SCSI : SCSI 타입의 하드디스크 정보만 출력
- dmesg | grep hda : IDE 타입의 하드디스크 정보만 출력
- dmesg | grep eth : NIC 정보만 출력
- dmesg | grep usb : USB 정보만 출력
- dmesg | grep Linux : 커널 정보만 출력
INIT 단계
SysV vs Systemd
예전 Linux는 "SysV"라는 Init 프로그램을 사용하였지만 현재는 Systemd라는 Init 프로그램을 주로 활용한다.
SysV에서는 "init.d"라는 디렉터리에 init 프로세스가 실행되기 위한 Script 파일들을 저장하였다.
그래서 프로그램 한 개를 설치할 때마다 프로그램의 기동 & 종료 스크립트가 init.d 디렉토리에 설치되고 부팅될 때마다 기동 스크립트가 실행되었다.
하지만 시간이 흐르며 SysV를 대체한 Systemd의 사용률이 점차 높아졌으며 현재는 Systemd가 사실상 모든 Linux의 Init System 역할을 수행한다.
Systemd는 리눅스 시스템의 모든 정보를 동일한 Interface로 모아 관리해 준다.
SysV에서는 init.d 디렉터리 내에 프로그램들 각각의 시동 스크립트가 저장되어 있어 관리자가 RunLevel에 따라 Start 시키거나 Stop 할 스크립트를 개별 지정해 줄 수 있었다.
Systemd는 통합 시스템(인터페이스)에 .service라는 파트를 따로 저장하여 중앙 집권적으로 Start 혹은 Stop 시킬 스크립트를 등록할 수 있다.
처음에는 사용 방법이 복잡하며 중앙 통제적인 Systemd는 반발도 많았으나 서비스 제어 면에서 Systemd가 현격히 높은 성능을 가졌고 시스템 부팅 과정들을 병렬화하여 동작시킴으로써 SysV보다 시작 속도가 빠르다는 점에서 Systemd가 주요 Init 프로세스가 되었다.
Run Level
Target Unit에 대해 공부하기 전 "Run Level"에 대해 공부할 필요가 있다.
Run Level이란 Linux System을 조금 더 쉽게 관리하기 위하여 서비스 실행을 단계별로 구분하여 적용하는 것을 말한다.
0 ~ 6까지 존재하며 숫자가 낮은 Run Level일 수록 시스템 시작 시 불러오는 드라이버와 Daemon 수가 적다.
RunLevel은 높아지는 방향으로 진행되며 Booting 시 Run Level 0부터 지정한 Run Level까지 진행된다.
각 RunLevel은 아래와 같은 의미를 가진다.
- 0(halt)
- 시스템 종료
- Run Level을 0으로 지정시 시스템이 종료됨
- 1(Single User Mode)
- 시스템 복원모드라고도 부름
- Run Level 1일 경우 기본적으로 관리자 권한을 얻음
- 파일시스템을 점검하거나 관리자 암호를 변경할 때 사용
- Window 안전 모드의 Linux 버전
- 2(Multiuser without NFS)
- NFS(Network File System)을 지원하지 않는 다중 사용자 모드
- 3(Full multiuser mode)
- CLI Multi-User Mode
- 그래픽을 지원하지 않음
- RunLevel 3에서 네트워크를 사용하지 못할 경우 Run Level 2와 동일함
- 4(unused)
- 임의로 정의해 사용할 수 있는 레벨이지만 기본적으로 사용하지 않음
- 5(X11)
- GUI 환경을 제공하는 Multi-User Mode
- 6(Reboot)
- 시스템 재부팅
- Run Level을 6으로 지정하면 시스템을 재부팅함
- Default Run Level을 6으로 지정하면 재부팅이 계속해서 발생할 것이므로 Default로 지정하면 안 됨
Target Unit
Systemd는 리눅스 시스템을 보조하는 풀타임 프로세스로써 Target Unit이라는 것을 활용하여 파일 시스템 마운트, 동기화 프로세스, 서비스 시작 및 중지 등을 관리한다.
그렇다면 Target Unit 종류에 대해 알아보자.
- poweroff.target(RunLevel 0)
- 시스템을 끔
- rescue.target(RunLevel 1)
- 단일 사용자 환경을 제공하는 복구 쉘 제공
- Root File System이 읽기+쓰기 권한을 가지고 Mount 됨
- multi-user.target(runlevel 2,3,4)
- CLI 환경 제공
- 모든 Linux 작업 가능
- Multi User 사용 가능
- graphical.target(runlevel 5)
- GUI 환경 제공
- 모든 Linux 작업 가능
- 기본적으로 제공되는 Target Unit이 아니므로 별도 설치가 필요함
- reboot.target(runlevel 6)
- System을 재시작시킴
GUI를 사용하는 Desktop Workstation Linux의 경우 대부분 default.target은 Run Level 5인 graphical.target으로 설정되어 있으며 CLI만 사용하는 Server Linux의 경우 RunLevel 3인 multi-user.target이 default.target으로 설정되어 있다.
Systemd가 Linux를 Booting 하는 과정
Systemd는 "/lib/systemd/system/default.target"을 첫 번째 Target Unit으로 실행시킨 뒤 계속해서 다른 Target Unit을 실행시킴으로써 Linux 시스템이 부팅되어 있어야 하는 상태를 만들어낸다.
Target Unit(Service) 파일 형식 중 가장 중요한 Unit 구조는 아래와 같다.
[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
...각 Section은 아래와 같은 의미를 가지고 있다.
- Description : 설명
- Documentation : Target Unit 설명이 적힌 Manual 경로
- Requires : Hard Dependencies. 무조건 실행되어야 하는 Target Unit
- Wants : Soft Dependencies. 실행이 필수까지는 아니지만 선호되는 Target Unit
- After : 현재 Target Unit이나 service 실행 이후에 Booting 할 Target Unit이나 Service 목록
- Conflicts : A의 설정이 Conflicts=B일 경우 A가 시작될 경우 B가 중지되고 A가 중지될 경우 B가 시작되는 역의 관계를 가짐
사진으로 보는 Target Unit
default.target이 graphical.target의 심볼릭 링크로써 연결되었음을 알 수 있다.
따라서 Systemd는 가장 처음에 "graphical.target" Target Unit 파일을 실행시킨다.
위 사진을 보면 Run Level에 따라 다른 Target Unit이 연결되었음을 알 수 있다.
Run Level 확인 및 변경
현재 Run Level을 확인하는 방법은 쉬운데 바로 아래 명령어만 입력하면 된다.
runlevel
runlevel 명령어를 입력할 경우 "N 5"라는 값이 출력됨을 알 수 있다.
첫 번째 자리는 "이전에 실행되던 Run Level", 두 번째 자리는 "현재 실행되고 있는 Run Level"을 의미한다.
두 번째 자리에 5라는 숫자가 적혀있으므로 현재 Run Level은 5(X11; Graphical Mode) 임을 알 수 있다.
그렇다면 N은 무엇일까?
runlevel 명령어를 입력했을 때 숫자가 아닌 "N"과 "S"가 나오는 경우가 있다.
N이란 Linux Booting 후 한 번도 부팅 레벨이 변경되지 않았음을 의미한다. 즉, 현재 Linux 컴퓨터를 켠 이후 필자는 Run Level을 변경한 적이 없으며 따라서 현재 실행되고 있는 Run Level 5가 초기 Run Level 값이다.
처음 Run Level 이전에 실행된 Run Level이라는 개념은 있을 수 없는 개념이므로 "존재하지 않는다"라는 의미를 가진 "N" 문자를 출력하는 것이다.
S는 "Single User"에서 따온 의미로 Run Level 1과 동일한 의미이다.
그렇다면 Run Level을 어떻게 변경할 수 있을까?
init [원하는 Run Level]그렇다면 현재 Run Level 5(Graphical Mode)인 상태에서 Run Level 3(CLI Mode)로 "init 3" 명령어를 통해 바꿔보자.
CLI 형태로 바뀐 것을 볼 수 있다. 이전 RunLevel 5에서 현재 3으로 바뀌었으니 "runlevel" 명령어를 입력했을 경우 "5 3"이 출력되어야 할 것이다. 확인해보자.
Default Run Level 변경
마지막으로 Linux Booting 시 처음으로 지정되는 Default Run Level 변경 방법을 알아보자.
Linux Booting 과정에서 "default.target"이 가장 첫 번째로 실행되는 Target Unit이라고 설명했다.
즉, "default.target"이 어떤 파일이냐에 따라 가장 처음으로 지정되는 Default Run Level이 설정된다는 것을 알 수 있다.
(Target Unit과 Run Level 간 연결은 위에 명시해 놨다.)
default.target을 변경시키는 명령어는 아래와 같다.
sudo systemctl set-default [Target Unit 파일 이름]
# ex : multi-user Target Unit을 사용하고 싶을 경우 multi-user.target 입력그렇다면 Run Level 5인 상태에서 3으로 바꾼 뒤 Reboot 시키고, 다시 5로 바꾼 뒤 Reboot 시켜보자.
5 → 3으로 Run Level 변경
CLI로 변경되었음을 확인할 수 있다. 즉 Default Run Level이 3이 되었다. 다시 5로 바꾼 뒤 Reboot 시켜보자.
다시 Graphical Mode(GUI)로 변경되었다. 즉, Default Run Level이 5가 되었다.
추가로 직접 default.target을 원하는 Target Unit 파일에 심볼릭 링크를 걸어줘도 된다.
하지만 귀찮은 작업이니 위에서 설명한 간단한 명령어 하나로 수정하자.
UEFI
BIOS는 위에서 말했듯 컴퓨터를 켜고 HW에 대한 검사를 진행한 뒤 제어하고 OS를 부팅시키는 역할을 하는 SW이다.
하지만 현재에 Legacy BIOS라고 불리는 예전 BIOS 대신 BIOS 후속 진화 버전인 UEFI를 더 많이 사용한다.
Legacy BIOS는 위에서 말했듯 "MBR"이라는 것을 활용하지만 UEFI는 "GPT 파티션"이라는 개념을 활용한다.
즉, UEFI의 장점은 곧 "GPT 파티션을 도입함으로써" 생긴 장점이라 이해해도 괜찮을 것이다.
그렇다면 UEFI가 어떤 장점이 있어 많이 활용되는지 알아보자.
2.2 TiB 이상의 저장장치 인식 가능
Legacy BIOS의 가장 큰 문제는 2.2 TB 이상의 디스크를 인식할 수 없다는 것이다.
즉 MBR은 2.2 TiB보다 큰 디스크를 사용하는 경우에도 2.2 TiB 공간만 활용할 수 있는 것이다.
이유는 BIOS의 경우 x86 기반 CPU와 16 Bit Real Mode 코드에 크게 의존하는데 Real Mode의 주소 공간이 1 Mbytes로 한정되어 있어 이런 문제가 생긴다.
UEFI는 32bit/64bit Native Code를 사용한 고기능 처리 및 GPT Partition이라는 새로운 방식으로 디스크를 관리하므로 2.2 TiB 이상의 디스크 또한 사용 가능하다.
UEFI는 2.2 TiB 이상 디스크의 모든 공간을 활용할 수 있으므로 2.2TiB 이상의 디스크를 OS의 설치 및 메인 디스크로 활용할 수 있게 되었다.(BIOS는 2.2TiB 이상의 디스크는 데이터 디스크로만 사용 가능하며, 그 또한 2.2TiB 밖에 사용하지 못함)
보안 부팅
Boot Code가 변조되지 않았음을 보증하는 기능을 "보안 부팅"이라고 한다.
UEFI는 Boot Code를 수정하는 작업을 모두 차단하기 때문에 바이러스나 멀웨어 등이 Boot Code를 수정하는 공격에 대해 안전하여 시스템의 안정성이 높아진다.
GUI를 통한 설정
UEFI는 GUI 화면을 지원하여 아이콘과 이미지 등이 활용된 직관적인 Booting 설정 화면을 가지고 있다.
또한 BIOS는 부팅 시 특정 1개 섹터만 사용하지만 UEFI는 부팅 과정에 전체 메모리에 액세스 할 수 있어 Legacy BIOS에서 하지 못하는 추가 설정이 가능하다.
부팅 속도 증가
출처 : https://ocw.unican.es/pluginfile.php/681/course/section/340/topic_3.pdf
위 사진에서 보는 것처럼 UEFI와 BIOS의 부팅 과정은 차이가 있다.
위 사진과 설명에서 알 수 있듯 BIOS는 HW 점검이나 BootLoader가 GRUB을 호출하는 과정 등 중간 과정이 많이 존재한다.
UEFI는 이런 과정을 모두 생략하고 UEFI의 GPT Partition이 GRUB의 역할을 포함하여 모든 과정을 수행한다.
즉, HW 및 BootLoader 단계를 Boot Manager가 모두 수행하기 때문에 부팅 속도가 매우 빠르다.
마무리 지으며
처음 Linux를 공부했을 때만 해도 대충 배우고 넘어갔기에 정리하는데 시간이 별로 안 걸리는 쉬운 개념인 줄 알았다.
하지만 이 Section만 3일째 정리하면서 진이 다 빠진 것 같다. 정말 어려운 개념이었다.
정리한 내용을 통해 Linux Booting은 "BIOS → MBR → GRUB → Kernel → Init" 단계를 거친다 정도와 UEFI & BIOS 차이 정도만 알아두면 성공한 게 아닐까 싶다
참고
