왜 initramfs가 필요합니까?

파일 시스템을 선택 jffs하거나 sd파일 시스템으로 선택 initramfs하면 커널 크기가 매우 작습니다 (1.4MB와 비교하여 1.4MB initramfs). 그것은 initramfs상당히 넓은 공간 을 차지 한다는 것을 의미합니다 . 따라서 가능하면 완전히 제거하여 아주 작은 커널을 갖게되므로 원하는 것입니다.

내 마음에 나타나는 기본 질문은 : 왜 내가 필요한가 initramfs? 초기 파일 시스템이 없어도 Linux 커널을 부팅 할 수 없습니까?

내 최종 응용 프로그램은 계산 및 통신 만 수행하며 저장 공간은 없습니다. 따라서 파일 시스템이없는 OS는 적어도 내 응용 프로그램에는 적합합니다.

initramfs를 갖는 크기 증가는 ramfs 드라이버 때문이 아닙니다 (몇 kB에 불과하고 다른 것들에 필요합니다). initramfs 자체 때문입니다. initramfs에는 실제 루트 파일 시스템을 어셈블하고 마운트하는 데 필요한 프로그램이 포함되어 있습니다.

Initramfs를 사용 /하면 시스템 부팅이 훨씬 쉽고 경우에 따라 (예 : 암호화 됨 ) 가능 합니다. 핫 플러그 ​​가능한 주변 장치가 많은 PC 스타일 하드웨어에 보관하는 것이 좋습니다. 반면에 내장 하드웨어를 내장 된 특정 하드웨어 구성 만 지원하는 커널을 사용하여 initramfs없이 부팅하는 것이 좋습니다.

물론 커널은 파일 시스템으로 부팅해야합니다. 실행하려는 응용 프로그램을로드 할 수있는 방법이 있어야합니다. 아무것도 실행하지 않을 경우 기계의 전원을 끄십시오.

initramfs를 사용하지 않으려면 부트 로더에게 전달하지 말라고 지시하십시오. 또한, 커널 빌드의 출력을 포함하지 않는 과정 - 모든 Architecture를하고 부트 로더 의존의 경우에 발생 방법 : 예를 들어, vmlinux그리고 bzImage(다시 initramfs를 포함 그들은 각각 원료 및 압축 커널 거 없어요? )이지만 uImage(U-Boot의 경우) 커널과 initramfs가 있으면 모두 압축합니다.

기술적으로 mikeserv가 언급 한 것처럼 항상 initramfs가 있지만 기본적으로 비어있는 134 바이트 아카이브입니다. 빌드 프로세스 및 루트 파일 시스템을 마운트하는 데 사용되는 도구가 포함되어 있습니다.)

initramfs는 영구적 인 데이터가없는 단일 응용 프로그램 시스템을 만드는 합리적인 방법 일 수 있습니다. 모든 응용 프로그램을 initramfs에 넣고 부팅하여 보관하십시오. 이를 통해 영구 저장소 또는 부팅 이미지를보다 쉽게 ​​구성 할 수 있습니다 (커널과 함께 제공되는 커널 및 initramfs 만 있으면됩니다). 그러나이 방법에는 단점이 있습니다. initramfs의 모든 데이터는 RAM에 영구적으로 저장되며 부팅 이미지에서 파일을 쉽게 수정할 수 없으므로 아카이브를 다시 작성해야합니다.

에서 LFS :

initramfs의 유일한 목적은 루트 파일 시스템을 마운트하는 것입니다. initramfs는 일반적인 루트 파일 시스템에서 찾을 수있는 완전한 디렉토리 세트입니다. 단일 cpio 아카이브에 번들로 제공되며 여러 압축 알고리즘 중 하나로 압축됩니다.

...

LFS 환경에 initramfs가 있어야하는 주된 이유는 네트워크에서 rootfs로드, LVM 논리 볼륨에서로드, 암호가 필요한 곳에 암호화 된 rootfs 보유 또는 rootfs를 라벨 또는 UUID. 다른 것은 보통 커널이 제대로 구성되지 않았 음을 의미합니다.

...

대부분의 배포판에서 커널 모듈은 initramfs를 갖는 가장 큰 이유입니다. 일반 배포판에는 파일 시스템 유형 및 디스크 레이아웃과 같은 많은 알 수없는 것이 있습니다. 어떤면에서 이것은 시스템 기능과 레이아웃이 알려져 있고 사용자 정의 커널이 일반적으로 빌드되는 LFS와 반대입니다. 이 상황에서 initramfs는 거의 필요하지 않습니다.

다른 출처 www.kernel.org

이 외에도 initramfs를 사용하지 않는 라우터와 같은 많은 Linux 시스템이 있습니다.

루트 부팅에 대한 액세스를 구성하려면 일부 사용자 모드 유틸리티가 필요하므로 네트워크 부팅 또는 lvm 또는 raid와 같은보다 복잡한 설정에는 initramfs가 필요합니다. 디스크의 단순하고 일반적인 파티션의 경우 디스크 드라이버가 커널에 내장되어 있고 UUID가 아닌 장치 경로로 루트 인수를 지정하면 initramfs없이 수행 할 수 있습니다. 물론 연결 한 플러그 앤 플레이 (예 : usb) 장치 또는 임의의 타이밍 차이에 따라 장치 경로가 변경 될 수 있으므로 거의 모든 사람이 uuid 및 initramfs를 사용하여 안정성을 유지합니다.

이것은 오래된 질문이지만 여전히 받아 들일만한 대답이없는 것 같습니다. 그래서 이것을 버릴 것입니다 (나는 여기 전문가가 아니며, 나는 이것을 스스로 알아 내려고 노력하고 있습니다.)

에서 https://www.kernel.org/doc/Documentation/early-userspace/README (이것은 2004 년 이후 업데이트되지 않은 말한다 하단에있는 모든 방법)

커널은 현재 루트 파일 시스템을 마운트하는 3 가지 방법이 있습니다 :

a) 커널에 컴파일 된 모든 필수 장치 및 파일 시스템 드라이버. initrd는 없습니다. init / main.c : init ()는 root_ 옵션 및 선택적인 init =에 따라 init / main.c : init의 끝에 나열된 것 이외의 다른 init 바이너리를 실행하기 위해 최종 루트 파일 시스템을 마운트하기 위해 Preparing_namespace ()를 호출합니다. ().

b) 모듈로 구축되고 initrd에 저장된 일부 장치 및 파일 시스템 드라이버. initrd에는이 드라이버 모듈을로드하는 바이너리 '/ linuxrc'가 포함되어야합니다. linuxrc를 통해 최종 루트 파일 시스템을 마운트하고 pivot_root syscall을 사용할 수도 있습니다. initrd는 Prepare_namespace ()를 통해 마운트되고 실행됩니다.

c) initramfs 사용. Preparing_namespace ()에 대한 호출을 건너 뛰어야합니다. 이것은 바이너리가 모든 작업을 수행해야 함을 의미합니다. 이 바이너리는 usr / gen_init_cpio.c를 수정하거나 새로운 initrd 형식 인 cpio 아카이브를 통해 initramfs에 저장할 수 있습니다. "/ init"라고해야합니다. 이 바이너리는 Preparing_namespace ()가하는 모든 일을 담당합니다.

이전 버전과의 호환성을 유지하기 위해 / init 바이너리는 initramfs cpio 아카이브를 통해 제공되는 경우에만 실행됩니다. 그렇지 않은 경우, init / main.c : init ()는 Preparing_namespace ()를 실행하여 최종 루트를 마운트하고 사전 정의 된 init 바이너리 중 하나를 실행합니다.

그 가치가 있기 때문에 Raspberry Pi와 같은 장치 / 배포판은 initramfs를 사용하지 않는다고 생각합니다. 어떤 경우에는 커널이 루트 파티션에 있어야합니다 (필요한 fs 모듈이있는 부트 로더에 의해 마운트됩니다). 다른 경우에 커널이 /boot파티션 에있는 경우, 다른 파티션과 같이 rootfs를 마운트하기 전에 동일한 파티션의 initramfs에 직접 액세스 할 수 있습니다. 진술했다.

어떤 경우에는 initramfs 를 커널과 같은 파일에 빌드 할 수 있지만 항상 그런 것은 아닙니다. (a) 어떤 경우에는 initramfs가 필요하지 않다는 것을 분명히 밝힌 것 같습니다.

다음 설명이 더 명확하다는 것을 알았습니다 .

initramfs커널에 내장되어 부트 프로세스의 초기 단계에서로드되는 루트 파일 시스템입니다. initrd의 후계자입니다. 부팅 과정에서 커널이 스스로 할 수없는 일을 할 수있는 초기 사용자 공간을 제공합니다.

initramfs 사용은 선택 사항입니다. 기본적으로 커널은 내장 드라이버를 사용하여 하드웨어를 초기화하고 지정된 루트 파티션을 마운트하며 설치된 Linux 배포판의 init 시스템을로드합니다. 그런 다음 init 시스템은 추가 모듈을로드하고 결국 사용자가 로그인 할 수있을 때까지 서비스를 시작합니다. 이는 좋은 기본 동작이며 많은 사용자에게 충분합니다. initramfs는 고급 요구 사항을 가진 사용자를위한 것입니다. 루트 파티션이 마운트되기 전에 가능한 빨리 작업을 수행해야하는 사용자를 위해.

다음은 initramfs로 수행 할 수있는 작업의 예입니다.

• 루트 파티션을 마운트하십시오 (암호화, 논리 및 특수 파티션의 경우).
• 최소한의 구조 쉘을 제공하십시오 (문제가 생길 경우).
• 부팅 프로세스를 사용자 정의합니다 (예 : 시작 메시지, 부팅 스플래시 등 인쇄).
• 로드 모듈 (예 : 타사 드라이버);
• 커널이 할 수없는 것 (예 : 명령을 실행하여 사용자 공간에서 할 수있는 한) 고급 요구 사항이 없으면 initramfs가 필요하지 않습니다.

당신이 무엇을 하든지, 당신은 가지고 있습니다 initramfs. 그것 없이는 할 일이 없습니다-그것은 당신에게 부과 된 유일한 파일 시스템입니다. 에서 kernel.org :

rootfs 란 무엇입니까?

Rootfs특별한의 인스턴스 ramfs(또는 tmpfs, 하다의가 활성화 된 경우), 항상 2.6 시스템에 존재하는가. 당신은 마운트 해제 할 수 없습니다rootfs 당신은 init 프로세스를 죽일 수 없어 거의 같은 이유; 빈 목록을 확인하고 처리하는 특수 코드가 아닌 커널이 특정 목록을 비워 둘 수 없도록 작고 간단합니다.

대부분의 시스템은 다른 파일 시스템을 마운트 rootfs하고 무시합니다. 비어있는 ramfs 인스턴스가 차지하는 공간은 아주 작습니다.

경우 * CONFIG_TMPFS *이 활성화되어 rootfs사용하는 tmpfs대신 ramfs기본적으로. 강제로 ramfs, 추가 "rootfstype=ramfs"커널 명령 행에.

initramfs 란 무엇입니까?

모든 2.6 Linux 커널 에는 gzip"cpio"으로압축 된형식의 아카이브 가 있으며 커널이 부팅 될 때 추출됩니다 rootfs. 추출 후 커널rootfs은 파일이있는지 확인합니다."init" , 하고 그것을 실행이 경우 PID 1. 만약 발견,이 init과정은 위치와 실제 루트 장치를 설치하고, 시스템에게 길의 나머지 부분을 가져 포함 할 책임이있다 ( 만약에 어떠한). 경우 rootfs포함되지 않은 init포함 된 후 프로그램을 cpio아카이브가 그것으로 추출, 커널은 찾아 루트 파티션을 마운트, 다음의 몇 가지 변형 간부 인하는 기존의 코드를 통해 떨어질 /sbin/init그 중입니다.

이 모든 것은 여러 가지면에서 이전 initrd와 다릅니다.

• 이전 initrd는 항상 별도의 파일 인 반면 initramfs 아카이브는 Linux 커널 이미지에 연결되어 있습니다. linux-* / usr 디렉토리는 빌드 중에이 아카이브를 생성하는 데 사용됩니다.

• 이전 initrd 파일은 gzipped 파일 시스템 이미지 (ext2와 같이 커널에 내장 된 드라이버가 필요한 일부 파일 형식) 였지만 새로운 initramfs 아카이브는 gzip으로 압축 된 cpio 아카이브입니다 (tar 만 더 간단 함, cpio (1) 참조). 및 Documentation / early-userspace / buffer-format.txt). 커널의 cpio 추출 코드는 매우 작을뿐만 아니라 부팅 과정에서 버릴 수있는 __init 텍스트 및 데이터이기도합니다.

• 이전 initrd (/ init가 아니라 / initrd라고 함)가 실행 한 프로그램은 일부 설정을 수행 한 후 커널로 돌아 왔지만 initramfs의 init 프로그램은 커널로 돌아올 것으로 예상되지 않습니다. (/ init 핸드 오프 제어가 필요한 경우 새 루트 장치로 오버 마운트 /하거나 다른 init 프로그램을 실행할 수 있습니다. 아래 switch_root 유틸리티를 참조하십시오.)

• 다른 루트 장치를 전환 할 때 initrd는 pivot_root를 실행 한 다음 램 디스크를 마운트 해제합니다. 그러나 initramfs는 rootfs입니다. pivot_root rootfs 나 마운트 해제 할 수 없습니다. 대신 rootfs에서 모든 것을 삭제하여 여유 공간을 확보하고 (find -xdev / -exec rm '{}' ';') rootfs를 새 루트 (cd / newmount; mount --move. /; chroot)로 오버 마운트하십시오. stdin / stdout / stderr을 새 / dev / console에 연결하고 새 init를 실행하십시오.

이 프로세스는 놀랍도록 이해하기 쉬운 프로세스이므로 (명령을 실행하기 전에 명령을 삭제해야 함) klibc 패키지에는 이러한 모든 작업을 수행하는 도우미 프로그램 (utils / run_init.c)이 도입되었습니다. busybox와 같은 대부분의 다른 패키지는이 명령의 이름을 "switch_root"로 지정했습니다.

초기화 initramfs :

2.6 커널 빌드 프로세스는 항상 gzipped cpio 형식 initramfs 아카이브를 작성하고 결과 커널 바이너리에 링크합니다. 기본적으로이 아카이브는 비어 있습니다 (x86에서 134 바이트 사용).

config_INITRAMFS_SOURCE 구성 옵션 (menuconfig의 일반 설정 및 usr / Kconfig에 있음)을 사용하여 initramfs 아카이브의 소스를 지정할 수 있으며,이 바이너리는 결과 바이너리에 자동으로 통합됩니다. 이 옵션은 기존 gzipped cpio 아카이브, 아카이브 할 파일이 포함 된 디렉토리 또는 다음 예제와 같은 텍스트 파일 스펙을 가리킬 수 있습니다.

  dir /dev 755 0 0
  nod /dev/console 644 0 0 c 5 1
  nod /dev/loop0 644 0 0 b 7 0
  dir /bin 755 1000 1000
  slink /bin/sh busybox 777 0 0
  file /bin/busybox initramfs/busybox 755 0 0
  dir /proc 755 0 0
  dir /sys 755 0 0
  dir /mnt 755 0 0
  file /init initramfs/init.sh 755 0 0

"usr / gen_init_cpio"(커널 빌드 후)를 실행하여 위 파일 형식을 설명하는 사용법 메시지를 받으십시오.

구성 파일의 한 가지 장점은 새 아카이브에서 권한을 설정하거나 장치 노드를 작성하기 위해 루트 액세스가 필요하지 않다는 것입니다. (이 두 "file"항목의 예는 linux-2.6. * 디렉토리의 "initramfs"라는 디렉토리에서 "init.sh"및 "busybox"라는 파일을 찾을 것으로 예상됩니다. Documentation / early-userspace / README는 자세한 내용은.)

커널은 외부 cpio 도구에 의존하지 않습니다. 구성 파일 대신 디렉토리를 지정하면 커널의 빌드 인프라는 해당 디렉토리에서 구성 파일을 작성하고 (usr / Makefile은 scripts / gen_initramfs_list.sh를 호출) 구성 파일을 사용하여 해당 디렉토리를 패키지화합니다. usr / gen_init_cpio.c에서 작성된 usr / gen_init_cpio). 커널의 빌드 타임 cpio 생성 코드는 완전히 자체 포함되어 있으며 커널의 부트 타임 추출기도 자체적으로 포함되어 있습니다.