Come reimballare initrd.img?

9

Nell'originale /boot/initrd.img- kernel_ver binwalk mostra questa struttura:

Da 0 a 22528 byte esiste un archivio CPIO che contiene solo il firmware GenuineIntel.bin nella gerarchia di cartelle specifica.
Da 22528 byte c'è gzip archiwe contiene il file system appropriato e questo gzip è anche archiviato con CPIO

Dopo aver decompresso e modificato come posso comprimere initrd.img allo stesso modo (con la stessa gerarchia di cartelle)? come questa struttura originale:

Dopo il suggerimento dal commento:

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

binwalk :

Questa è una struttura completamente diversa.

initramfs

— edid
fonte

Estrarre initrd.img in una directory di lavoro. Aggiungi il tuo firmware GenuineIntel.bin nella gerarchia di cartelle specifiche nella directory di lavoro. Quindi rifare l'archivio con find . | cpio --quiet --dereference -o -H newc | lzma -7 > ../cusotm.initrd.lzSe quella procedura non funziona, chiarire quali comandi sono stati eseguiti e cosa non funziona.

— Pantera,

La tua modifica, con una foto, aggiunge poco a nulla della mia comprensione del tuo problema. Devi estrarre l'immagine, aggiungere il tuo codice, con la struttura dei file e la posizione appropriate del firmware GenuineIntel.bin e reimballare in un nuovo .img.

— Pantera,

@ bodhi.zazen come ho detto, questo ha reso diversi file ...

— EdiD,

@ bodhi.zazen hai finalmente capito cosa ti sto chiedendo?

— EdiD,

1

Sembra che il file initramfs sia una concatenazione di archivi CPIO. Ogni archivio CPIO può essere compresso (con gzip, xz ecc.) O non compresso. Il tuo file di input inizia con uno non compresso a offset 0, quindi continua con uno compresso a offset 22528. Sfortunatamente non conosco uno strumento standard in grado di estrarre una concatenazione di archivi CPIO forse compressi.

— punti

4

Ho capito come fare esattamente lo stesso initrd.imgarchivio.

La risposta di Bodhi.zazen probabilmente funzionerà perché questa è una soluzione comunemente nota:

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

ma la domanda era diversa. Questa risposta sarebbe buona se nell'archivio cpio c'è un file system compresso con gzip ma in questa situazione c'è anche un firmware Intel nella specifica struttura di cartelle che voglio conservare.

Per mantenere la stessa gerarchia di cartelle sono necessari tre passaggi:

Crea un archivio di file system CPIO con l'opzione -o semplice senza il formato newc creato prima di es. cartella base:

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

Crea l'archivio corretto con il formato newc contenente kernel / x86 / microcode / GenuineIntel.bin :

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

Aggiungi l'archivio del file system gzipped al file new_initrd.img corretto:

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

— edid
fonte

1

Grande! Grazie! +10! Ma come si fa a decomprimere initrd originale?

— RTH

Inoltre, la tua soluzione crea una struttura leggermente diversa. Ho l'assolutamente lo stesso truttura in binwalk quando ho fatto il punto (2) e poifind . | cpio -o | gzip -9 >> new_initrd.img

— RTH

@EdiD come si decomprime initrd originale?

— ImranRazaKhan,

1

@ImranRazaKhan è necessario quattro fasi: cpio -id < initrd.img-kernel_ver; dd if=initrd.img-4.4.0-22-generic of=image.gz bs=22528 skip=1-match il nome del file initrd.img e la dimensione del blocco; gunzip image.gz; cpio -i < image

— EdiD

3

Confezionate con

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

Il secondo comando rinomina initrd, si specifica initrd da usare quando si avvia in grub.

Ti consiglio di provare (avviare) l'inizrd personalizzato prima di spostarlo o rinominarlo.

Ulteriori informazioni dalla discussione nei commenti:

Innanzitutto non penso che tu stia capendo il ruolo di cpio / tar. sia cpio che tar prendono un numero di file e / o directory e li trasformano in un unico file o archivio.

Secondo, non penso che tu capisca il ruolo della compressione, la compressione semplicemente riduce l'archivio risultante. Puoi usare qualsiasi strumento tu desideri per la compressione.

Vedere

https://wiki.ubuntu.com/CustomizeLiveInitrd

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

Terzo, il kernel di Linux usa cipo piuttosto che tar.

Vedere

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

Vedi "Perché cpio anziché tar?" sezione

Perché cpio anziché tar?

Questa decisione è stata presa nel dicembre 2001. La discussione è iniziata qui:

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

E ha generato un secondo thread (in particolare su tar vs cpio), iniziando qui:

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

La versione di riepilogo rapida e sporca (che non sostituisce la lettura dei thread sopra) è:

1) cpio è uno standard. Ha decenni (dai tempi di AT&T) e già ampiamente utilizzato su Linux (all'interno di RPM, i dischi driver del dispositivo Red Hat). Ecco un articolo del Linux Journal a riguardo dal 1996:
  http://www.linuxjournal.com/article/1213
Non è così popolare come tar perché i tradizionali strumenti della riga di comando di cpio richiedono argomenti della riga di comando _truly_hideous_. Ma questo non dice nulla in alcun modo sul formato dell'archivio e ci sono strumenti alternativi, come:
 http://freecode.com/projects/afio
2) Il formato dell'archivio cpio scelto dal kernel è più semplice e pulito (e quindi più facile da creare e analizzare) rispetto a uno dei (letteralmente dozzine di) diversi formati di archivio tar. Il formato completo dell'archivio initramfs è spiegato in buffer-format.txt, creato in usr / gen_init_cpio.c ed estratto in init / initramfs.c. Tutti e tre insieme arrivano a meno di 26k di testo leggibile dall'uomo.

3) Il progetto GNU che standardizza su tar è approssimativamente rilevante quanto la standardizzazione di Windows su zip. Linux non fa parte di nessuno dei due ed è libero di prendere le proprie decisioni tecniche.

4) Dato che si tratta di un formato interno del kernel, avrebbe potuto facilmente essere
qualcosa di nuovo. Il kernel fornisce i propri strumenti per creare ed estrarre questo formato comunque. L'uso di uno standard esistente era preferibile, ma non essenziale.

5) Al Viro ha preso la decisione (citazione: "tar è brutto da morire e non sarà supportato dal lato kernel"):
  http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1540.html
ha spiegato il suo ragionamento:
  http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1550.html
  http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1638.html
e, soprattutto, progettato e implementato il codice initramfs.

— Pantera
fonte

Ciò non manterrà la struttura delle cartelle. Voglio la stessa struttura dell'originale initrd.img. Significato -> GenuineIntel.bin non compresso appena archiviato con cpio su root nella cartella kernel / x86 / microcode e perché lzma mentre sto parlando di gzip?

— EdiD

lzma fornisce un archivio più piccolo. usa gzip se lo desideri. Non sono sicuro del motivo per cui sei preoccupato per la compressione o meno, dovrebbe funzionare bene con la compressione e provocare un'immagine più piccola sul disco. Non sono davvero sicuro di ciò che stai cercando di ottenere da ciò che hai pubblicato.

— Pantera,

Voglio sapere come è stato originariamente fatto. Probabilmente il firmware Intel non è compresso a causa della maggiore accessibilità.

— EdiD

quasi sicuramente è stato compresso, è possibile controllare l'archivio. La compressione viene utilizzata per impostazione predefinita in quanto non influisce in modo evidente sulle prestazioni.

— Pantera,

Non c'è nulla nel manuale di cpio sulla compressione. Controlla la risposta accettata: superuser.com/questions/343915/…

— EdiD

3

Di recente mi sono imbattuto in questa stessa domanda e la mia ricerca sul web mi ha portato a questa discussione, quindi nel caso in cui aiuti gli altri a seguire quelle orme, ecco una risposta del 2018 a una vecchia domanda ...

Sembra che nei kernel "recenti" il file initrd.img possa contenere un archivio cpio non compresso (ovvero contenente aggiornamenti di microcodici) anteposto all'archivio (compresso) di cpio contenente il normale albero di directory initramfs.

Questo è discusso brevemente nella pagina Wiki Debian:
https://wiki.debian.org/initramfs#How_to_inspect_initramfs
, ma un codice più preciso per l'analisi attraverso questo tipo di file initrd.img si trova nella splitinitramfs()funzione all'interno del unmkinitramfscomando trovato nel comando trovato nel comando initramfs-tools-corepacchetto (ad es. https://git.launchpad.net/ubuntu/+source/initramfs-tools/tree/unmkinitramfs ).

Non ho provato a ricostruire questo tipo di file initrd.img da solo, ma sulla base di quella pagina Wiki sembra che per modificare gli script di avvio di initramfs, non si vorrebbe affatto decomprimere l'archivio GenuineIntel. Invece, potresti semplicemente conservare l'archivio cpio così com'è da qualche parte separatamente, quindi decomprimere il secondo archivio (compresso), modificare l'albero delle directory e ricostruire l'archivio cpio compresso, quindi concatenare l'archivio microcodice salvato con quello appena generato.

(Il codice che ha originariamente generato questo archivio "anteposto" si trova in /usr/share/initramfs-tools/hooks/intel_microcode.)

— nathan
fonte

0

in Ubuntu initrd.imgè compresso in gzip, vorrei preservarlo quando lo modifico. questo è come:

estratto:

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

comprimere:

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

— Jossef Harush
fonte