¿Cómo reempaquetar initrd.img?

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

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:

Después de la sugerencia del comentario:

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

binwalk :

Esta es una estructura completamente diferente.

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

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.

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

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