我急需帮助！
4 年的旧服务器。Ubuntu
14.04 服务器 i686。Linux
3.13.0-149-generic 是最后一个完美运行的版本。10
天前，我升级到了 3.13.0.151。
服务器在启动时崩溃。
屏幕显示...
Loading Linux 3.13.0-151-generic ...
Loading initial ramdisk ...
1秒后...重新启动。
与 3.13.0-151 恢复模式相同。
与 3.13.0-153 相同（截至今天最新的，正常和恢复模式）。
我如何才能知道，在 3.13.0-149 成功启动后，什么原因导致崩溃？
谢谢！
- - - 之后 - - -
@heynnema 试图通过告诉我如何为initrd.img-*151 构建一个新的 ( update-initramfs -c -k 3.13.0-151-generic) 来帮助我。见下文。这没有用。151 仍然没有使系统启动。我的致命错误是说update-initramfs -c -k 3.13.0-149-generic（唯一有效的内核）。之后，我陷入了困境。没有内核可以启动了！ramdisk 的问题与 151 和 153 相同。
之后，我ubuntu-14.04.5-desktop-i386.iso在卡住的系统上启动了 Live DVD ( )，在另一台计算机上安装了旧的 14.05.5 VM 和 3.13 内核，更新了这些 ( apt-get dist-upgrade)，将结果initrd.img-3.13.0-153-generic（最新内核）复制到卡住的系统（“/boot”），然后它再次启动（使用 153）！这让我大吃一惊，因为我不知道 VMinitrd.img-*可以在真正的硬件上运行！但是我仍然无法从 149 和 151 启动（这是有道理的）。
以上所有操作只是为了让系统恢复运行。问题本身并没有解决！
底线：
update-initramfs使用系统上的数据（文件）来构建initrd.img-*。在我的机器上，这导致无法继续执行“正在加载初始 ramdisk ...”操作。
问题：
使用了哪些文件update-initramfs？
我可以 (?!) 做些什么来再次创建可运行的版本initrd.img-3.13.0-153-generic吗？
只要这个问题不解决，将来构建的initrd-img-*文件几乎肯定也会崩溃！
答案1
再次感谢@heynnema 的想法（感谢！）
lsinitramfsinitrd.img对所有 3 个不起作用的文件 (149、151、153)均不起作用。
root@gan:~# lsinitramfs /boot/initrd.img-3.13.0-153
/boot/initrd.img-3.13.0-153
gzip: /boot/initrd.img-3.13.0-153: not in gzip format
cpio: premature end of archive
那么今天早上这里...
root@gan:~# apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
linux-headers-3.13.0-151 linux-headers-3.13.0-151-generic
linux-image-3.13.0-151-generic linux-image-extra-3.13.0-151-generic
Use 'apt-get autoremove' to remove them.
The following packages will be upgraded:
amd64-microcode
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 26.3 kB of archives.
After this operation, 2,048 B disk space will be freed.
Do you want to continue? [Y/n] y
Get:1 http://xx.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64-microcode i386 3.20180524.1~ubuntu0.14.04.2+really20130710.1 [26.3 kB]
Fetched 26.3 kB in 0s (387 kB/s)
(Reading database ... 132952 files and directories currently installed.)
Preparing to unpack .../amd64-microcode_3.20180524.1~ubuntu0.14.04.2+really20130710.1_i386.deb ...
Unpacking amd64-microcode (3.20180524.1~ubuntu0.14.04.2+really20130710.1) over (3.20180524.1~ubuntu0.14.04.1) ...
Setting up amd64-microcode (3.20180524.1~ubuntu0.14.04.2+really20130710.1) ...
Updating microcode on all online processors...
update-initramfs: deferring update (trigger activated)
Processing triggers for initramfs-tools (0.103ubuntu4.11) ...
update-initramfs: Generating /boot/initrd.img-3.13.0-153-generic
启动再次成功！！！
lsinitramfs现在也一样！
root@gan:~# lsinitramfs /boot/initrd.img-3.13.0-153-generic
/boot/initrd.img-3.13.0-153-generic
.
sbin
sbin/biosdevname
...
还更新了其他initrd.img文件（149 和 151）。
root@gan:/boot# update-initramfs -c -k 3.13.0-151-generic
update-initramfs: Generating /boot/initrd.img-3.13.0-151-generic
root@gan:/boot# update-initramfs -c -k 3.13.0-149-generic
update-initramfs: Generating /boot/initrd.img-3.13.0-149-generic
现在所有 3 个都已被 接受lsinitranfs。
所有 3 个都可用于引导。
因此，问题的根源是amd64-microcode。花了两周的时间才得到修复。
为了测试目的，我initrd.img-3.13.0-153-generic使用手动构建update-initramfs。结果与 构建的结果不完全相同apt-get update，但同样有效。
谢谢大家的帮助！