에듀테크 프로젝트 대시보드
부팅 과정 (Boot Process)
전원 버튼을 누르면 CPU는 메모리가 텅 빈 상태로 깨어난다. 운영체제는 아직 디스크 안에서 잠들어 있다. "아무것도 없는 상태"에서 "리눅스 로그인 프롬프트"까지, 프로그램이 다음 프로그램을 불러오는 연쇄 부트스트랩(bootstrap)이 어떻게 일어나는지 한 단계씩 따라가 본다.
initramfs를 RAM에 올림 →
커널이 드라이버를 켜고 진짜 루트 파일시스템을 마운트 →
init(systemd) PID 1이 서비스를 순서대로 올려 로그인 화면 도달.
펌웨어 방식을 고르고 「전원 켜기」를 누른 뒤 「다음 단계」로 한 칸씩 진행하거나 「자동 진행」으로 흘려보내라. 오른쪽 "고장 주입" 스위치를 켜 두면 특정 단계에서 부팅이 실패한다 — 실제로 자주 겪는 증상들이다.
CPU는 리셋되면 정해진 물리 주소(예: 0xFFFFFFF0)에서 첫 명령어를 가져온다. 그 자리에는 메인보드에 납땜된 펌웨어 칩(플래시 ROM)이 매핑돼 있다. 펌웨어는:
| 레거시 BIOS | UEFI (요즘 표준) | |
|---|---|---|
| 디스크 파티션 | MBR (최대 2TB, 4개) | GPT (사실상 무제한) |
| 부트로더 위치 | 디스크 첫 512바이트(MBR 부트섹터)에 욱여넣음 | ESP(EFI 시스템 파티션)의 .efi 실행 파일 |
| 실행 모드 | 16비트 리얼 모드로 시작 | 처음부터 32/64비트 |
| 보안 | 없음 | Secure Boot(서명된 부트로더만 허용) |
MBR의 512바이트는 너무 작아서 부트로더를 다 담지 못한다. 그래서 여러 단계로 나뉜다: 아주 작은 1단계가 1.5단계를 부르고, 그게 파일시스템을 읽을 줄 아는 2단계(/boot/grub)를 부른다. GRUB이 최종적으로 하는 일:
vmlinuz와 initramfs를 RAM으로 로드.root=UUID=... ro quiet splash.딜레마: 루트 파일시스템(/)이 NVMe SSD·LVM·암호화 볼륨 위에 있다면, 그걸 마운트하려면 드라이버가 필요하다. 그런데 그 드라이버는 아직 마운트 못 한 / 안에 있다. 닭이 먼저냐 달걀이 먼저냐.
해법이 initramfs — 부트로더가 RAM에 올려 준 작은 임시 루트 파일시스템이다. 커널은 이걸 먼저 /로 삼고, 그 안의 스크립트가 필요한 모듈을 insmod 한 뒤 진짜 루트를 찾아 마운트하고, switch_root로 갈아탄다. 그 후 진짜 /sbin/init을 PID 1로 실행한다.
PID 1은 죽으면 커널 패닉이 나는 모든 프로세스의 조상이다. 옛날엔 /etc/rc*.d 스크립트를 번호순으로 하나씩 실행했다(SysV init, 느림). 요즘 systemd는 유닛 간 의존성 그래프를 만들어 서로 무관한 서비스를 병렬로 올리고, 소켓을 미리 열어 두는 방식으로 부팅을 앞당긴다.
# 부팅이 도달하는 목표(target) — 실행 레벨의 후신 graphical.target # GUI 로그인 (구 runlevel 5) └─ multi-user.target # 네트워크 + 콘솔 로그인 (구 runlevel 3) └─ basic.target └─ sysinit.target # 파일시스템 검사, 스왑, udev … $ systemd-analyze # 총 부팅 시간 $ systemd-analyze blame # 서비스별 소요 시간 (느린 놈 찾기) $ systemd-analyze critical-chain # 부팅 임계 경로
power on → CPU가 0xFFFFFFF0 에서 fetch # 펌웨어 코드 → 펌웨어: POST → 부트 순서대로 장치 검색 → 부트로더(GRUB) 로드 BIOS: MBR 첫 512B | UEFI: ESP의 grubx64.efi → GRUB: vmlinuz + initramfs → RAM → 커널 압축 해제 → 드라이버 초기화 → initramfs를 임시 / → initramfs: 모듈 로드 → 진짜 루트 찾기 → switch_root → /sbin/init 실행 = PID 1 (systemd) → sysinit → basic → multi-user → graphical.target → login: <_>