Como reembalar initrd.img?

Em originais /boot/initrd.img- kernel_ver binwalk mostra esta estrutura:

De 0 a 22528 bytes, o arquivo CPIO contém apenas o firmware GenuineIntel.bin na hierarquia de pastas específica.
De 22528 bytes, existe o gzip archiwe contém um sistema de arquivos apropriado e esse gzip também é arquivado com o CPIO

Após descompactar e modificar, como posso compactar o initrd.img da mesma maneira (com a mesma hierarquia de pastas)? como esta estrutura original:

Após sugestão do comentário:

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

binwalk :

Essa é uma estrutura completamente diferente.

Eu descobri como fazer exatamente o mesmo initrd.imgarquivo.

A resposta do Bodhi.zazen provavelmente funcionará porque esta é uma solução conhecida:

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

mas a questão era diferente. Essa resposta seria boa se no arquivo cpio houver um sistema de arquivos compactado com gzip, mas nessa situação também houver firmware da Intel na estrutura de pastas específica que desejo manter.

Para manter a mesma hierarquia de pastas, são necessárias três etapas:

1. Faça o arquivo do sistema de arquivos CPIO com a opção -o simples, sem o formato newc criado antes, por exemplo. pasta base:

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

2. Faça o arquivo adequado com o formato newc contendo kernel / x86 / microcode / GenuineIntel.bin :

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

3. Adicione o arquivo do sistema de arquivos gzipped ao new_initrd.img apropriado:

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

Você reembalou com

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

O segundo comando renomeia o initrd, você especifica o initrd a ser usado ao inicializar no grub.

Sugiro que você teste (inicialize) o initrd personalizado antes de movê-lo ou renomeá-lo.

Informações adicionais da discussão nos comentários:

Primeiro, acho que você não está entendendo o papel do cpio / tar. cpio e tar pegam vários arquivos e / ou diretórios e os transformam em um arquivo ou archive.

Segundo, não acho que você entenda o papel da compactação, a compactação simplesmente torna o arquivo resultante menor. Você pode usar qualquer ferramenta que desejar para compactação.

Vejo

https://wiki.ubuntu.com/CustomizeLiveInitrd

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

Terceiro, o kernel do linux usa cipo e não tar.

Vejo

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

Consulte o "Por que cpio em vez de alcatrão?" seção

Por que cpio em vez de alcatrão?

Esta decisão foi tomada em dezembro de 2001. A discussão começou aqui:

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

E gerou um segundo segmento (especificamente no tar vs cpio), começando aqui:

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

A versão resumida rápida e suja (que não substitui a leitura dos threads acima) é:

1) cpio é um padrão. Ele tem décadas (dos dias da AT&T) e já é amplamente usado no Linux (dentro do RPM, discos de driver de dispositivo da Red Hat). Aqui está um artigo do Linux Journal sobre isso em 1996:

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

Não é tão popular quanto o tar, porque as ferramentas de linha de comando tradicionais do cpio exigem argumentos de linha de comando _truly_hideous_. Mas isso não diz nada sobre o formato do arquivo, e existem ferramentas alternativas, como:

 http://freecode.com/projects/afio

2) O formato de arquivo cpio escolhido pelo kernel é mais simples e mais limpo (e, portanto, mais fácil de criar e analisar) do que qualquer um dos (literalmente dezenas de) vários formatos de arquivo tar. O formato completo do arquivo initramfs é explicado em buffer-format.txt, criado em usr / gen_init_cpio.c e extraído em init / initramfs.c. Os três juntos somam menos de 26k de texto legível por humanos.

3) O projeto GNU de padronização no tar é aproximadamente tão relevante quanto a padronização do Windows no zip. O Linux também não faz parte e é livre para tomar suas próprias decisões técnicas.

4) Como este é um formato interno do kernel, poderia facilmente ter sido
algo totalmente novo. O kernel fornece suas próprias ferramentas para criar e extrair esse formato de qualquer maneira. Usar um padrão existente era preferível, mas não essencial.

5) Al Viro tomou a decisão (citação: "o tar é feio como o inferno e não será suportado no lado do kernel"):

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

explicou seu raciocínio:

  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, o mais importante, projetou e implementou o código initramfs.

Recentemente, me deparei com essa mesma pergunta e minha pesquisa na web me levou a esse segmento, então, caso ajude outras pessoas a seguir esses passos, aqui está uma resposta de 2018 a uma pergunta antiga ...

Parece que nos kernels "recentes" o arquivo initrd.img pode conter um arquivo cpio descompactado (ou seja, contendo atualizações de microcódigo) anexado ao arquivo cpio (compactado) que contém a árvore de diretórios initramfs normal.

Isso é discutido brevemente na página Wiki do Debian:
https://wiki.debian.org/initramfs#How_to_inspect_initramfs
, mas um código mais preciso para analisar através desse tipo de arquivo initrd.img pode ser encontrado na splitinitramfs()função dentro do unmkinitramfscomando encontrado no initramfs-tools-corepacote (por exemplo, https://git.launchpad.net/ubuntu/+source/initramfs-tools/tree/unmkinitramfs ).

Eu não tentei reconstruir esse tipo de arquivo initrd.img, mas com base nessa página da Wiki, parece que, para editar os scripts de inicialização do initramfs, não seria necessário descompactar o arquivo GenuineIntel. Em vez disso, você pode preservar o arquivo cpio como está em algum lugar separadamente, descompactar o segundo arquivo compactado, modificar a árvore de diretórios e reconstruir o arquivo cpio compactado, concatenar o arquivo de microcódigo salvo com o recém-gerado.

(O código que originalmente gerou esse arquivo "anexado" encontra-se em /usr/share/initramfs-tools/hooks/intel_microcode.)

no Ubuntu o initrd.imgé compactado no gzip, gostaria de preservar isso quando o editar. é assim:

extrair:

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