启动失败并显示“正在加载初始 ramdisk ...”

启动失败并显示“正在加载初始 ramdisk ...”

我急需帮助!

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,但同样有效。

谢谢大家的帮助!

相关内容