Wie packe ich initrd.img neu?

9

Auf original /boot/initrd.img- kernel_ver binwalk wird diese Struktur angezeigt :

Von 0 bis 22528 Bytes gibt es ein CPIO-Archiv, das nur die Firmware GenuineIntel.bin in einer bestimmten Ordnerhierarchie enthält.
Ab 22528 Bytes gibt es gzip archiwe enthält das entsprechende Dateisystem und dieses gzip wird auch mit CPIO archiviert

Wie kann ich nach dem Entpacken und Ändern initrd.img auf dieselbe Weise komprimieren (mit derselben Ordnerhierarchie)? wie diese ursprüngliche Struktur:

Nach Vorschlag aus Kommentar:

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

binwalk ::

Dies ist eine völlig andere Struktur.

initramfs

— EdiD
quelle

Sie extrahieren die Datei initrd.img in ein Arbeitsverzeichnis. Sie fügen Ihre GenuineIntel.bin-Firmware in einer bestimmten Ordnerhierarchie zum Arbeitsverzeichnis hinzu. Anschließend erstellen Sie das Archiv mit neu. find . | cpio --quiet --dereference -o -H newc | lzma -7 > ../cusotm.initrd.lzWenn diese Prozedur nicht funktioniert, klären Sie, welche Befehle Sie ausgeführt haben und welche nicht.

— Panther

Ihre Bearbeitung mit einem Bild trägt wenig zu meinem Verständnis Ihres Problems bei. Sie müssen das Image extrahieren, Ihren Code mit der entsprechenden Dateistruktur und dem Speicherort der GenuineIntel.bin-Firmware hinzufügen und in eine neue IMG-Datei umpacken.

— Panther

@ bodhi.zazen wie gesagt das hat eine andere Datei gemacht ...

— EdiD

@ bodhi.zazen verstehst du endlich was ich frage?

— EdiD

1

Es sieht so aus, als wäre die initramfs-Datei eine Verkettung von CPIO-Archiven. Jedes CPIO-Archiv kann komprimiert (mit gzip, xz usw.) oder dekomprimiert werden. Ihre Eingabedatei beginnt mit einer unkomprimierten Datei bei Offset 0 und wird dann mit einer komprimierten Datei bei Offset 22528 fortgesetzt. Leider kenne ich kein Standardwerkzeug, mit dem eine Verkettung von möglicherweise komprimierten CPIO-Archiven extrahiert werden kann.

— Punkte

4

Ich habe herausgefunden, wie man genau das gleiche initrd.imgArchiv erstellt.

Die Antwort von Bodhi.zazen wird wahrscheinlich funktionieren, da dies eine allgemein bekannte Lösung ist:

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

aber die Frage war anders. Diese Antwort wäre gut, wenn es im cpio-Archiv ein komprimiertes Dateisystem gibt, aber in dieser Situation gibt es auch Intel-Firmware in einer bestimmten Ordnerstruktur, die ich behalten möchte.

Um die gleiche Ordnerhierarchie beizubehalten, sind drei Schritte erforderlich:

Erstellen Sie ein CPIO- Dateisystemarchiv mit der einfachen Option -o ohne das zuvor erstellte Newc- Format. Basisordner:

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

Erstellen Sie das richtige Archiv mit dem newc- Format, das kernel / x86 / microcode / GenuineIntel.bin enthält :

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

Fügen Sie das gzipped-Dateisystemarchiv zur richtigen Datei new_initrd.img hinzu:

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

— EdiD
quelle

1

Großartig! Vielen Dank! +10! Aber wie entpackt man die Original-Initrd?

— rth

Außerdem schafft Ihre Lösung eine etwas andere Struktur. Ich habe das absolut die gleichen tructure in binwalk bekomme , wenn ich den Schritt tat (2) und dannfind . | cpio -o | gzip -9 >> new_initrd.img

— rth

@EdiD wie entpackst du original initrd?

— ImranRazaKhan

1

@ ImranRazaKhan Sie benötigen vier Schritte : cpio -id < initrd.img-kernel_ver; dd if=initrd.img-4.4.0-22-generic of=image.gz bs=22528 skip=1- Passen Sie Ihren initrd.img-Dateinamen und die Blockgröße an. gunzip image.gz;; cpio -i < image

— EdiD

3

Sie verpacken mit

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

Mit dem zweiten Befehl wird die initrd umbenannt. Sie geben die initrd an, die beim Booten in grub verwendet werden soll.

Ich schlage vor, dass Sie die benutzerdefinierte initrd testen (booten), bevor Sie sie verschieben oder umbenennen.

Zusätzliche Informationen aus der Diskussion in den Kommentaren:

Erstens glaube ich nicht, dass Sie die Rolle von cpio / tar verstehen. Sowohl cpio als auch tar nehmen eine Reihe von Dateien und / oder Verzeichnissen und machen sie zu einer Datei oder einem Archiv.

Zweitens glaube ich nicht, dass Sie die Rolle der Komprimierung verstehen. Durch die Komprimierung wird das resultierende Archiv einfach kleiner. Sie können jedes gewünschte Werkzeug für die Komprimierung verwenden.

Sehen

https://wiki.ubuntu.com/CustomizeLiveInitrd

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

Drittens verwendet der Linux-Kernel eher cipo als tar.

Sehen

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

Siehe "Warum CPIO statt Teer?" Sektion

Warum cpio statt teer?

Diese Entscheidung wurde bereits im Dezember 2001 getroffen. Die Diskussion begann hier:

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

Und es entstand ein zweiter Thread (speziell zu tar vs cpio), der hier beginnt:

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

Die schnelle und schmutzige Zusammenfassungsversion (die kein Ersatz für das Lesen der obigen Themen ist) lautet:

1) cpio ist ein Standard. Es ist Jahrzehnte alt (aus der Zeit von AT & T) und unter Linux bereits weit verbreitet (innerhalb von RPM, Red Hats Gerätetreiberdisketten). Hier ist ein Artikel aus dem Linux Journal von 1996:
  http://www.linuxjournal.com/article/1213
Es ist nicht so beliebt wie tar, da die traditionellen cpio-Befehlszeilentools _truly_hideous_ Befehlszeilenargumente erfordern. Das sagt jedoch nichts über das Archivformat aus, und es gibt alternative Tools wie:
 http://freecode.com/projects/afio
2) Das vom Kernel gewählte cpio-Archivformat ist einfacher und übersichtlicher (und damit einfacher zu erstellen und zu analysieren) als jedes der (buchstäblich Dutzende) verschiedenen Tar-Archivformate. Das vollständige Archivformat von initramfs wird in buffer-format.txt erläutert, in usr / gen_init_cpio.c erstellt und in init / initramfs.c extrahiert. Alle drei zusammen ergeben weniger als 26.000 lesbaren Text.

3) Das GNU-Projekt zur Standardisierung auf Teer ist ungefähr so relevant wie die Windows-Standardisierung auf Zip. Linux gehört auch nicht dazu und kann seine eigenen technischen Entscheidungen treffen.

4) Da dies ein internes Kernel-Format ist, könnte es leicht
etwas ganz Neues gewesen sein. Der Kernel bietet ohnehin eigene Tools zum Erstellen und Extrahieren dieses Formats. Die Verwendung eines vorhandenen Standards war vorzuziehen, aber nicht unbedingt erforderlich.

5) Al Viro traf die Entscheidung (Zitat: "Teer ist höllisch hässlich und wird auf der Kernelseite nicht unterstützt"):
  http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1540.html
erklärte seine Argumentation:
  http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1550.html
  http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1638.html
und vor allem den initramfs-Code entworfen und implementiert.

— Panther
quelle

Dadurch bleibt die Ordnerstruktur nicht erhalten. Ich möchte die gleiche Struktur wie das ursprüngliche initrd.img. Bedeutung -> GenuineIntel.bin nicht komprimiert, nur mit cpio im Stammverzeichnis im Ordner kernel / x86 / microcode archiviert und warum lzma, während ich über gzip spreche?

— EdiD

lzma gibt ein kleineres Archiv. Verwenden Sie gzip, wenn Sie möchten. Ich bin mir nicht sicher, warum Sie sich Gedanken über die Komprimierung machen oder nicht, sollte mit der Komprimierung gut funktionieren und zu einem kleineren Image auf der Festplatte führen. Ich bin mir nicht sicher, was Sie mit dem, was Sie gepostet haben, erreichen wollen.

— Panther

Ich möchte wissen, wie es ursprünglich gemacht wurde. Wahrscheinlich wird die Intel-Firmware aufgrund der schnelleren Zugänglichkeit nicht komprimiert.

— EdiD

Mit ziemlicher Sicherheit wurde komprimiert, Sie können das Archiv überprüfen. Die Komprimierung wird standardmäßig verwendet, da sie die Leistung nicht merklich beeinträchtigt.

— Panther

Im cpio-Handbuch gibt es nichts über Komprimierung. Überprüfen Sie akzeptierte Antwort: superuser.com/questions/343915/...

— EDID

3

Ich bin kürzlich auf dieselbe Frage gestoßen, und meine Websuche hat mich zu diesem Thread geführt. Falls dies anderen hilft, in diese Fußstapfen zu treten, finden Sie hier eine Antwort auf eine alte Frage aus dem Jahr 2018 ...

Es scheint, dass in "aktuellen" Kerneln die Datei initrd.img ein unkomprimiertes cpio-Archiv enthalten kann (dh Mikrocode-Aktualisierungen enthält), das dem (komprimierten) cpio-Archiv vorangestellt ist, das den normalen initramfs-Verzeichnisbaum enthält.

Dies wird auf der Debian-Wiki-Seite kurz erläutert:
https://wiki.debian.org/initramfs#How_to_inspect_initramfs
. Genaueren Code zum Parsen dieser Art von initrd.img-Datei finden Sie jedoch in der splitinitramfs()Funktion innerhalb des unmkinitramfsBefehls in der initramfs-tools-corePaket (z . B. https://git.launchpad.net/ubuntu/+source/initramfs-tools/tree/unmkinitramfs ).

Ich habe nicht versucht, diese Art von initrd.img-Datei selbst neu zu erstellen, aber basierend auf dieser Wiki-Seite scheint es, dass man das GenuineIntel-Archiv überhaupt nicht entpacken möchte, um die Boot-Skripte von initramfs zu bearbeiten. Stattdessen können Sie das cpio-Archiv einfach so wie es ist irgendwo separat aufbewahren, dann das zweite (komprimierte) Archiv entpacken, den Verzeichnisbaum ändern und das komprimierte cpio-Archiv neu erstellen und dann das gespeicherte Mikrocode-Archiv mit dem neu generierten verketten.

(Der Code, der ursprünglich dieses "vorangestellte" Archiv generiert hat, befindet sich in /usr/share/initramfs-tools/hooks/intel_microcode.)

— Nathan
quelle

0

in Ubuntu initrd.imgist das in gzip komprimiert, ich möchte dies beim Bearbeiten beibehalten. das ist wie:

Extrakt:

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

komprimieren:

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

— Jossef Harush
quelle