web-dev-qa-db-fra.com

Comment remballer initrd.img?

Sur l'original /boot/initrd.img-kernel_verbinwalkaffiche cette structure:

enter image description here

De 0 à 22528 octets il existe une archive CPIO contenant uniquement GenuineIntel.bin firmware 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écompressé et modifié, comment compresser initrd.img de la même manière (avec la même hiérarchie de dossiers)? comme cette structure originale:

enter image description here

Après suggestion du commentaire:

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

binwalkname__:

enter image description here

Cette structure est complètement différente.

initramfs
8
EdiD

Vous remballez 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 pour démarrer en mode Grub.

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

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

Premièrement, je ne pense pas que vous compreniez le rôle de cpio/tar. cpio et tar prennent tous deux 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, celle-ci réduit simplement l'archive résultante. Vous pouvez utiliser n’importe quel outil 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 le "Pourquoi cpio plutôt que le goudron?" section

Pourquoi cpio plutôt que goudron?

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 créé un deuxième fil (en particulier sur tar vs cpio), à partir d’ici:

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

La version sommaire rapide et incorrecte (qui ne remplace pas la lecture des discussions ci-dessus) est la suivante:

1) cpio est un standard. Il est vieux de plusieurs décennies (de l'époque AT & T) et déjà largement utilisé sous Linux (dans RPM, les disques de pilotes de périphériques de Red Hat). Voici un article du Linux Journal 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 dans le format d'archive, et il existe d'autres outils, 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 des (littéralement des dizaines de) formats d'archive tar. Le format d'archive complet initramfs est expliqué dans buffer-format.txt, créé dans usr/gen_init_cpio.c et extrait dans init/initramfs.c. Les trois ensemble représentent moins de 26 000 mots au total.

3) Le projet GNU, la normalisation sur tar est à peu près aussi pertinent que la normalisation Windows sur Zip. Linux ne fait partie ni de l'un ni de l'autre et est libre de prendre ses propres décisions techniques.

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

5) Al Viro a pris la décision (citation: "tar est aussi laid que possible et ne sera pas supporté 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, plus important encore, conçu et mis en œuvre le code initramfs.

3
Panther

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

La réponse de Bodhi.zazen fonctionnera probablement car il s’agit d’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 utile si dans une archive cpio, il existe un système de fichiers compressé, mais dans cette situation, il existe également un microprogramme Intel dans une structure de dossiers spécifique que je souhaite conserver.

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

  1. Créer une archive de système de fichiers CPIO avec une simple option -o sans le format newc préalablement créé, par exemple. dossier de base:

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

  2. 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

  3. Ajoutez une archive de système de fichiers gzipped au fichier new_initrd.img approprié:

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

3
EdiD

J'ai récemment rencontré cette même question et ma recherche sur le Web m'a conduit à ce fil. Si vous aidez d'autres personnes à suivre ces traces, voici la réponse de 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 les mises à jour du microcode) préfixée à l'archive (compressée) cpio contenant l'arborescence de répertoires initramfs normale.

Ceci est discuté brièvement dans la page du wiki Debian:
https://wiki.debian.org/initramfs#How_to_inspect_initramfs
, mais un code plus précis pour l'analyse de ce type de fichier initrd.img est disponible dans la fonction splitinitramfs() de la commande unmkinitramfs située dans le package initramfs-tools-core (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 si l'on se base sur cette page Wiki, il semble que pour éditer les scripts de démarrage initramfs, il ne faudrait pas du tout décompresser l'archive GenuineIntel. Au lieu de cela, vous pouvez simplement conserver l’archive cpio telle quelle quelque part séparément, puis décompresser la seconde archive (compressée), modifier l’arborescence de répertoires, reconstruire l’archive cpio compressée, puis concaténer l’archive de microcode enregistrée avec celle nouvellement générée.

(Le code à l'origine de cette archive "préparée" se trouve dans /usr/share/initramfs-tools/hooks/intel_microcode.)

1
Nathan

sous Ubuntu, le initrd.img est compressé dans gzip, je souhaite le conserver lorsque je l’édite. 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
0
Jossef Harush