리눅스 시작 프로세스

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요
2. 시스템 시작
3. 부트로더 단계
4. 커널 단계
- 4.1. 커널 로딩
- 4.2. 커널 초기화
5. 초기 사용자 공간 (initramfs)
6. Init 프로세스
참조

1. 개요

리눅스 시작 프로세스는 하드웨어의 종류에 따라 여러 단계를 거친다. BIOS, UEFI, 임베디드 시스템 등 각기 다른 방식으로 시스템이 시작되며, 부트로더 단계, 커널 로딩 단계를 거쳐 init 프로세스를 실행한다. 부트로더는 BIOS 시스템에서 MBR을 통해, UEFI 시스템에서는 GRUB 2 또는 systemd-boot 등을 통해 실행되며, 커널은 메모리에 로드되어 압축 해제된 후 초기화 과정을 거친다. Init 프로세스는 SysV init, systemd, Upstart, runit 등 다양한 방식으로 사용자 공간을 부트스트랩하며, 파일 시스템 마운트 및 다른 프로세스 시작 등의 역할을 수행한다.

더 읽어볼만한 페이지

부팅 - 마스터 부트 레코드
마스터 부트 레코드(MBR)는 저장 장치의 파티션 정보를 담은 512바이트 영역으로, 파티션 테이블, 부트스트랩 코드 등으로 구성되어 BIOS 펌웨어가 실행하여 운영체제 부팅을 시작하지만, 2TiB의 디스크 크기 제한으로 GPT 파티션 테이블로 대체되고 있다.
부팅 - 부팅 디스크
부팅 디스크는 운영 체제 설치, 데이터 복구 등을 위해 사용되는 보조 기억 장치이며, BIOS 설정에 따라 플로피 디스크, CD-ROM, USB 메모리 등 다양한 매체로 부팅하며, 운영 체제에 따라 필요한 파일이 다르다.
리눅스 - 리누스의 법칙
리누스의 법칙은 오픈 소스 개발에서 많은 개발자가 코드 검토에 참여할수록 버그가 빨리 발견되고 수정된다는 개념을 담고 있지만, 개발 환경에 따라 효과가 달라질 수 있다는 비판도 존재한다.
리눅스 - 2038년 문제
2038년 문제는 유닉스 시간의 정수 오버플로우로 인해 2038년 1월 19일 이후에 오류가 발생하는 문제이며, 64비트 시스템 전환 등으로 해결하려 한다.

리눅스 시작 프로세스
리눅스 부팅 프로세스
설명	리눅스 시스템을 시작하는 다단계 초기화 과정이다.
단계별 개요
1단계 부트 로더	1단계 부트 로더
2단계 부트 로더	2단계 부트 로더
커널	커널
init 프로세스	init 프로세스

2. 시스템 시작

리눅스 시스템이 시작되는 과정은 컴퓨터의 하드웨어 구조에 따라 여러 단계로 나뉜다. IBM PC 호환 기종과 같은 하드웨어는 리눅스가 자주 사용되는 대표적인 구조 중 하나이며, 이러한 시스템에서는 BIOS 또는 UEFI 펌웨어가 부팅 과정에서 중요한 역할을 수행한다.

2. 1. BIOS 시스템

IBM PC 호환 기종과 같은 하드웨어는 리눅스가 자주 사용되는 대표적인 구조 중 하나이다. 이런 시스템에서는 BIOS가 부팅 과정에서 중요한 역할을 담당한다.

BIOS 기반 시스템에서는 부팅 시 가장 먼저 BIOS가 전원 켜기 자가 진단(POST, Power-On Self-Test)을 실행한다. 이 과정을 통해 시스템의 하드웨어를 점검하고, 연결된 장치들을 확인(열거)한 뒤 시스템을 초기화한다.

시스템 초기화 과정에서 BIOS는 운영체제(OS)가 설치된 부팅 가능한 장치를 찾는다. 부팅 가능한 장치로는 플로피 디스크, CD-ROM, USB 플래시 드라이브, 하드 디스크의 특정 파티션(예를 들어, 윈도우와 페도라처럼 여러 운영체제가 설치된 경우), 또는 네트워크 상의 저장 장치 등이 될 수 있다.

리눅스를 부팅하는 데 사용되는 하드 디스크에는 보통 마스터 부트 레코드(MBR)가 저장되어 있다. MBR에는 시스템 메모리(RAM)로 가장 먼저 불러올 1단계 부트로더(기본 부트로더)가 포함되어 있다.

2. 2. UEFI 시스템

UEFI 시스템에서는 리눅스 커널을 EFI 부트 스텁을 통해 UEFI 펌웨어가 직접 실행할 수 있다.^[2] 하지만 일반적으로는 GRUB 2나 systemd-boot와 같은 부트로더를 사용한다.^[3]^[4]

UEFI 보안 부팅 기능이 지원되는 경우, 부트로더나 EFI 스텁이 포함된 커널이 실행되기 전에 "shim" 또는 "Preloader"라는 프로그램이 UEFI에 의해 먼저 부팅되는 경우가 많다.^[5] "shim" 또는 "Preloader"는 UEFI의 키 데이터베이스를 수정하지 않고도, 이후 부팅 단계에서 필요한 서명을 검증하기 위한 추가적인 키 데이터베이스 역할을 한다. 이를 통해 UEFI와 동일한 방식으로 다음 부팅 단계로 넘어갈 수 있게 해준다. UEFI 보안 부팅 기능이 비활성화된 상태라도, 나중에 이 기능을 활성화할 경우를 대비하여 "shim"이나 "Preloader"가 시스템에 존재하며 부팅 과정에 포함될 수 있다.

2. 3. 임베디드 시스템

임베디드 리눅스 시스템의 시스템 시작 단계는 온칩 부트 ROM의 펌웨어 또는 프로그램을 실행하는 것으로 시작한다. 이 부트 ROM은 eMMC, eUFS, NAND 플래시 등과 같은 저장 장치에서 부트로더나 운영 체제를 로드하는 역할을 한다. 시스템 시작 순서는 사용되는 프로세서에 따라 다르지만, 일반적으로 하드웨어 초기화 및 시스템 하드웨어 테스트 단계를 포함한다.

예를 들어, NXP의 i.MX 7D 프로세서와 부팅 가능한 장치(U-Boot 포함)가 있는 시스템의 경우, 온칩 부트 ROM은 먼저 DDR 메모리 컨트롤러를 설정한다. 이를 통해 부트 ROM의 프로그램은 부팅 가능한 장치의 외부 부트로더에서 SoC 구성 데이터를 얻을 수 있다. 그 후, 온칩 부트 ROM은 U-Boot을 부트로더 단계의 DRAM으로 로드한다.

3. 부트로더 단계

부트로더는 운영 체제 커널을 메모리에 로드하고 실행하는 중요한 역할을 담당한다. 이 단계의 구체적인 과정은 컴퓨터 하드웨어 구조에 따라 달라질 수 있으며, 특히 IBM PC 호환 시스템에서는 바이오스(BIOS) 또는 UEFI 방식의 영향을 받는다.

일반적으로 부트로더는 부팅 과정에서 사용자에게 운영 체제 선택 메뉴나 관련 옵션을 보여주기도 한다. 사용자가 특정 항목을 선택하거나, 정해진 시간 동안 입력이 없으면 기본 설정된 운영 체제의 커널을 메모리로 불러온다. 이때 커널 실행에 필요한 초기 매개변수들을 함께 전달하고 시스템의 제어권을 커널에게 넘겨준다.

리눅스 시스템에서는 다양한 종류의 부트로더가 사용된다. 가장 널리 알려진 것은 GRUB(GRand Unified Bootloader)이며, 과거에는 LILO(LInux LOader)도 많이 사용되었다. 이 외에도 특정 파일 시스템이나 환경에 특화된 SYSLINUX, UEFI 환경을 위한 systemd-boot 등 여러 부트로더가 존재한다. 각 부트로더의 상세한 작동 방식이나 특징은 시스템 환경(BIOS 또는 UEFI) 및 설정에 따라 차이가 있다.

3. 1. BIOS 시스템

바이오스(BIOS) 기반 시스템의 부트 과정은 마스터 부트 레코드(MBR) 코드가 리얼 모드에서 실행되고, 첫 번째 단계 부트 로더가 로드되면서 시작된다.

제1단계 부트로더는 마스터 부트 레코드(MBR)의 일부로, 512바이트 크기이며 프로그램 코드와 파티션 테이블을 포함한다. 이 1단계 부트로더는 파티션 테이블에서 활성 파티션을 찾아, 해당 파티션의 부트 레코드를 메모리로 읽어 들여 제2단계 부트로더를 실행시킨다.

제2단계 부트로더는 리눅스 커널 이미지와 필요한 경우 초기 RAM 디스크(initrd 또는 initramfs)를 메모리에 로드하는 역할을 한다. 이때 로드되는 커널 이미지는 실행 가능한 커널 자체가 아니라, zlib 등을 이용해 zImage 또는 bzImage 형식으로 압축된 파일이다.

x86 PC 환경에서 널리 사용되는 부트로더는 다음과 같다.

GRUB (GRand Unified Bootloader): 현재 가장 널리 사용되는 부트로더이다.
GRUB 2: 다양한 운영 체제를 자동으로 감지하고 설정을 자동화할 수 있다는 점에서 GRUB 1과 차별화된다. GRUB 2는 여러 단계로 구성된다. 제1단계(stage1)는 BIOS에 의해 마스터 부트 레코드(MBR)에서 로드되어 실행된다. 이후 중간 단계 로더(stage1.5, 보통 `core.img` 파일)가 로드되어 파일 시스템을 인식하고 제2단계 로더(stage2, `/boot/grub/` 디렉토리 내 파일들)를 로드한다. 제2단계 로더는 사용자에게 부팅 메뉴를 보여주고, 사용자가 운영 체제를 선택하거나 부팅 매개변수를 수정할 수 있게 한다. 선택이 완료되면 GRUB는 리눅스 커널을 메모리에 로드하고 시스템 제어권을 넘긴다. GRUB는 다른 부트로더를 불러오는 체인 로딩 기능도 지원한다.
GRUB 1: 런타임 시 파일 시스템을 읽어 설정 파일에 접근할 수 있었으며^[13], 이를 통해 설정을 유연하게 변경하고 사람이 읽을 수 있는 형식으로 디스크와 파티션을 지정할 수 있었다. 또한 명령줄 인터페이스(CLI)를 제공하여 설정 오류 시 복구를 용이하게 했다.^[14]

LILO (LInux LOader): 과거에 많이 사용되었던 부트로더이다. LILO는 파일 시스템 구조를 직접 이해하지 못한다. 대신 시스템 설정 시 생성된 설정 파일(`/etc/lilo.conf`)에 기록된 커널과 램 디스크의 물리적인 위치 정보(raw offset)를 사용하여 부팅한다. 이 정보는 부트로더 코드와 함께 MBR 부트 섹터에 기록된다. BIOS에 의해 부트 섹터가 읽히고 제어권이 넘어오면, LILO는 메뉴 코드를 로드하고 사용자 입력과 저장된 값을 이용하여 리눅스 커널을 계산하여 로드한다.

SYSLINUX/ISOLINUX: FAT 파일 시스템에서 리눅스를 부팅하는 데 특화된 부트로더이다. 주로 부팅용 플로피 디스크, live USB, 기타 경량 부팅 시스템에 사용된다. ISOLINUX는 리눅스 live CD나 설치용 CD에서 흔히 볼 수 있다.

Loadlin: 실행 중인 도스(DOS)나 윈도우 9x 환경에서 리눅스 커널을 로드하여 시스템을 리눅스로 전환할 수 있게 해주던 부트로더이다. 하드웨어 초기화를 위해 DOS/Windows 드라이버가 필요했던 과거에 유용했으나, 현재 리눅스 커널 자체에서 다양한 하드웨어를 지원하게 되면서 사용 빈도는 크게 줄었다.

3. 2. UEFI 시스템

UEFI 시스템에서는 BIOS 기반 시스템과 부팅 과정이 다르다. UEFI 펌웨어는 리눅스 커널과 같은 운영 체제 페이로드를 직접 실행할 수 있는 기능을 갖추고 있어, 이론적으로는 별도의 부트로더가 필요하지 않을 수도 있다. 하지만 실제로는 GRUB 2, systemd-boot, rEFInd와 같은 부트로더를 사용하는 경우가 일반적이다.

UEFI 환경에서 GRUB 2는 BIOS 환경과 다르게 작동한다. BIOS 시스템에서는 마스터 부트 레코드(MBR)에 저장된 1단계 부트로더가 1.5단계(필요한 경우)와 2단계 부트로더를 순차적으로 로드하는 방식이지만, UEFI 시스템에서는 1단계와 1.5단계 부트로더가 일반적으로 하나의 UEFI 애플리케이션 파일로 통합된다. 예를 들어, x64 UEFI 시스템에서는 `grubx64.efi` 파일이 이 역할을 수행한다. 이 UEFI 애플리케이션이 실행되면, 2단계 부트로더(/boot/grub/ 파일들)를 로드하여 GRUB 메뉴를 표시하고 사용자가 선택한 커널을 메모리에 로드하여 부팅을 진행한다.

GRUB 외에도 UEFI 시스템에서 사용되는 다른 부트로더들이 있다.

systemd-boot: (이전 이름 Gummiboot) systemd에 포함된 부트로더로, 최소한의 설정만 필요하며 UEFI 시스템 전용으로 설계되었다.
rEFInd: UEFI 시스템을 위한 부트 매니저로, 설치된 운영체제들을 자동으로 감지하여 부팅 메뉴를 제공하는 데 중점을 둔다.

3. 3. 기타 부트로더

systemd-boot: systemd에 포함된 부트로더로, 최소한의 설정만 필요하고 UEFI 시스템 전용이다. 이전 이름은 Gummiboot였다.
SYSLINUX/ISOLINUX: FAT 파일 시스템에서 리눅스 설치본 전체를 부팅하는 데 특화된 부트로더이다. 주로 부팅 또는 복구용 플로피 디스크, 라이브 USB, 그 외 가벼운 부팅 시스템에 사용된다. ISOLINUX는 일반적으로 리눅스 라이브 CD나 부팅 가능한 설치 CD에서 사용된다.
rEFInd: UEFI 시스템을 위한 부트 매니저이다.
coreboot: UEFI나 BIOS를 대체하는 자유 오픈 소스 펌웨어이다. 보통 시스템 보드와 함께 배포되며, 필요하다면 제조사에서 현장 업데이트를 제공하기도 한다. coreboot 일부는 시스템 BIOS처럼 작동하여 부팅 후 메모리에 상주한다.
Das U-Boot: 임베디드 시스템을 위한 부트로더이다. BIOS나 UEFI가 없고, 부트로더를 메모리로 읽어 실행하는 독자적인 부팅 방식을 사용하는 시스템에서 주로 쓰인다.
Loadlin: 실행 중인 DOS나 Windows 9x 커널을 리눅스 커널로 교체할 수 있는 부트로더이다. 소프트웨어로 활성화해야 하는 특정 하드웨어를 사용하기 위해 DOS 전용 설정 프로그램이 필요할 때 유용했다. 현재는 리눅스가 다양한 하드웨어 드라이버를 지원하므로 덜 필요하지만, 일부 모바일 장치 등에서 사용된 적이 있다. 또한 BIOS가 부팅할 수 없는 저장 장치에 리눅스가 설치된 경우, DOS나 Windows에서 해당 장치 드라이버를 로드한 후 Loadlin으로 리눅스를 부팅하는 데 사용되기도 했다.

4. 커널 단계

커널은 운영 체제의 핵심적인 부분으로, 부트로더가 작업을 완료한 후 제어를 넘겨받아 시스템 운영에 필요한 핵심 기능들을 담당한다. 여기에는 메모리 관리, 작업 스케줄링, 입출력(I/O) 처리, 프로세스 간 통신(IPC) 및 전반적인 시스템 제어 등이 포함된다.^[9]

커널 로딩 및 초기화는 일반적으로 두 단계로 진행된다. 첫 번째 단계에서는 부트로더에 의해 압축된 커널 이미지가 메모리에 로드되고 압축이 해제되며, 기본적인 하드웨어 설정과 메모리 관리 기능 일부가 초기화된다. 이 과정이 완료되면, 커널은 시스템 운영에 필요한 나머지 기능들을 설정하는 본격적인 초기화 단계로 진입한다. 이 단계에서는 인터럽트 처리 기능 활성화, 추가적인 메모리 관리 설정, 연결된 장치 및 드라이버 초기화 등이 이루어진다. 또한, 부팅 초기에 필요한 파일들을 담고 있는 초기 RAM 디스크(initrd)나 initramfs 같은 임시 파일 시스템을 마운트하여 활용하기도 한다.

모든 초기화 과정이 끝나면, 커널은 시스템에서 실행될 첫 번째 사용자 공간 프로세스인 Init 프로세스(일반적으로 `/sbin/init`)를 실행시킨다. Init 프로세스는 사용자 환경을 설정하고 필요한 서비스들을 시작하는 역할을 담당한다. Init 프로세스가 시작된 후, 커널 자체는 주로 시스템 호출이나 하드웨어 인터럽트 같은 이벤트 발생을 기다리는 상태로 전환되며, 필요할 때마다 해당 요청을 처리한다. 커널은 시스템이 종료될 때까지 이러한 핵심적인 역할을 계속 수행한다.

4. 1. 커널 로딩

부트로더 단계 이후 커널 로딩 단계가 시작된다. 커널은 메모리 관리, 태스크 스케줄링, 입출력, 프로세스 간 통신 그리고 전체적인 시스템 제어 같은 모든 운영 체제 프로세스들을 다룬다.

커널 로딩은 일반적으로 두 단계로 이루어진다. 첫 단계에서는 부트로더에 의해 압축된 커널 이미지 파일(주로 zImage 또는 bzImage 형식)이 메모리에 로드된다.^[15] 이후 커널 이미지는 일반적으로 커널 자체의 루틴에 의해 압축 해제되며, 이 과정에서 기본적인 메모리 관리 및 최소한의 하드웨어 설정과 같은 몇 가지 기본적인 기능이 설정된다. 다만, ARM 64비트와 같은 일부 플랫폼에서는 U-Boot와 같은 부트로더가 커널 압축 해제를 대신 수행해야 할 수도 있다.

i386 마이크로프로세서를 예로 들면, bzImage가 로드되면 먼저 ./arch/i386/boot/head.S의 start() 함수가 호출되어 기본적인 하드웨어 설정을 수행한다. 그 다음, ./arch/i386/boot/compressed/head.S에 위치한 startup_32() 함수가 호출된다. 이 함수는 스택 설정 등 기본적인 환경 설정을 수행하고, BSS 영역을 초기화한다. 마지막으로 ./arch/i386/boot/compressed/misc.c에 위치한 decompress_kernel() 함수를 호출하여 커널 이미지의 압축을 해제한다. 이 단계가 완료되면 제어는 주요 커널 시작 프로세스로 넘어간다.

4. 2. 커널 초기화

커널은 운영체제의 핵심으로, 메모리 관리, 태스크 스케줄링, 입출력, 프로세스 간 통신 등 시스템 전반을 제어한다. 커널 로딩은 두 단계로 진행된다. 첫 단계에서는 압축된 커널 이미지 파일(예: bzImage)이 메모리에 로드되어 압축이 해제되고, 기본적인 메모리 관리와 최소한의 하드웨어 설정 등 몇 가지 기본적인 기능이 설정된다. 커널 이미지는 일반적으로 자체 압축 해제 루틴을 포함하지만, ARM 64비트와 같은 일부 플랫폼에서는 U-Boot 같은 부트로더가 대신 압축 해제를 수행하기도 한다.

커널의 시작 함수는 아키텍처에 따라 다르다. 예를 들어 i386 아키텍처에서는 `bzImage`가 로드되면, start() 함수(./arch/i386/boot/head.S)가 호출되어 기본적인 하드웨어 설정을 수행한 다음 startup_32() 함수(./arch/i386/boot/compressed/head.S)를 호출한다. 이 함수는 환경(스택 등)을 설정하고 BSS 영역을 초기화한 후, decompress_kernel() 함수(./arch/i386/boot/compressed/misc.c)를 호출하여 커널의 압축을 해제한다. 압축 해제 후에는 다른 startup_32() 함수(./arch/i386/kernel/head.S)를 통해 커널의 본격적인 시작 단계가 실행된다. 이 단계에서는 메모리 관리(페이징 테이블 및 메모리 페이징 설정)와 CPU 종류 및 부동소수점 지원 여부와 같은 추가 기능 탐지가 이루어진다. 이후 아키텍처에 독립적인 커널 초기화 함수인 start_kernel() 함수(./init/main.c)가 호출된다.

start_kernel() 함수는 광범위한 초기화 작업을 수행한다. 인터럽트 핸들링(IRQ)을 설정하고, 메모리를 추가로 구성하며, 첫 번째 사용자 공간 프로세스인 Init 프로세스를 시작한다. 또한, 부트로더 단계에서 미리 로드된 임시 루트 파일 시스템인 초기 RAM 디스크(initrd) 또는 initramfs를 마운트한다.

initrd나 initramfs는 실제 루트 파일 시스템이 마운트되기 전에 필요한 장치 드라이버들을 메모리에서 직접 로드할 수 있게 해준다. 예를 들어, 하드 디스크 드라이버와 같이 시스템 부팅에 필수적인 드라이버 모듈들이 여기에 포함될 수 있다. 이를 통해 커널 자체의 크기를 줄이면서도 다양한 하드웨어 구성을 지원할 수 있다. 특히 initramfs는 커널 버전 2.5.46부터 사용 가능하며^[8], '초기 사용자 공간'이라고도 불린다. 이는 커널이 부팅 과정에서 수행하던 기능 중 가능한 많은 부분을 사용자 공간으로 옮기려는 목적으로 도입되었다. 많은 리눅스 배포판에서는 dracut과 같은 도구를 사용하여 initramfs 이미지를 생성하고 관리한다.

필요한 드라이버들이 로드되고 실제 루트 파일 시스템에 접근할 준비가 되면, 커널은 pivot_root() 시스템 호출을 사용하여 루트 파일 시스템을 임시 루트 파일 시스템(initrd 또는 initramfs)에서 실제 루트 파일 시스템으로 전환한다. 이후 임시 루트 파일 시스템이 사용하던 메모리는 회수된다.

마지막으로 커널은 장치들을 초기화하고, 부트로더에 의해 지정된 루트 파일 시스템을 읽기 전용으로 마운트한다. 그리고 시스템에서 실행되는 첫 번째 사용자 공간 프로세스인 Init(/sbin/init)를 실행한다. 이 프로세스는 PID 1번을 가지며, 이후 사용자 환경 설정 등 나머지 부팅 과정을 담당한다.^[16]^[9] 파일 시스템 마운트 과정이나 Init 프로세스 시작 시 관련 메시지가 출력될 수 있다.^[9] 커널은 Init 프로세스를 시작시킨 후, 특별한 작업이 없으면 시스템 자원을 최소한으로 사용하며 대기하는 유휴 태스크(cpu_idle()) 상태로 전환된다.

레드햇(Red Hat)은 커널 초기화 단계를 다음과 같이 요약한다:^[13]^[6]

: "커널이 로드되면 즉시 컴퓨터의 메모리를 초기화하고 구성하며, 모든 프로세서, I/O 서브시스템 및 저장 장치를 포함하여 시스템에 연결된 다양한 하드웨어를 구성한다. 그런 다음 메모리의 미리 결정된 위치에서 압축된 initrd 이미지를 찾고, 압축을 풀고, 마운트하고, 필요한 모든 드라이버를 로드한다. 다음으로, initrd 디스크 이미지를 마운트 해제하고 디스크 이미지가 한 번 차지했던 모든 메모리를 해제하기 전에 LVM 또는 소프트웨어 RAID와 같은 파일 시스템과 관련된 가상 장치를 초기화한다. 커널은 그런 다음 루트 장치를 생성하고, 루트 파티션을 읽기 전용으로 마운트하고, 사용하지 않는 모든 메모리를 해제한다. 이 시점에서 커널은 메모리에 로드되어 작동한다. 그러나 시스템에 의미 있는 입력을 허용하는 사용자 응용 프로그램이 없으므로, 이를 가지고 할 수 있는 일이 많지 않다." (initramfs 방식의 부팅은 설명된 initrd 부팅과 유사하지만 세부적으로는 차이가 있다.)

이 시점에서 인터럽트가 활성화되고, 스케줄러는 선점형 멀티태스킹을 제공하기 위해 시스템의 전반적인 관리를 제어하게 된다. Init 프로세스는 사용자 공간에서 사용자 환경을 구성하는 나머지 부팅 과정을 계속 진행한다.

5. 초기 사용자 공간 (initramfs)

initramfs는 '초기 사용자 공간'이라고도 불리며, 리눅스 커널 버전 2.5.46부터 사용되었다.^[17] 이는 시작 과정에서 커널이 수행되기 전에 가능한 많은 기능을 대체하기 위한 목적으로 도입되었다. 초기 사용자 공간의 일반적인 역할은 주요 사용자 공간 파일 시스템을 불러오기 위해 필요한 장치 드라이버가 무엇인지 알아내어, 이를 임시 파일 시스템에 불러오는 것이다.

6. Init 프로세스

커널이 시작되면, init 프로세스를 시작한다.^[18] 이는 데몬으로, 사용자 공간을 부트스트랩하는 역할을 담당한다. 예를 들어 파일 시스템을 확인하고 마운트하며, 다른 필요한 프로세스들을 시작하는 등의 작업을 수행한다. init 시스템은 시스템 부팅 시 시작되는 첫 번째 데몬이며, 시스템 종료 시 종료되는 마지막 데몬이다.

역사적으로 리눅스 시스템에서는 "SysV init"(단순히 "init"라고도 불림)가 주로 사용되었다. 이는 SysV 스타일을 따르는 방식이다. 그러나 최근의 리눅스 배포판들은 systemd, Upstart, runit과 같은 더 현대적인 init 시스템 중 하나를 사용할 가능성이 높다. 이러한 다양한 init 시스템들은 각각의 특징과 방식으로 시스템의 시작과 종료 과정을 관리한다. 상세한 내용은 각 시스템별 하위 섹션에서 다룬다.

시스템 종료 시에는 모든 init 시스템이 공통적으로 사용자 공간의 기능들을 순차적으로 종료시키는 역할을 수행한다. 모든 사용자 공간 프로세스가 종료된 후 init 프로세스 자신도 종료되며, 이후 커널이 시스템 종료 절차를 마무리한다.

6. 1. SysV init

init 프로세스는 커널 부팅 직후 가장 먼저 실행되어^[18] 사용자 공간 전체를 설정하고 가동하는 핵심 데몬이다. 이는 파일 시스템 확인 및 마운트, 필요한 서비스 시작, 최종적으로 사용자 환경 전환까지의 과정을 포함한다.^[18] 유닉스나 BSD의 init 과정과 유사점을 가지면서도 리눅스만의 특징이 있다.

역사적으로 리눅스에서 널리 사용된 init 시스템은 SysV init (또는 단순히 "init")이다. 이는 SysV 스타일을 따르며, 최근에는 systemd와 같은 현대적인 시스템으로 대체되는 추세이다. SysV init는 런레벨 개념을 통해 시스템 상태를 관리한다. 0부터 6까지의 숫자로 구분되는 각 런레벨은 특정 시스템 상태(예: 단일 사용자 모드, 다중 사용자 네트워크 모드, 종료, 재부팅 등)에 해당하며, 해당 런레벨에서 어떤 서비스를 실행하고 중지할지를 결정한다.^[18]^[10]

주요 설정 파일과 스크립트 위치는 다음과 같다.

/etc/inittab: SysV init의 기본 설정 파일로, 시스템 부팅 시 사용할 기본 런레벨 등이 정의되어 있다.^[10]^[18]
/etc/rc?.d/ (예: /etc/rc3.d/): 각 런레벨('?' 자리에 런레벨 숫자)에서 실행될 스크립트들이 위치한다. 이 스크립트들은 특정 서비스를 시작(S로 시작)하거나 중지(K로 시작)하는 링크 형태이다.^[18]

시스템 부팅 과정에서 SysV init는 다음 단계를 따른다.

1. /etc/inittab 파일을 읽어 기본 런레벨을 확인한다. 만약 지정되어 있지 않다면, 시스템 콘솔을 통해 사용자에게 런레벨 입력을 요청한다.^[16]

2. 결정된 런레벨에 맞는 부팅 스크립트들을 실행한다. 이 과정에는 다음 작업들이 포함된다.^[9]^[16]

필요한 커널 모듈 로딩
읽기 전용으로 마운트된 루트 파일 시스템의 무결성 검사
루트 파일 시스템을 읽기-쓰기 권한으로 다시 마운트
네트워크 인터페이스 활성화 및 설정

모든 부팅 관련 프로세스가 완료되면, init 프로세스는 대기 상태로 전환되어 다음 세 가지 주요 이벤트 중 하나가 발생하기를 기다린다.^[11]^[19]

init이 실행한 자식 프로세스의 종료
전원 관련 문제 신호 수신
/sbin/telinit 명령어를 통한 사용자의 런레벨 변경 요청

6. 2. systemd

systemd는 SysV init을 대체하기 위해 개발된 현대적인 init 시스템이다.^[12] 기존의 유닉스 계열 운영체제에서 사용되던 init 시스템의 한계를 극복하는 데 초점을 맞추었다. `init`과 마찬가지로 `systemd`는 다른 데몬들을 관리하는 역할을 수행하며, 이 데몬들은 모두 백그라운드 프로세스로 동작한다. `systemd`는 시스템이 부팅될 때 가장 먼저 실행되는 데몬이며, 시스템이 종료될 때 가장 마지막으로 종료되는 데몬이다.

`systemd`를 처음 개발한 소프트웨어 엔지니어인 레나르트 포터링(Lennart Poettering)과 케이 시버스(Kay Sievers)^[12]는 여러 측면에서 기존 `init` 데몬의 효율성을 넘어서고자 했다.^[20] 이들은 시스템 부팅 과정에서 더 많은 프로세스들이 동시에, 즉 병렬적으로 처리될 수 있도록 소프트웨어 프레임워크를 개선하고, 셸 스크립트 실행에 따른 계산 오버헤드를 줄이는 것을 목표로 삼았다.

`systemd`의 주요 특징 중 하나는 각 데몬의 초기화 명령어를 셸 스크립트 대신 선언적인 설정 파일에 기록한다는 점이다. 이는 관리의 편의성을 높이고 오류 발생 가능성을 줄인다. 또한, 프로세스 간 통신(IPC)을 위해 실행 중인 데몬들에게 유닉스 도메인 소켓과 D-Bus를 사용할 수 있도록 지원한다. 이러한 구조를 통해 `systemd`는 시스템 자원을 효율적으로 활용하며 적극적인 병렬 처리를 가능하게 한다.

6. 3. Upstart

전통적인 init 과정은 기본적으로 컴퓨터 전원이 켜진 후 정상 실행 상태로 만들고, 종료 전에 서비스들을 순서대로 멈추는 것에 중점을 둔다. 이 방식은 동기적으로 작동하여, 현재 작업이 끝나기 전까지 다음 작업을 시작하지 못한다. 또한 모든 작업은 미리 정의되어야 하므로, 현대 데스크톱 컴퓨터에서 발생하는 다양한 비정규적인 작업들을 처리하기 어렵다.

Upstart는 이러한 한계를 극복하기 위해 비동기적으로 작동한다. 시스템 부팅 시 작업과 서비스 시작, 종료 시 정지뿐만 아니라 시스템이 실행되는 동안에도 관련 작업들을 감시하고 관리한다.

Upstart의 중요한 설계 목표 중 하나는 기존 Sysvinit과의 쉬운 전환과 완전한 하위 호환성을 보장하는 것이다.^[21] 이 덕분에 Upstart 환경에서도 수정되지 않은 기존 sysvinit 스크립트를 그대로 실행할 수 있다. 이는 일반적으로 완전한 시스템 전환을 요구하고 과거와 현재의 시작 방식이 혼재된 환경을 지원하지 않는 다른 init 대체 시스템들과 구별되는 특징이다.^[22]

Upstart는 `initctl` 유틸리티와 이벤트 브릿지(복잡한 이벤트들을 통합하는 기능)를 통해 독자적인 이벤트 모델을 사용한다.^[23] 기본적으로 Upstart는 소켓, dbus, udev, 파일 시스템, dconf 설정 변경 등 다양한 시스템 이벤트를 감지하고 처리하기 위한 브릿지들을 포함하고 있다.^[24]

6. 4. runit

Runit은 유닉스 계열 운영 체제들을 위한 init 구조로서 운영 체제를 통해 초기화, 감독 그리고 프로세스들의 종료를 담당한다. 이것은 리눅스, 맥, BSD 등에서 돌아가는 데몬툴즈 프로세스 감독 툴킷^[25]의 재구현이다. Runit은 운영 체제의 부트 시간을 줄여줄 수 있는 시스템 서비스 시작의 병렬화를 특징으로 갖는다.^[26]

Runit은 init 데몬으로서 모든 다른 프로세스들의 직접적인 또는 간접적인 조상이다. 이것은 부팅 시에 시작되는 첫 번째 프로세스이며 시스템이 종료되기 전까지 실행된다.

참조

_[1] 서적 2020 International Symposium on Computer Engineering and Intelligent Communications (ISCEIC) 2020-08
_[2] 웹사이트 EFI stub kernel - Gentoo Wiki https://wiki.gentoo.[...] 2020-11-02
_[3] 웹사이트 Solving BIOS Boot Issues with EFI http://systems.cs.co[...] 2010-09-14
_[4] 뉴스 MS denies secure boot will exclude Linux https://www.theregis[...] The Register 2011-09-24
_[5] 웹사이트 Using a Signed Bootloader - Arch Wiki https://wiki.archlin[...] 2024-12-05
_[6] 웹사이트 Product Documentation http://www.redhat.co[...] Redhat.com 2014-01-22
_[7] 웹사이트 Product Documentation http://www.redhat.co[...] Redhat.com 2014-01-22
_[8] 웹사이트 Initramfs arrives https://lwn.net/Arti[...] 2011-11-14
_[9] 문서 Linux Boot Process - by Kim Oldfield http://oldfield.watt[...] 2001
_[10] 웹사이트 From Power Up To Bash Prompt: Init http://users.cecs.an[...]
_[11] 웹사이트 init http://man.he.net/ma[...]
_[12] 웹사이트 systemd README http://cgit.freedesk[...] 2012-09-09
_[13] 웹인용 Product Documentation http://www.redhat.co[...] Redhat.com 2014-01-22
_[14] 웹인용 Product Documentation http://www.redhat.co[...] Redhat.com 2014-01-22
_[15] 웹인용 보관된 사본 http://www-128.ibm.c[...] 2007-04-03
_[16] 문서 Linux Boot Process - by Kim Oldfield http://oldfield.watt[...] 2001
_[17] 웹인용 Initramfs arrives http://lwn.net/Artic[...] 2011-11-14
_[18] 웹인용 From Power Up To Bash Prompt: Init http://axiom.anu.edu[...] 2016-02-18
_[19] 문서 init http://man.he.net/ma[...]
_[20] 웹인용 systemd README http://cgit.freedesk[...] 2012-09-09
_[21] 간행물 Launch Pad https://bugs.launchp[...] Ubuntu
_[22] 간행물 Ubuntu Wiki https://wiki.ubuntu.[...] Canonical
_[23] 웹인용 The Upstart Cookbook http://upstart.ubunt[...] Canonical 2014-01-26
_[24] 웹인용 The Upstart Cookbook http://upstart.ubunt[...] Canonical 2014-01-26
_[25] 웹인용 Init Scripts Considered Harmful http://www.sanityinc[...] 2013-12-12
_[26] 웹인용 runit - benefits http://smarden.org/r[...] 2013-04-23

본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com