在原始 /boot/initrd.img 上-内核版本 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：
这是完全不同的结构。
答案1
我知道如何制作完全相同的initrd.img档案。
Bodhi.zazen 的答案可能会有效，因为这是众所周知的解决方案：
find . | cpio --quiet --dereference -o -H newc | lzma -7 > ../cusotm.initrd.lz
但问题不同。如果在 cpio 存档中有一个 gzip 压缩的文件系统，这个答案会很好，但在这种情况下，特定文件夹结构中还有我想保留的英特尔固件。
要保持相同的文件夹层次结构，需要三个步骤：
制作消费者知识产权组织文件系统存档带有简单的 -o 选项，无需新之前创建的格式，例如基础文件夹：
find . | cpio -o | gzip -9 > ../base/file_system.gz使用以下方法进行正确归档新格式包含内核/x86/微码/GenuineIntel.bin：
find kernel/ | cpio -o -H newc > new_initrd.img将 gzip 压缩的文件系统存档添加到正确的 new_initrd.img：
find base/ | cpio -o >> new_initrd.img
答案2
我最近遇到了同样的问题，我的网络搜索让我找到了这个帖子，所以如果它能帮助其他追随这些脚步的人，这里是 2018 年对一个老问题的回答......
在“最近的”内核中，initrd.img 文件似乎可以包含一个未压缩的 cpio 档案（即包含微码更新），该档案位于包含正常 initramfs 目录树的（压缩）cpio 档案的前面。
Debian Wiki 页面对此进行了简要讨论：
https://wiki.debian.org/initramfs#How_to_inspect_initramfs
但是，可以在包中的命令splitinitramfs()内的函数 中找到用于解析此类 initrd.img 文件的更精确的代码（例如
unmkinitramfsinitramfs-tools-corehttps://git.launchpad.net/ubuntu/+source/initramfs-tools/tree/unmkinitramfs
）。
我自己还没有尝试重建这种 initrd.img 文件，但根据该 Wiki 页面，似乎要编辑 initramfs 启动脚本，根本不需要解压 GenuineIntel 存档。相反，您可以直接将该 cpio 存档原样保存在某个单独的位置，然后解压第二个（压缩）存档，修改目录树，重建压缩的 cpio 存档，然后将保存的微码存档与新生成的微码存档连接起来。
（最初生成此“前置”档案的代码可在 中找到/usr/share/initramfs-tools/hooks/intel_microcode。）
答案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/指南
第三，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/afio2) 内核选择的 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 代码。
答案4
在 Ubuntu 中，它initrd.img是用 gzip 压缩的，我想在编辑它时保留它。方法如下：
提炼：
zcat /boot/initrd.img-3.19.0-80-generic | cpio --extract
压缩：
find . 2>/dev/null | cpio --quiet --dereference -o -H newc | gzip -9 > /boot/initrd.img-3.19.0-80-generic