임베디드 스터디 - 초기 RAM 디스크

초기 RAM Disk

• start_kernel() 이후 systemd가 실행되려면 루트 파일시스템이 마운트되어 있어야 한다.
• 루트 파일시스템이 NAND Flash에 있다면 MTD/UBI 드라이버가 필요한데, 드라이버는 파일시스템 안에 있다.
  • 파일시스템을 마운트하려면 드라이버가 필요하고, 드라이버는 파일시스템 안에 있는 닭-달걀 문제가 발생
  • 해결책 : 임시 루트 파일시스템을 RAM에 먼저 마운트해서 드라이버를 로드한 뒤 실제 루트를 마운트

initrd vs initramfs

• initrd(initial RAM disk) : RAM에 가상 블록 디바이스(/dev/ram0)를 만들고 파일시스템 이미지를 마운트
• initramfs(initial RAM filesystem) : cpio 아카이브를 RAM에 직접 풀어서 tmpfs로 마운트

initrd
  커널 → /dev/ram0 (가상 블록 디바이스) → 파일시스템 마운트
  → /linuxrc 실행 → 실제 루트로 전환 → /dev/ram0 해제

initramfs
  커널 → cpio 압축 해제 → tmpfs에 직접 풀기
  → /init 실행 → 실제 루트로 전환 → RAM 반환

• initrd의 문제점으로 인해 현대 Linux는 initramfs가 표준
  • 블록 디바이스 오버헤드 : RAM → 블록 디바이스 → 파일시스템 계층이 복잡하고 블록 디바이스 드라이버를 커널에 내장해야 함
  • 크기 고정 문제 : 이미지 크기가 미리 고정되어 RAM 낭비 또는 공간 부족 발생
• cpio : 파일들을 하나로 묶는 아카이브 포맷. 커널이 cpio 압축 해제를 내장 지원함

initramfs 구성 요소

• initramfs 안에는 실제 루트 파일시스템을 마운트하기 위한 최소한의 구성이 들어간다.

initramfs 내부
  /init          ← 부팅 스크립트
  /bin/busybox   ← 모든 유틸리티
  /bin/sh → busybox
  /bin/mount → busybox
  /lib/           ← 최소한의 라이브러리
  /dev/console    ← 기본 디바이스 노드

• /init 스크립트 실행 흐름

initramfs /init
  - 드라이버 로드 (MTD/UBI 등)
  - 실제 루트 파일시스템 마운트
    ↓ switch_root
실제 루트 파일시스템
    ↓
/sbin/init (= systemd, PID 1)

BusyBox

• sh, ls, mount 등 수백 개의 Unix 유틸리티를 하나의 바이너리로 묶은 도구
• 모든 심볼릭 링크가 /bin/busybox 단일 바이너리를 가리키며, busybox는 호출된 이름(argv[0])을 보고 해당 기능을 수행

구분	일반 Linux 유틸리티	BusyBox
용량	수십~수백 MB	약 1~2 MB
바이너리 수	수백 개	1개 + 심볼릭 링크
기능	풀 기능	핵심 기능만 (경량화)

일반 방식
  /bin/sh      (바이너리, 1MB)
  /bin/ls      (바이너리, 200KB)
  /bin/mount   (바이너리, 300KB)
  ...          (수백 개)

BusyBox 방식
  /bin/busybox (바이너리, 1~2MB)
  /bin/sh      (심볼릭 링크, 수 바이트)
  /bin/ls      (심볼릭 링크, 수 바이트)
  /bin/mount   (심볼릭 링크, 수 바이트)

• BusyBox가 작은 이유
  • 핵심 옵션만 구현하여 기능을 경량화
  • 모든 유틸리티가 공통 코드를 공유하여 중복 제거