Jak przepakować initrd.img?

Na oryginalnym /boot/initrd.img- kernel_ver binwalk pokazuje tę strukturę:

Od 0 do 22528 bajtów archiwum CPIO zawiera tylko oprogramowanie układowe GenuineIntel.bin w określonej hierarchii folderów.
Od 22528 bajtów istnieje gzip archiwe zawiera odpowiedni system plików, a ten gzip jest również archiwizowany za pomocą CPIO

Po rozpakowaniu i modyfikacji, jak mogę skompresować plik initrd.img w ten sam sposób (z tą samą hierarchią folderów)? jak ta oryginalna struktura:

Po sugestii z komentarza:

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

binwalk :

To zupełnie inna struktura.

Wymyśliłem, jak zrobić dokładnie to samo initrd.imgarchiwum.

Odpowiedź Bodhi.zazen prawdopodobnie zadziała, ponieważ jest to powszechnie znane rozwiązanie:

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

ale pytanie było inne. Ta odpowiedź byłaby dobra, gdyby w archiwum CPIO był jeden system plików spakowany gzipem, ale w tej sytuacji jest też oprogramowanie układowe Intela w określonej strukturze folderów, które chcę zachować.

Aby zachować tę samą hierarchię folderów, potrzebne są trzy kroki:

1. Utwórz archiwum systemu plików CPIO z prostą opcją -o bez nowego formatu utworzonego przed np. folder podstawowy:

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

2. Utwórz właściwe archiwum w nowym formacie zawierającym jądro / x86 / microcode / GenuineIntel.bin :

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

3. Dodaj spakowane archiwum systemu plików do właściwego pliku new_initrd.img:

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

Przepakowujesz za pomocą

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

Drugie polecenie zmienia nazwę initrd, określasz initrd, który ma być używany podczas uruchamiania systemu grub.

Sugeruję przetestowanie (uruchomienie) niestandardowego initrd przed przeniesieniem lub zmianą nazwy.

Dodatkowe informacje z dyskusji w komentarzach:

Po pierwsze nie sądzę, że rozumiesz rolę cpio / tar. zarówno cpio, jak i tar pobierają wiele plików i / lub katalogów i tworzą je w jednym pliku lub archiwum.

Po drugie, nie sądzę, że rozumiesz rolę kompresji, kompresja po prostu zmniejsza wynikowe archiwum. Możesz użyć dowolnego narzędzia do kompresji.

Widzieć

https://wiki.ubuntu.com/CustomizeLiveInitrd

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

Po trzecie, jądro Linuksa używa cipo zamiast tar.

Widzieć

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

Zobacz „Dlaczego cpio zamiast tar?” Sekcja

Dlaczego CPIO zamiast smoły?

Decyzja została podjęta w grudniu 2001 roku. Dyskusja rozpoczęła się tutaj:

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

I pojawił się drugi wątek (szczególnie na tar vs cpio), zaczynając tutaj:

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

Szybka i brudna wersja podsumowania (która nie zastępuje czytania powyższych wątków) to:

1) CPIO jest standardem. Ma dziesiątki lat (od czasów AT&T) i jest już szeroko stosowany w systemie Linux (w RPM, dyskach ze sterownikami urządzeń Red Hata). Oto artykuł na ten temat w Linux Journal z 1996 roku:

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

Nie jest tak popularny jak tar, ponieważ tradycyjne narzędzia wiersza polecenia cpio wymagają argumentów wiersza polecenia naprawdę. Ale to nic nie mówi o formacie archiwum, a istnieją alternatywne narzędzia, takie jak:

 http://freecode.com/projects/afio

2) Format archiwum CPIO wybrany przez jądro jest prostszy i czystszy (a zatem łatwiejszy do utworzenia i analizy) niż jakikolwiek z (dosłownie dziesiątek) różnych formatów archiwów tar. Pełny format archiwum initramfs wyjaśniono w pliku-buforze-format.txt, utworzonym w usr / gen_init_cpio.c i wyodrębnionym w init / initramfs.c. Wszystkie trzy razem zawierają mniej niż 26 tys. Tekstu czytelnego dla człowieka.

3) Projekt GNU standaryzujący na tar jest mniej więcej tak samo ważny jak system Windows na zipie. Linux nie jest częścią żadnego z nich i może podejmować własne decyzje techniczne.

4) Ponieważ jest to wewnętrzny format jądra, może to być
coś zupełnie nowego. Jądro zapewnia własne narzędzia do tworzenia i wyodrębniania tego formatu. Zastosowanie istniejącego standardu było lepsze, ale nie konieczne.

5) Al Viro podjął decyzję (cytat: „smoła jest brzydka jak diabli i nie będzie wspierana po stronie jądra”):

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

wyjaśnił swoje rozumowanie:

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

i, co najważniejsze, zaprojektował i wdrożył kod initramfs.

Niedawno natknąłem się na to samo pytanie, a moje wyszukiwanie w sieci doprowadziło mnie do tego wątku, więc w przypadku, gdy pomaga to innym podążać tymi śladami, oto odpowiedź na stare pytanie z 2018 roku ...

Wydaje się, że w „najnowszych” jądrach plik initrd.img może zawierać nieskompresowane archiwum cpio (tj. Zawierające aktualizacje mikrokodu) dołączone do (skompresowanego) archiwum cpio zawierającego normalne drzewo katalogów initramfs.

Zostało to krótko omówione na stronie Wiki Debiana:
https://wiki.debian.org/initramfs#How_to_inspect_initramfs
, ale dokładniejszy kod do analizowania tego rodzaju pliku initrd.img można znaleźć w splitinitramfs()funkcji w unmkinitramfspoleceniu znajdującym się w initramfs-tools-corepakiet (np. https://git.launchpad.net/ubuntu/+source/initramfs-tools/tree/unmkinitramfs ).

Sam nie próbowałem odbudować tego rodzaju pliku initrd.img, ale na podstawie tej strony Wiki wydaje się, że aby edytować skrypty startowe initramfs, wcale nie chciałbym rozpakowywać archiwum GenuineIntel. Zamiast tego możesz po prostu zachować to archiwum cpio gdzie jest osobno, a następnie rozpakować drugie (skompresowane) archiwum, zmodyfikować drzewo katalogów i odbudować skompresowane archiwum cpio, a następnie połączyć zapisane archiwum mikrokodu z nowo wygenerowanym.

(Kod, który pierwotnie wygenerował to „gotowe” archiwum, znajduje się w /usr/share/initramfs-tools/hooks/intel_microcode.)

w Ubuntu initrd.imgjest skompresowany w gzip, chciałbym zachować to podczas edycji. Oto jak:

wyciąg:

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

Kompresja:

find . 2>/dev/null | cpio --quiet --dereference -o -H newc | gzip -9 > /boot/initrd.img-3.19.0-80-generic