如何重新打包 initrd.img？

Question

在原有/boot/initrd.img- kernel_ver binwalk显示了这种结构：

从0到22528字节，CPIO 存档仅包含特定文件夹层次结构中的 GenuineIntel.bin 固件。
从22528字节开始，gzip archiwe 包含适当的文件系统，并且这个 gzip 也与 CPIO 一起存档

解压和修改后，如何以相同的方式（具有相同的文件夹层次结构）压缩 initrd.img ？像这样的原始结构：

来自评论的建议后：

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

binwalk ：

这是完全不同的结构。

Answer 1

我想出了如何制作完全相同的initrd.img存档。

Bodhi.zazen 答案可能会起作用，因为这是众所周知的解决方案：

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

但问题是不同的。如果在 cpio 存档中有一个 gzip 文件系统，这个答案会很好，但在这种情况下，我想保留特定文件夹结构中的英特尔固件。

要保持相同的文件夹层次结构，需要三个步骤：

1. 使用简单的 -o 选项制作CPIO文件系统存档，例如之前创建的没有newc格式。基本文件夹：

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

2. 使用包含kernel/x86/microcode/GenuineIntel.bin 的newc格式制作适当的存档：

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

3. 将 gzipped 文件系统存档添加到正确的 new_initrd.img：

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

Answer 2

我最近遇到了同样的问题，我的网络搜索引导我找到了这个帖子，所以如果它可以帮助其他人追随这些脚步，这里是一个老问题的 2018 年答案......

在“最近的”内核中，initrd.img 文件似乎可以包含未压缩的 cpio 存档（即包含微码更新），该存档位于包含正常 initramfs 目录树的（压缩的）cpio 存档之前。

Debian Wiki 页面对此进行了简要讨论：
https://wiki.debian.org/initramfs#How_to_inspect_initramfs
，但用于解析此类 initrd.img 文件的更精确的代码可以在以下命令splitinitramfs()中的函数中找到：包（例如 https://git.launchpad.net/ubuntu/+source/initramfs-tools/tree/unmkinitramfs ）。unmkinitramfsinitramfs-tools-core

我自己没有尝试重建这种 initrd.img 文件，但根据该 Wiki 页面，似乎要编辑 initramfs 启动脚本，人们根本不想解压 GenuineIntel 存档。相反，您可以单独保留该 cpio 存档，然后解压第二个（压缩的）存档，修改目录树，并重建压缩的 cpio 存档，然后将保存的微代码存档与新生成的微代码存档连接起来。

（最初生成此“前置”存档的代码可在 中找到/usr/share/initramfs-tools/hooks/intel_microcode。）

Answer 3

你重新打包

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

第二个命令重命名 initrd，您指定在 grub 中引导时要使用的 initrd。

我建议您在移动或重命名自定义 initrd 之前测试（引导）它。

评论中讨论的附加信息：

首先我认为您没有理解cpio / tar的作用。cpio 和 tar 都获取许多文件和/或目录并将它们放入一个文件或存档中。

其次，我认为您不了解压缩的作用，压缩只是使生成的存档更小。您可以使用任何您想要的工具进行压缩。

看

https://wiki.ubuntu.com/CustomizeLiveInitrd

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

第三，Linux 内核使用 cipo 而不是 tar。

看

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

请参阅“为什么使用 cpio 而不是 tar？” 部分

为什么是 cpio 而不是 tar？

这个决定是在 2001 年 12 月做出的​​。讨论是从这里开始的：

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

并产生了第二个线程（特别是在 tar 与 cpio 上），从这里开始：

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

快速而肮脏的摘要版本（不能替代阅读上述线程）是：

1）cpio是一个标准。它已经有几十年的历史了（从 AT&T 时代开始），并且已经在 Linux 上广泛使用（在 RPM、Red Hat 的设备驱动程序磁盘中）。这是 1996 年关于它的 Linux Journal 文章：

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

它不像 tar 那样流行，因为传统的 cpio 命令行工具需要 _truly_hideous_ 命令行参数。但这对存档格式没有任何影响，并且还有替代工具，例如：

 http://freecode.com/projects/afio

2) 内核选择的 cpio 归档格式比任何（实际上是几十种）各种 tar 归档格式更简单、更干净（因此更容易创建和解析）。完整的 initramfs 归档格式在 buffer-format.txt 中进行了解释，在 usr/gen_init_cpio.c 中创建，并在 init/initramfs.c 中提取。这三者加起来总共不到 26k 人类可读的文本。

3) GNU 项目标准化 tar 的相关性与 Windows 标准化 zip 的相关性大致相同。Linux 不属于其中任何一个，并且可以自由地做出自己的技术决策。

4) 由于这是内核内部格式，因此它很可能是
全新的。内核提供了自己的工具来创建和提取这种格式。使用现有标准是更好的选择，但不是必需的。

5) Al Viro 做出了决定（引用：“tar 非常丑陋，并且不会在内核端得到支持”）：

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

解释了他的推理：

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

最重要的是，设计并实现了 initramfs 代码。