원문 보기: https://dawoum.duckdns.org/wiki/Initial_ramdisk
리눅스 시스템에서, initrd (초기 램디스크)는 리눅스 시작 프로세스의 일부로 사용될 임시적인 루트 파일 시스템을 메모리에 로드하는 방식입니다. initrd와 initramfs (INITial RAM File System에서 유래)는 이를 달성하는 두 가지 다른 방법을 참조합니다. 둘 다 실제 루트 파일 시스템을 마운트하기 전에 준비하는 데 공통적으로 사용됩니다.
Rationale
많은 리눅스 배포판은 단일의 일반적인 리눅스 커널 이미지를 제공합니다 – 리눅스 커널은 배포판 개발자가 다양한 하드웨어에서 부팅하도록 특별히 만든 것입니다. 이 일반 커널 이미지에 대한 장치 드라이버는 적재-가능한 커널 모듈로 포함되는데, 왜냐하면 많은 드라이버를 하나의 커널로 정적으로 컴파일하면 커널 이미지가 훨씬 커져서 메모리가 제한된 컴퓨터에서 부팅하기에는 너무 크거나, 존재하지 않거나 충돌하는 하드웨어를 검색하여 부팅 시 충돌이나 다른 문제가 발생할 수 있기 때문입니다. 이 정적으로-컴파일된 커널 방식은 더 이상 사용되지 않거나 필요하지 않은 모듈을 커널 메모리에 남겨두고 부팅 시 루트 파일 시스템을 마운트하는 데 필요한 모듈을 감지하고 로드하거나 루트 파일 시스템이 어디에 있는지 또는 무엇인지 추론하는 문제를 제기합니다.
문제를 더 복잡하게 만들기 위해, 루트 파일 시스템은 소프트웨어 RAID 볼륨, LVM, NFS (디스크 없는 워크스테이션), 또는 암호화된 파티션에 있을 수 있습니다. 이들 모든 것은 마운트하기 위한 특별한 준비가 필요합니다.
또 다른 복잡한 문제는 최대 절전 모드에 대한 커널 지원으로, 이는 메모리의 전체 내용 이미지를 스왑 파티션이나 일반 파일에 덤프하고, 그런-다음 전원을 꺼서 컴퓨터를 디스크에 일시 중지합니다. 다음 부팅 시 이 이미지는 메모리에 다시 로드되기 전에 액세스 가능하게 만들어야 합니다.
커널에 많은 특수 케이스에 대한 하드코딩 처리를 하지 않아도 되도록, 임시 루트 파일 시스템 (현재는 초기 사용자 공간이라고 함)을 갖는 초기 부팅 단계가 사용됩니다. 이 루트 파일-시스템은 실제 루트 파일 시스템을 마운트하는 데 필요한 하드웨어 감지, 모듈 로딩, 및 장치 검색을 수행하는 사용자 공간 헬퍼를 포함할 수 있습니다.
Implementation
이 초기 루트 파일 시스템의 이미지 (커널 이미지와 함께)는 리눅스 부트로더 또는 컴퓨터의 부트 펌웨어에 의해 접근할 수 있는 어딘가에 저장되어야 합니다. 이것은 루트 파일 시스템 자체, 광 디스크의 부트 이미지, 로컬 디스크의 작은 파티션 (보통 ext2 또는 FAT 파일 시스템을 사용하는 부트 파티션), 또는 TFTP 서버 (이더넷에서 부팅할 수 있는 시스템)일 수 있습니다.
부트로더는 커널과 초기 루트 파일 시스템 이미지를 메모리에 로드하고 그런-다음 커널을 시작하고 이미지의 메모리 주소를 전달합니다. 부트 순서의 끝에서, 커널은 처음 몇 블록의 데이터에서 이미지의 형식을 결정하려고 시도하며, 이는 initrd 또는 initramfs 체계로 이어질 수 있습니다.
initrd 체계에서, 이미지는 파일 시스템 이미지 (선택적으로 압축됨)일 수 있으며, 이는 특수 블록 장치 (/dev/ram)에서 사용 가능한 다음 초기 루트 파일 시스템으로 마운트됩니다. 해당 파일 시스템에 대한 드라이버는 커널에 정적으로 컴파일되어야 합니다. 많은 배포판은 원래 압축된 ext2 파일 시스템 이미지를 사용했지만, 다른 배포판 (Debian 3.1 포함)은 메모리-제한된 시스템에서 부팅하기 위해 cramfs를 사용하는데, 왜냐하면 cramfs 이미지는 압축 해제를 위한 추가 공간이 필요하지 않고도 그 자리에서 마운트할 수 있기 때문입니다. 일단 초기 루트 파일 시스템이 시작되면, 커널은 첫 번째 프로세스로 /linuxrc를 실행합니다; 그것이 종료될 때, 커널은 실제 루트 파일 시스템이 마운트되었다고 가정하고 /sbin/init를 실행하여 일반 사용자 공간 부팅 프로세스를 시작합니다.
initramfs 체계 (리눅스 커널 2.6.13부터 사용 가능)에서, 이미지는 cpio 아카이브 (선택적으로 압축) 또는 그러한 아카이브의 연결일 수 있습니다. 아카이브는 커널에 의해 tmpf의 특수 인스턴스로 압축 해제되어 초기 루트 파일 시스템이 됩니다. 이 체계는 중간 파일 시스템이나 블록 드라이버를 커널에 컴파일할 필요가 없다는 장점이 있습니다. 일부 시스템은 dracut 패키지를 사용하여 initramfs 이미지를 만듭니다. initramfs 체계에서, 커널은 종료되지 않을 것으로 예상되는 첫 번째 프로세스로 /init을 실행합니다. 일부 응용 프로그램에 대해, initramfs는 casper 유틸리티를 unionfs를 사용하여 읽기 전용 루트 파일 시스템 이미지 위에 지속성 계층을 오버레이하는 쓰기 가능 환경을 만들기 위해 사용될 수 있습니다. 예를 들어, 오버레이 데이터는 USB 플래시 드라이브에 저장될 수 있고, 반면에 라이브 CD에 저장된 압축된 SquashFS 읽기 전용 이미지는 루트 파일 시스템 역할을 합니다.
정적으로 컴파일된 알고리즘에 따라, 커널은 gzip, bzip2, LZMA, XZ, LZO, LZ4, 및 zstd로 압축된 initrd/initramfs 이미지를 압축 해제할 수 있습니다.
Mount preparations
Debian과 같은 일부 리눅스 배포판은 ATA, SCSI와 파일 시스템 커널 모듈과 같이 특정 컴퓨터를 부팅하는 데 필요한 것만 포함하는 사용자 지정 initrd 이미지를 생성합니다. 이것들은 전형적으로 루트 파일 시스템의 위치와 유형을 포함합니다.
다른 리눅스 배포판 (예를 들어, Fedora와 Ubuntu)은 보다 일반적인 initrd 이미지를 생성합니다. 이것들은 루트 파일 시스템의 장치 이름 (또는 그것의 UUID)으로만 시작하고 부팅 시 다른 모든 것을 발견해야 합니다. 이 경우에서, 소프트웨어는 루트 파일 시스템을 마운트하기 위해 복잡한 일련의 작업을 수행해야 합니다:
- 부팅 프로세스가 의존하는 임의의 하드웨어 드라이버는 로드되어야 합니다. 공통적인 배열은 공통적인 스토리지 장치의 커널 모듈을 initrd에 패킹하고 그런-다음 핫플러그 에이전트를 호출하여 컴퓨터에서 감지된 하드웨어와 일치하는 모듈을 가져오는 것입니다.
- 부팅 스플래시 화면을 표시하는 시스템에서, 비디오 하드웨어를 초기화하고 사용자-공간 도우미를 시작하여 부팅 프로세스에 맞춰 디스플레이에 애니메이션을 그려야 합니다.
- 루트 파일 시스템이 NFS에 있으면, 그것은 주요 네트워크 인터페이스를 불러오고, DHCP 클라이언트를 호출하여, DHCP 임대를 얻고, 임대에서 NFS 공유 이름과 NFS 서버의 주소를 추출하고, 그런-다음 NFS 공유를 마운트해야 합니다.
- 루트 파일 시스템이 소프트웨어 RAID 장치에 있는 것으로 나타나면, RAID 볼륨이 어떤 장치를 포괄하는지 알 수 있는 방법이 없습니다; 표준 MD 유틸리티를 호출하여 사용 가능한 모든 블록 장치를 스캔하고 필요한 블록 장치를 온라인으로 전환해야 합니다.
- 루트 파일 시스템이 논리 볼륨에 있는 것으로 나타나면, LVM 유틸리티를 호출하여 해당 루트 파일 시스템이 포함된 볼륨 그룹을 검색하고 활성화해야 합니다.
- 루트 파일 시스템이 암호화된 블록 장치에 있으면, 소프트웨어는 사용자에게 암호문을 입력하거나 하드웨어 토큰 (예를 들어, 스마트 카드나 USB 보안 동글)을 삽입하라는 메시지를 표시하는 도우미 스크립트를 호출하고, 그런-다음 장치 매퍼를 사용하여 암호 해독 대상을 생성해야 합니다.
일부 배포판은 udev와 같은 이벤트-구동 핫플러그 에이전트를 사용하며, 이는 특정 규칙과 일치하는 하드웨어 장치, 디스크 파티션, 및 스토리지 볼륨이 온라인이 되면 헬퍼 프로그램을 호출합니다. 이를 통해 검색을 병렬로 실행하고, 점진적으로 LVM, RAID, 또는 암호화의 임의의 중첩으로 캐스케이드하여 루트 파일 시스템에 도달할 수 있습니다.
루트 파일 시스템이 마침내 표시될 때, 마운트된 루트 파일 시스템에서 실행할 수 없는 임의의 유지 관리 작업이 완료되고, 루트 파일 시스템은 읽기 전용으로 마운트되고, 계속 실행해야 하는 임의의 프로세스 (예를 들어 스플래시 화면 도우미 및 명령 FIFO)는 새로 마운트된 루트 파일 시스템으로 끌어올려집니다.
최종 루트 파일 시스템은 단순히 / 위에 마운트될 수 없는데, 왜냐하면 최종 정리 작업을 위해 초기 루트 파일 시스템의 스크립트와 도구에 접근할 수 없게 되기 때문입니다;
- initrd에서, 새 루트는 임시 마운트 지점에 마운트되고 pivot_root(8) (이 목적을 위해 특별히 도입됨)로 제자리로 회전됩니다. 이렇게 하면 초기 루트 파일 시스템이 마운트 지점 (예를 들어, /initrd)에 남게 되며, 여기서 정규 부팅 스크립트가 나중에 마운트를 해제하여 initrd가 보유한 메모리를 해제할 수 있습니다.
- initramfs에서, 초기 루트 파일 시스템을 회전하여 제거할 수 없습니다. 대신, 그것은 단순히 비우고 최종 루트 파일 시스템을 맨 위에 마운트합니다.
대부분의 초기 루트 파일 시스템은 /linuxrc 또는 /init을 쉘 스크립트로 구현하고 따라서 최소한의 쉘 (보통 /bin/ash)과 일부 필수 사용자 공간 유틸리티 (보통 BusyBox 툴킷)를 포함합니다. 공간을 더욱 절약하기 위해, 쉘, 유틸리티, 및 지원 라이브러리는 전형적으로 공간 최적화가 활성화된 상태로 컴파일되고 (예를 들어, gcc의 "-Os" 플래그 사용) 이 목적을 위해 특별히 작성된 C 라이브러리의 최소 버전인 klibc에 링크됩니다.
Other uses
리눅스 배포판에 대한 설치 프로그램은 전형적으로 initramfs에서 완전히 실행되는데, 왜냐하면 그것들은 임의의 영구 저장소가 설정되기 전에 설치 프로그램 인터페이스와 지원 도구를 호스팅할 수 있어야 하기 때문입니다.
Tiny Core Linux 및 Puppy Linux는 initrd에서 전적으로 실행할 수 있습니다.
Similarities in other operating systems
Windows Vista부터, Windows는 파일 형식이 게시된 WIM 디스크 이미지 파일에서 부팅할 수 있습니다; 그것은 하드 링크, 중복 제거 청크를 지원하고, 청크별 압축을 사용한다는 점을 제외하면 ZIP 형식과 유사합니다. 이 경우에서, 전체 WIM이 처음에 RAM에 로드되고, 그런-다음 커널 초기화가 이어집니다. 다음으로, 로드된 WIM은 할당된 드라이브 문자를 갖는 SystemRoot로 사용할 수 있습니다. Windows 설치 프로그램은 이를 사용하여 BOOT.WIM에서 부팅하고, 그런-다음 INSTALL.WIM을 설치할 Windows 파일 모음으로 사용합니다.
역사, Windows 사전 설치 환경 (Windows PE)도 같은 것을 사용하며, 이는 일부 바이러스 백신과 백업/재해 복구 소프트웨어의 별도 부팅 버전의 기반이 됩니다.
물리적 드라이브에 위치해 있는 WIM 또는 VHD 파일에서 항상 부팅되도록 Windows를 설치하는 것도 가능합니다. 어쨌든, Windows 부트로더가 부팅 시간 커널 모듈에 대한 .sys 파일을 로드할 수 있기 때문에 이 방법은 거의 사용되지 않으며, 이는 리눅스에서 initrd를 요구하는 임무입니다.
See also
External links
- Debian initramfs-tools
- Detailed comparison of initrd-generating toolkits
- Kernel documentation on early userspace support
- "Motivation for switch from initrd to initramfs". Archived from the original on 4 January 2013. Alt URL