initrd.img를 다시 포장하는 방법?


9

원래 /boot/initrd.img-에서 kernel_ver의 binwalk 방송이 구조 :

여기에 이미지 설명을 입력하십시오

에서 02만2천5백28 바이트 CPIO 아카이브는 특정 폴더 계층 구조 만 GenuineIntel.bin 펌웨어가 포함되어있다. 22528 바이트
부터 적절한 파일 시스템을 포함하는 gzip 아키텍처가 있으며이 gzip은 CPIO와 함께 아카이브됩니다.

압축을 풀고 수정 한 후 어떻게 같은 폴더 계층에서 같은 방법으로 initrd.img를 압축 할 수 있습니까? 이 원래 구조처럼 :

여기에 이미지 설명을 입력하십시오

의견 제안 후 :

find . | cpio --quiet --dereference -o -H newc | lzma -7 > ../cusotm.initrd.lz

binwalk :

여기에 이미지 설명을 입력하십시오

이것은 완전히 다른 구조입니다.


initrd.img를 작업 디렉토리로 추출하십시오. 특정 폴더 계층 구조로 GenuineIntel.bin 펌웨어를 작업 디렉토리에 추가합니다. 그런 다음 find . | cpio --quiet --dereference -o -H newc | lzma -7 > ../cusotm.initrd.lz프로 시저가 작동하지 않는 경우를 실행 하여 아카이브를 다시 작성하십시오. 실행 한 명령과 작동하지 않는 명령을 명확히하십시오.
Panther

그림으로 편집 한 내용은 문제에 대한 나의 이해에 거의 도움이되지 않습니다. GenuineIntel.bin 펌웨어의 적절한 파일 구조와 위치를 사용하여 이미지를 추출하고 코드에 추가 한 다음 새 .img로 다시 패키지해야합니다.
Panther

내가 말한 것처럼 @ bodhi.zazen 다른 파일을 만들었습니다 ...
EdiD

@ bodhi.zazen 마침내 내가 무엇을 요구하는지 이해합니까?
EdiD

1
initramfs 파일이 CPIO 아카이브의 연결 인 것 같습니다. 각 CPIO 아카이브는 압축 (gzip, xz 등)하거나 압축 해제 할 수 있습니다. 입력 파일은 오프셋 0에서 압축되지 않은 파일로 시작한 다음 오프셋 22528에서 압축 된 파일로 계속됩니다. 불행히도 압축 된 CPIO 아카이브의 연결을 추출 할 수있는 표준 도구는 알 수 없습니다.
pts

답변:


4

정확히 같은 initrd.img아카이브 를 만드는 방법을 알아 냈습니다 .

Bodhi.zazen 답변은 일반적으로 알려진 솔루션이므로 작동합니다.

find . | cpio --quiet --dereference -o -H newc | lzma -7 > ../cusotm.initrd.lz

그러나 질문은 달랐습니다. 이 답변은 cpio 아카이브에 하나의 gzipped 파일 시스템이 있지만이 상황에서 유지하려는 특정 폴더 구조에 Intel 펌웨어도있는 경우 좋습니다.

동일한 폴더 계층 구조를 유지하려면 세 단계가 필요합니다.

  1. 예를 들어 newc 형식을 사용 하지 않고 simple -o 옵션을 사용하여 CPIO 파일 시스템 아카이브를 만듭니다 . 기본 폴더 :

    find . | cpio -o | gzip -9 > ../base/file_system.gz

  2. kernel / x86 / microcode / GenuineIntel.bin을 포함하는 newc 형식으로 적절한 아카이브를 만드십시오 :

    find kernel/ | cpio -o -H newc > new_initrd.img

  3. gzip으로 압축 된 파일 시스템 아카이브를 적절한 new_initrd.img에 추가하십시오.

    find base/ | cpio -o >> new_initrd.img


1
큰! 감사! +10! 그러나 원래 initrd의 압축을 푸는 방법은 무엇입니까?
rth

또한 솔루션이 약간 다른 구조를 만듭니다. 나는 (2) 단계를 먼저 수행 한 다음 binwalk에서 완전히 동일한 구조를 가졌습니다.find . | cpio -o | gzip -9 >> new_initrd.img
rth

@EdiD 원래 initrd의 압축을 풀려면 어떻게해야합니까?
ImranRazaKhan

1
@ImranRazaKhan 당신은 네 단계가 필요합니다 : cpio -id < initrd.img-kernel_ver; dd if=initrd.img-4.4.0-22-generic of=image.gz bs=22528 skip=1-initrd.img 파일 이름 및 블록 크기와 일치하십시오. gunzip image.gz; cpio -i < image
EdiD

3

리 패키지

cd your_working_directory_with_modifications
find . | cpio --quiet --dereference -o -H newc | lzma -7 > ../cusotm.initrd.lz

두 번째 명령은 initrd의 이름을 바꾸고, grub에서 부팅 할 때 사용할 initrd를 지정합니다.

사용자 정의 initrd를 이동하거나 이름을 바꾸기 전에 테스트 (부팅)하는 것이 좋습니다.

의견에 대한 토론의 추가 정보 :

먼저 나는 당신이 cpio / tar의 역할을 이해하고 있다고 생각하지 않습니다. cpio와 tar는 많은 파일 및 / 또는 디렉토리를 가져 와서 하나의 파일 또는 아카이브로 만듭니다.

둘째, 압축의 역할을 이해하지 못한다고 생각하면 압축은 단순히 결과 아카이브를 작게 만듭니다. 압축을 원하는 도구를 사용할 수 있습니다.

보다

https://wiki.ubuntu.com/CustomizeLiveInitrd

https://wiki.gentoo.org/wiki/Initramfs/Guide

셋째, 리눅스 커널은 tar 대신 cipo를 사용합니다.

보다

https://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt

"왜 tar가 아닌 cpio입니까?"를 참조하십시오. 부분

왜 tar가 아닌 cpio입니까?

이 결정은 2001 년 12 월에 이루어졌습니다. 토론은 여기에서 시작되었습니다.

http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1538.html

그리고 여기에서 시작하여 두 번째 스레드 (특히 tar 대 cpio)를 생성했습니다.

http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1587.html

빠르고 더러운 요약 버전 (위의 스레드를 대신 할 수 없음)은 다음과 같습니다.

1) cpio는 표준입니다. AT & T 시절부터 수십 년 전이며 Linux (Red Hat의 장치 드라이버 디스크 인 RPM 내부)에서 이미 널리 사용되고 있습니다. 다음은 1996 년의 Linux Journal 기사입니다.

  http://www.linuxjournal.com/article/1213

전통적인 cpio 명령 줄 도구에는 _truly_hideous_ 명령 줄 인수가 필요하기 때문에 tar만큼 인기가 없습니다. 그러나 이것은 아카이브 형식에 대해 아무 말도하지 않으며 다음과 같은 대체 도구가 있습니다.

 http://freecode.com/projects/afio

2) 커널이 선택한 cpio 아카이브 형식은 다양한 문자 그대로의 tar 아카이브 형식보다 간단하고 깔끔합니다 (따라서 작성 및 구문 분석이 더 쉽습니다). 전체 initramfs 아카이브 형식은 usr / gen_init_cpio.c에 작성되고 init / initramfs.c에 추출 된 buffer-format.txt에 설명되어 있습니다. 이 세 가지가 모두 26k 미만의 사람이 읽을 수있는 텍스트입니다.

3) tar로 표준화 한 GNU 프로젝트는 zip으로 표준화 한 Windows와 거의 관련이 있습니다. Linux도 그 일부가 아니며 자체적으로 기술적 인 결정을 내릴 수 있습니다.

4) 이것은 커널 내부 형식이므로
새로운 것일 수 있습니다 . 커널은 어쨌든이 형식을 만들고 추출 할 수있는 자체 도구를 제공합니다. 기존 표준을 사용하는 것이 바람직했지만 필수는 아닙니다.

5) Al Viro가 결정을 내렸다 ( "견적 : 추악한 것은 못 생겼고 커널 쪽에서는 지원되지 않을 것이다").

  http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1540.html

그의 추론을 설명했다 :

  http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1550.html
  http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1638.html

그리고 가장 중요한 것은 initramfs 코드를 디자인하고 구현 한 것입니다.


폴더 구조는 유지되지 않습니다. 원래 initrd.img와 동일한 구조를 원합니다. 의미-> GenuineIntel.bin은 커널 / x86 / 마이크로 코드 폴더의 루트에 cpio로 아카이브되어 압축되지 않았으며 gzip에 대해 이야기하는 동안 왜 lzma입니까?
EdiD

lzma는 더 작은 아카이브를 제공합니다. 원하는 경우 gzip을 사용하십시오. 압축에 관심이있는 이유는 확실하지 않으며 압축으로 잘 작동하여 디스크의 이미지가 작아야합니다. 당신이 게시 한 것에서 무엇을 성취하려고하는지 확실하지 않습니다.
Panther

나는 그것이 원래 어떻게되었는지 알고 싶다. 빠른 액세스 가능성으로 인해 인텔 펌웨어가 압축되지 않았을 수 있습니다.
EdiD

거의 확실하게 압축되었으므로 아카이브를 확인할 수 있습니다. 압축은 성능에 눈에 띄게 영향을 미치지 않으므로 기본적으로 사용됩니다.
Panther

cpio 매뉴얼에는 압축에 관한 내용이 없습니다. 수락 된 답변 확인 : superuser.com/questions/343915/…
EdiD

3

나는 최근에 같은 질문에 부딪 쳤고 웹 검색으로 인해이 스레드로 이끌었습니다. 따라서 다른 사람들이 그 발자취를 따르는 데 도움이되는 경우 오래된 질문에 대한 2018 년 답변이 있습니다 ...

"최근"커널에서 initrd.img 파일은 일반 initramfs 디렉토리 트리를 포함하는 (압축 된) cpio 아카이브 앞에 추가 된 압축되지 않은 cpio 아카이브 (예 : 마이크로 코드 업데이트 포함)를 포함 할 수 있습니다.

이것은 데비안 위키 페이지에 간략하게 설명되어 있습니다 :
https://wiki.debian.org/initramfs#How_to_inspect_initramfs
만의 initrd.img 파일의 종류를 구문 분석에 대한 더 정확한 코드는에서 찾을 수 있습니다 splitinitramfs()내에서 기능 unmkinitramfs에있는 명령 initramfs-tools-core패키지 (예 : https://git.launchpad.net/ubuntu/+source/initramfs-tools/tree/unmkinitramfs ).

나는 이런 종류의 initrd.img 파일을 스스로 재 구축하려고 시도하지는 않았지만, Wiki 페이지를 기반으로 initramfs 부트 스크립트를 편집하면 GenuineIntel 아카이브를 전혀 풀고 싶지 않은 것 같습니다. 대신, cpio 아카이브를 따로 따로 보관 한 다음 두 번째 (압축 된) 아카이브의 압축을 풀고 디렉토리 트리를 수정 한 후 압축 된 cpio 아카이브를 다시 빌드 한 다음 저장된 마이크로 코드 아카이브를 새로 생성 된 아카이브와 연결할 수 있습니다.

(이 "prepended"아카이브를 처음 생성 한 코드는에서 찾을 수 있습니다 /usr/share/initramfs-tools/hooks/intel_microcode.)


0

우분투에서는 initrd.imggzip으로 압축되어 있으므로 편집 할 때 이것을 유지하고 싶습니다. 이것은 방법입니다 :

추출물:

zcat /boot/initrd.img-3.19.0-80-generic | cpio --extract

압박 붕대:

find . 2>/dev/null | cpio --quiet --dereference -o -H newc | gzip -9 > /boot/initrd.img-3.19.0-80-generic
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.