我们有多台旧的（14 年以上）Tyan S3950 主板服务器，运行 Debian Unstable，带有各种最新内核，例如 6.1.0-3-amd64。
尽管使用的是不稳定发行版，但这是一个非常可靠的设置。然而，在最近的一次更新之后，我们不得不重启几台服务器，两台服务器都没有网络或控制台键盘，也就是说，完全无法使用。
我已经能够在另一台服务器上安装发生故障的服务器硬盘，并比较失败和上次成功启动的 dmesg 日志。失败的启动没有检测到软盘（我告诉过你它们很旧）并且没有加载内核 piix4_smbus 驱动程序。这是一份好的启动 dmesg 日志包含的内容：
...
Floppy drive(s): fd0 is 1.44M
piix4_smbus 0000:00:02.0: SMBus Host Controller at 0x580, revision 0
...
启动失败，没有上述行，随后无法检测和启用网络接口和键盘或任何其他 USB 设备。
值得一提的是，3ware RAID 驱动程序在坏启动中仍能正常加载。因此，某些驱动程序仍在加载。
这个问题可能源于 Debian 正在向合并/usr 系统迁移，但我一直无法确定如何确定。我唯一的线索是，我们在这些故障发生前应用的最后一个 dbus 软件包更新包含一个关于假设系统完全合并/usr 系统的警告“在 dbus 的情况下，当这个假设被打破时，症状特别严重（各种关键系统服务将无法启动”。但是，由于这个警告是指软件包依赖关系更改，而不是任何特定的代码更改，所以我还没有将其报告为 dbus 错误。
此时，我甚至不知道该问什么。我估计启动过程中加载驱动程序的过程没有在正确的地方查找。但我不知道在哪里查找驱动程序，即使我找到了它们，我该如何更改才能告诉系统在正确的地方查找它们？
如果你不知道的话，我现在有点迷茫了。;-)
答案1
经过几天的研究和测试，我发现问题与 debian 切换到合并的 /usr 系统无关。
几个月前，由于软件包冲突，我们从 initramfs-tools 切换到 tiny-initramfs。但是，我们从未真正测试过 tiny-imitramfs，而且它创建的 initfamfs.img 文件缺少缺少的驱动程序，这很可能是我们这边的配置问题。
无论如何，我们最终设法解决了这个问题，方法是使用活动的闪存驱动器启动死机服务器，将死机服务器 raid 安装到 chroot 环境中，将死机服务器切换回 initramfs-tools（软件包冲突现在已消失），然后重建 initramfs.img 文件。debian wiki 中对该过程进行了很好的描述，网址为https://wiki.debian.org/RescueLive