我一直在构建自己的内核（4.19.37）并且在构建（make）或安装（make install_modules+ make install）期间没有任何问题。在我执行之前，一切似乎都很好grub2-mkconfig -o /boot/grub2/grub.cfg。执行此命令时，grub 会在其中找到我现有的和新的vmlinuz-*内核/boot/以及它们对应的initramfs-*.img. 但是，此时系统无限期挂起（> 几个小时）。 Ctrl+C似乎没有停止它，我必须重新启动。我已经研究了这个问题，我发现可能是一个问题是探测可引导操作系统的删除磁盘，我已经通过删除它们和添加GRUB_DISABLE_OS_PROBER=true到/etc/default/grubper this SE post来消除它们。两者都没有帮助。
重新启动后，我最终进入grub>命令行，大概是因为grub2-mkconfig从未完成并损坏了 grub 配置文件。在这里，我可以毫无问题地加载新旧内核以及 initramfs，但是当我执行引导时，我得到内核恐慌：
end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
自然地，我的假设是initramfs-4.19.37.img我的构建过程产生了一些问题。作为一个实验，我测试了我是否可以加载新内核，但使用旧的 initramfs (4.19.10)，它确实可以启动到emergency mode. 然而，我不能用新的 initramfs 做相反的旧内核。所以我的新 initramfs 图像有些可疑。
变得更聪明了，我的最后一个实验是使用mount. 它们都成功安装且没有错误，并且似乎具有相同的文件结构。我还比较了内核版本的新旧.config文件，差异很小。
其他一些注释/观察：
- 在上图中，您可以看到
List of all partions:没有产生任何内容，所以我想知道文件系统类型是否存在问题？我的硬盘是xfs用什么文件系统的initramfs？CPIO？ - 在
grub>命令行中，ls /生成我期望在/boot. 它包含所有我的vmlinuz-*和initramfs-*.img文件 - 我的文件系统是
xfs - 我尝试了各种其他内核版本，结果相同
- 我有两次成功的构建和安装，一次是现有的内核（4.19.10），这是一次升级，第二次是使用具有
low-latency抢占模式的相同内核。我一生都无法弄清楚我当时做了什么不同的事情。
所以最后的问题是——initramfs这些构建的形式有什么问题？我还能做些什么来验证它的完整性？在为文件系统.config构建内核时，我应该做些什么改变？xfs
免责声明：所以这实际上是 [this question][3] 的延续，但我稍微简化了问题。那里的一些背景信息可能是相关的。