Comment remballer initrd.img?

9

Sur /boot/initrd.img- kernel_ver d'origine binwalk montre cette structure:

De 0 à 22528 octets, l'archive CPIO contient uniquement le micrologiciel GenuineIntel.bin dans une hiérarchie de dossiers spécifique.
De 22528 octets il y a gzip archiwe contient le système de fichiers approprié et ce gzip est également archivé avec CPIO

Après avoir déballé et modifié comment puis-je compresser initrd.img de la même manière (avec la même hiérarchie de dossiers)? comme cette structure originale:

Après suggestion du commentaire:

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

binwalk :

C'est une structure complètement différente.

initramfs

— EdiD
source

Vous extrayez initrd.img dans un répertoire de travail. Vous ajoutez votre firmware GenuineIntel.bin dans une hiérarchie de dossiers spécifique au répertoire de travail. Vous refaites ensuite l'archive avec find . | cpio --quiet --dereference -o -H newc | lzma -7 > ../cusotm.initrd.lzSi cette procédure ne fonctionne pas, clarifiez les commandes que vous avez exécutées et celles qui ne fonctionnent pas.

— Panther

Votre montage, avec une photo, n'ajoute rien à ma compréhension de votre problème. Vous devez extraire l'image, ajouter votre code, avec la structure de fichiers et l'emplacement appropriés du micrologiciel GenuineIntel.bin et reconditionner dans un nouveau .img.

— Panther

@ bodhi.zazen comme je l'ai dit, cela a fait un fichier différent ...

— EdiD

@ bodhi.zazen comprenez-vous enfin ce que je demande?

— EdiD

1

Il semble que le fichier initramfs soit une concaténation d'archives CPIO. Chaque archive CPIO peut être compressée (avec gzip, xz etc.) ou non compressée. Votre fichier d'entrée commence par un fichier non compressé à l'offset 0, puis se poursuit par un fichier compressé à l'offset 22528. Malheureusement, je ne connais pas d'outil standard capable d'extraire une concaténation d'archives CPIO peut-être compressées.

— pts

4

J'ai compris comment créer exactement la même initrd.imgarchive.

La réponse Bodhi.zazen fonctionnera probablement parce que c'est une solution connue:

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

mais la question était différente. Cette réponse serait bonne si dans l'archive cpio il y a un système de fichiers compressé mais dans cette situation, il y a aussi le firmware Intel dans une structure de dossiers spécifique que je veux garder.

Pour conserver la même hiérarchie de dossiers, trois étapes sont nécessaires:

Faire l' archive du système de fichiers CPIO avec l'option -o simple sans format newc dans créé avant par exemple. dossier de base:

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

Créez une archive appropriée avec le format newc contenant le noyau / x86 / microcode / GenuineIntel.bin :

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

Ajoutez une archive de système de fichiers gzippé dans le fichier new_initrd.img approprié:

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

— EdiD
source

1

Génial! Merci! +10! Mais comment déballer l'initrd d'origine?

— RTH

De plus, votre solution crée une structure un peu différente. J'ai le même absolument tructure dans binwalk quand je l'ai fait l'étape (2) d' abord, puisfind . | cpio -o | gzip -9 >> new_initrd.img

— RTH

@EdiD comment décompressez-vous l'initrd original?

— ImranRazaKhan

1

@ImranRazaKhan vous avez besoin de quatre étapes: cpio -id < initrd.img-kernel_ver; dd if=initrd.img-4.4.0-22-generic of=image.gz bs=22528 skip=1-match votre nom de fichier initrd.img et la taille du bloc; gunzip image.gz; cpio -i < image

— EdiD

3

Vous reconditionnez avec

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

La deuxième commande renomme l'initrd, vous spécifiez l'initrd à utiliser lors du démarrage dans grub.

Je vous suggère de tester (démarrer) l'initrd personnalisé avant de le déplacer ou de le renommer.

Informations supplémentaires issues de la discussion dans les commentaires:

Tout d'abord, je ne pense pas que vous compreniez le rôle de cpio / tar. cpio et tar prennent un certain nombre de fichiers et / ou de répertoires et les transforment en un seul fichier ou archive.

Deuxièmement, je ne pense pas que vous compreniez le rôle de la compression, la compression rend simplement l'archive résultante plus petite. Vous pouvez utiliser n'importe quel outil que vous souhaitez pour la compression.

Voir

https://wiki.ubuntu.com/CustomizeLiveInitrd

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

Troisièmement, le noyau Linux utilise cipo plutôt que tar.

Voir

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

Voir "Pourquoi cpio plutôt que tar?" section

Pourquoi cpio plutôt que tar?

Cette décision a été prise en décembre 2001. La discussion a commencé ici:

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

Et a engendré un deuxième thread (spécifiquement sur tar vs cpio), commençant ici:

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

La version de résumé rapide et sale (qui ne remplace pas la lecture des discussions ci-dessus) est:

1) cpio est une norme. Il a des décennies (depuis les jours AT&T) et est déjà largement utilisé sur Linux (à l'intérieur de RPM, les disques de pilotes de périphériques de Red Hat). Voici un article du Linux Journal à ce sujet de 1996:
  http://www.linuxjournal.com/article/1213
Ce n'est pas aussi populaire que tar car les outils de ligne de commande cpio traditionnels nécessitent des arguments de ligne de commande _truly_hideous_. Mais cela ne dit rien sur le format d'archive, et il existe des outils alternatifs, tels que:
 http://freecode.com/projects/afio
2) Le format d'archive cpio choisi par le noyau est plus simple et plus propre (et donc plus facile à créer et à analyser) que n'importe lequel (littéralement des dizaines de) différents formats d'archive tar. Le format complet de l'archive initramfs est expliqué dans buffer-format.txt, créé dans usr / gen_init_cpio.c et extrait dans init / initramfs.c. Tous les trois réunis représentent moins de 26 000 au total de texte lisible par l'homme.

3) Le projet GNU standardisant sur tar est à peu près aussi pertinent que Windows standardisant sur zip. Linux ne fait pas partie non plus et est libre de prendre ses propres décisions techniques.

4) Puisqu'il s'agit d'un format interne du noyau, il aurait pu facilement être
quelque chose de nouveau. Le noyau fournit de toute façon ses propres outils pour créer et extraire ce format. L'utilisation d'une norme existante était préférable, mais pas indispensable.

5) Al Viro a pris la décision (citation: "tar est moche comme l'enfer et ne va pas être pris en charge du côté du noyau"):
  http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1540.html
a expliqué son raisonnement:
  http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1550.html
  http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1638.html
et, surtout, conçu et implémenté le code initramfs.

— Panthère
source

Cela ne préservera pas la structure des dossiers. Je veux la même structure que initrd.img d'origine. Signification -> GenuineIntel.bin non compressé vient d'être archivé avec cpio à la racine dans le dossier kernel / x86 / microcode et pourquoi lzma pendant que je parle de gzip?

— EdiD

lzma donne une archive plus petite. utilisez gzip si vous le souhaitez. Je ne sais pas pourquoi vous vous inquiétez de la compression ou non, devrait fonctionner très bien avec la compression et entraîner une image plus petite sur le disque. Je ne sais pas vraiment ce que vous essayez d'accomplir à partir de ce que vous avez publié.

— Panther

Je veux savoir comment cela a été fait à l'origine. Le micrologiciel Intel n'est probablement pas compressé en raison d'une accessibilité plus rapide.

— EdiD

presque certainement compressé, vous pouvez consulter l'archive. La compression est utilisée par défaut car elle n'affecte pas sensiblement les performances.

— Panther

Il n'y a rien dans le manuel de cpio sur la compression. Vérifiez la réponse acceptée: superuser.com/questions/343915/…

— EdiD

3

J'ai récemment rencontré cette même question et ma recherche sur le Web m'a conduit à ce fil, donc au cas où cela aiderait les autres à suivre ces traces, voici une réponse 2018 à une vieille question ...

Il semble que dans les noyaux "récents" le fichier initrd.img puisse contenir une archive cpio non compressée (c'est-à-dire contenant des mises à jour de microcode) ajoutée à l'archive cpio (compressée) contenant l'arborescence de répertoires initramfs normale.

Ceci est discuté brièvement dans la page Wiki Debian:
https://wiki.debian.org/initramfs#How_to_inspect_initramfs
, mais un code plus précis pour l'analyse à travers ce type de fichier initrd.img peut être trouvé dans la splitinitramfs()fonction dans la unmkinitramfscommande trouvée dans le initramfs-tools-corepackage (par exemple https://git.launchpad.net/ubuntu/+source/initramfs-tools/tree/unmkinitramfs ).

Je n'ai pas essayé de reconstruire ce type de fichier initrd.img moi-même, mais sur la base de cette page Wiki, il semble que pour modifier les scripts de démarrage initramfs, on ne voudrait pas du tout décompresser l'archive GenuineIntel. Au lieu de cela, vous pouvez simplement conserver cette archive cpio telle quelle quelque part séparément, puis décompresser la deuxième archive (compressée), modifier l'arborescence de répertoires et reconstruire l'archive cpio compressée, puis concaténer l'archive de microcode enregistrée avec la nouvelle archive générée.

(Le code qui a généré à l'origine cette archive "pré-ajoutée" se trouve dans /usr/share/initramfs-tools/hooks/intel_microcode.)

— Nathan
source

0

dans Ubuntu le initrd.imgest compressé en gzip, je voudrais le conserver quand je le modifie. c'est ainsi:

extrait:

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

compresse:

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

— Jossef Harush
source