¿Cómo reempaquetar initrd.img?


9

En /boot/initrd.img- kernel_ver original binwalkmuestra esta estructura:

ingrese la descripción de la imagen aquí

De 0 a 22528 bytes, el archivo CPIO contiene solo firmware GenuineIntel.bin en una jerarquía de carpetas específica.
Desde 22528 bytes hay un archivo gzip que contiene el sistema de archivos apropiado y este archivo gzip también se archiva con CPIO

Después de desempacar y modificar, ¿cómo puedo comprimir initrd.img de la misma manera (con la misma jerarquía de carpetas)? como esta estructura original:

ingrese la descripción de la imagen aquí

Después de la sugerencia del comentario:

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

binwalk :

ingrese la descripción de la imagen aquí

Esta es una estructura completamente diferente.


Extrae initrd.img en un directorio de trabajo. Agregue su firmware GenuineIntel.bin en la jerarquía de carpetas específica al directorio de trabajo. Luego rehace el archivo con find . | cpio --quiet --dereference -o -H newc | lzma -7 > ../cusotm.initrd.lzSi ese procedimiento no funciona, aclare qué comandos ejecutó y qué no funciona.
Panther

Su edición, con una imagen, agrega poco a nada de mi comprensión de su problema. Debe extraer la imagen, agregar su código, con la estructura de archivos adecuada y la ubicación del firmware GenuineIntel.bin y volver a empaquetarlo en un nuevo .img.
Panther

@ bodhi.zazen como dije, esto hizo un archivo diferente ...
EdiD

@ bodhi.zazen ¿finalmente entiendes lo que te estoy preguntando?
EdiD

1
Parece que el archivo initramfs es una concatenación de archivos CPIO. Cada archivo CPIO se puede comprimir (con gzip, xz, etc.) o sin comprimir. Su archivo de entrada comienza con uno sin comprimir en el desplazamiento 0, luego continúa con uno comprimido en el desplazamiento 22528. Desafortunadamente, no conozco una herramienta estándar que pueda extraer una concatenación de archivos CPIO tal vez comprimidos.
pts

Respuestas:


4

Descubrí cómo hacer exactamente el mismo initrd.imgarchivo.

La respuesta de Bodhi.zazen probablemente funcionará porque esta es una solución comúnmente conocida:

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

Pero la pregunta era diferente. Esta respuesta sería buena si en el archivo cpio hay un sistema de archivos comprimido pero en esta situación también hay firmware Intel en la estructura de carpetas específica que quiero mantener.

Para mantener la misma jerarquía de carpetas, se necesitan tres pasos:

  1. Haga el archivo del sistema de archivos CPIO con la opción -o simple sin formato newc creado antes, por ejemplo. carpeta base:

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

  2. Haga un archivo apropiado con el formato newc que contiene kernel / x86 / microcode / GenuineIntel.bin :

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

  3. Agregue el archivo del sistema de archivos comprimido al new_initrd.img apropiado:

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


1
¡Excelente! ¡Gracias! +10! Pero, ¿cómo desempaquetar el initrd original?
rth

Además, su solución crea una estructura un poco diferente. Obtuve la misma tructura en binwalk cuando hice el paso (2) primero y luegofind . | cpio -o | gzip -9 >> new_initrd.img
rth

@EdiD, ¿cómo desempaqueta el initrd original?
ImranRazaKhan

1
@ImranRazaKhan necesita cuatro pasos: cpio -id < initrd.img-kernel_ver; dd if=initrd.img-4.4.0-22-generic of=image.gz bs=22528 skip=1-coincide con su nombre de archivo initrd.img y el tamaño del bloque; gunzip image.gz; cpio -i < image
EdiD

3

Reenvasas con

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

El segundo comando cambia el nombre del initrd, usted especifica el initrd para usar al arrancar en grub.

Le sugiero que pruebe (arranque) el initrd personalizado antes de moverlo o renombrarlo.

Información adicional de la discusión en los comentarios:

Primero, no creo que entiendas el papel de cpio / tar. tanto cpio como tar toman una cantidad de archivos y / o directorios y los convierten en un archivo o archivo.

En segundo lugar, no creo que comprenda el papel de la compresión, la compresión simplemente hace que el archivo resultante sea más pequeño. Puede usar cualquier herramienta que desee para la compresión.

Ver

https://wiki.ubuntu.com/CustomizeLiveInitrd

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

Tercero, el kernel de Linux usa cipo en lugar de tar.

Ver

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

Vea "¿Por qué cpio en lugar de alquitrán?" sección

¿Por qué cpio en lugar de alquitrán?

Esta decisión se tomó en diciembre de 2001. La discusión comenzó aquí:

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

Y generó un segundo hilo (específicamente en tar vs cpio), comenzando aquí:

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

La versión resumida rápida y sucia (que no sustituye la lectura de los hilos anteriores) es:

1) cpio es un estándar. Tiene décadas de antigüedad (desde los días de AT&T) y ya se usa ampliamente en Linux (dentro de RPM, los discos de controladores de dispositivos de Red Hat). Aquí hay un artículo de Linux Journal al respecto de 1996:

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

No es tan popular como el tar porque las herramientas tradicionales de línea de comandos de cpio requieren argumentos de línea de comandos realmente verdaderos. Pero eso no dice nada sobre el formato de archivo, y hay herramientas alternativas, como:

 http://freecode.com/projects/afio

2) El formato de archivo cpio elegido por el núcleo es más simple y limpio (y, por lo tanto, más fácil de crear y analizar) que cualquiera de los (literalmente docenas de) varios formatos de archivo tar. El formato de archivo initramfs completo se explica en buffer-format.txt, creado en usr / gen_init_cpio.c y extraído en init / initramfs.c. Los tres juntos suman menos de 26k de textos legibles por humanos.

3) La estandarización del proyecto GNU en tar es aproximadamente tan relevante como la estandarización de Windows en zip. Linux tampoco forma parte y es libre de tomar sus propias decisiones técnicas.

4) Dado que este es un formato interno del núcleo, fácilmente podría haber sido
algo completamente nuevo. El núcleo proporciona sus propias herramientas para crear y extraer este formato de todos modos. Usar un estándar existente era preferible, pero no esencial.

5) Al Viro tomó la decisión (cita: "el alquitrán es feo como el infierno y no será compatible con el núcleo"):

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

explicó su razonamiento:

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

y, lo más importante, diseñó e implementó el código initramfs.


Esto no preservará la estructura de la carpeta. Quiero la misma estructura que initrd.img original. Significado -> GenuineIntel.bin no comprimido solo archivado con cpio en la raíz en la carpeta kernel / x86 / microcode y ¿por qué lzma mientras estoy hablando de gzip?
EdiD

lzma da un archivo más pequeño. use gzip si lo desea. No estoy seguro de por qué le preocupa la compresión o no, debería funcionar bien con la compresión y dar como resultado una imagen más pequeña en el disco. No estoy realmente seguro de lo que está tratando de lograr con lo que publicó.
Panther

Quiero saber cómo se hizo originalmente. Probablemente el firmware de Intel no esté comprimido debido a una accesibilidad más rápida.
EdiD

casi seguro que estaba comprimido, puedes consultar el archivo. La compresión se usa de forma predeterminada, ya que no afecta notablemente el rendimiento.
Panther

No hay nada en el manual de cpio sobre compresión. Compruebe respuesta aceptada: superuser.com/questions/343915/...
edid

3

Recientemente me encontré con esta misma pregunta y mi búsqueda en la web me llevó a este hilo, por lo que en caso de que ayude a otros a seguir esos pasos, aquí hay una respuesta de 2018 a una pregunta anterior ...

Parece que en los núcleos "recientes" el archivo initrd.img puede contener un archivo cpio sin comprimir (es decir, que contiene actualizaciones de microcódigo) antepuesto al archivo cpio (comprimido) que contiene el árbol de directorios initramfs normal.

Esto se trata brevemente en la página Wiki de Debian:
https://wiki.debian.org/initramfs#How_to_inspect_initramfs
, pero se puede encontrar un código más preciso para analizar este tipo de archivo initrd.img en la splitinitramfs()función dentro del unmkinitramfscomando que se encuentra en el comando initramfs-tools-corepaquete (por ejemplo, https://git.launchpad.net/ubuntu/+source/initramfs-tools/tree/unmkinitramfs ).

No he intentado reconstruir este tipo de archivo initrd.img, pero según esa página Wiki parece que para editar los scripts de arranque initramfs, uno no querría descomprimir el archivo GenuineIntel. En su lugar, puede conservar ese archivo cpio como está en algún lugar por separado, luego desempaquetar el segundo archivo (comprimido), modificar el árbol de directorios y reconstruir el archivo cpio comprimido, luego concatenar el archivo de microcódigo guardado con el archivo recién generado.

(El código que originalmente generó este archivo "antepuesto" se encuentra en /usr/share/initramfs-tools/hooks/intel_microcode).


0

en Ubuntu el initrd.imgestá comprimido en gzip, me gustaría preservar esto cuando lo edite. así es como:

extraer:

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

comprimir:

find . 2>/dev/null | cpio --quiet --dereference -o -H newc | gzip -9 > /boot/initrd.img-3.19.0-80-generic
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.