☰

Amazon EC2 实例无法启动：内核恐慌 - 未同步：VFS：无法在未知块（0,0）上挂载根 fs

tag-icon • tag-icon centos amazon-ec2 centos6 boot amazon-ebs
Amazon EC2 实例无法启动：内核恐慌 - 未同步：VFS：无法在未知块（0,0）上挂载根 fs

我的实例运行了好几年，突然在 6 月 1 日停止响应。我尝试重新启动它，但它无法启动。它在系统日志中显示错误：https://pastebin.com/rSxr1kLs

Linux 版本 2.6.32-642.11.1.el6.x86_64 ([电子邮件保护]) (gcc 版本 4.4.7 20120313 (Red Hat 4.4.7-17) (GCC) ) #1 SMP 星期五 11 月 18 日 19:25:05 UTC 2016
内核命令行：root=/dev/xvde ro LANG=en_US.UTF-8 KEYTABLE=us
VFS: 无法打开根设备“xvde”或未知块 (0,0)
请附加正确的“root=”启动选项；以下是可用的分区：
内核崩溃 - 未同步：VFS：无法在未知块 (0,0) 上挂载根文件系统

/dev/sda1我尝试分离 EBS 卷并根据文档重新连接它：https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstances.html#FilesystemKernel

但是，它给出了一个错误Error attaching volume: Invalid value '/dev/sda1' for unixDevice. Attachment point /dev/sda1 is already in use，我无法连接它。我重新连接它，/dev/sda但它仍然无法启动，系统日志中仍然显示错误。

我能够在完全相同的可用区中启动一个新实例，并将我的 EBS 卷附加为/dev/sdf。它在实例中显示为/dev/xvdj。我将其挂载为mount /dev/xvdj /xvdj。我可以看到grub.conf文件：

[root@ip-172-31-4-249 grub]# cat /xvdj/boot/grub/grub.conf
default=0
timeout=1

title CentOS (2.6.32-642.11.1.el6.x86_64)
        root (hd0)
        kernel /boot/vmlinuz-2.6.32-642.11.1.el6.x86_64 root=/dev/xvde ro crashkernel=auto LANG=en_US.UTF-8 KEYTABLE=us
title CentOS (2.6.32-504.30.3.el6.x86_64)
        root (hd0)
        kernel /boot/vmlinuz-2.6.32-504.30.3.el6.x86_64 root=/dev/xvde ro crashkernel=auto LANG=en_US.UTF-8 KEYTABLE=us
        initrd /boot/initramfs-2.6.32-504.30.3.el6.x86_64.img
title CentOS (2.6.32-504.3.3.el6.x86_64)
        root (hd0)
        kernel /boot/vmlinuz-2.6.32-504.3.3.el6.x86_64 root=/dev/xvde ro crashkernel=auto LANG=en_US.UTF-8 KEYTABLE=us
        initrd /boot/initramfs-2.6.32-504.3.3.el6.x86_64.img
title CentOS (2.6.32-504.el6.x86_64)
        root (hd0)
        kernel /boot/vmlinuz-2.6.32-504.el6.x86_64 root=/dev/xvde ro crashkernel=auto LANG=en_US.UTF-8 KEYTABLE=us
        initrd /boot/initramfs-2.6.32-504.el6.x86_64.img
title CentOS (2.6.32-431.29.2.el6.x86_64)
        root (hd0)
        kernel /boot/vmlinuz-2.6.32-431.29.2.el6.x86_64 root=/dev/xvde ro crashkernel=auto LANG=en_US.UTF-8 KEYTABLE=us
        initrd /boot/initramfs-2.6.32-431.29.2.el6.x86_64.img
title CentOS (2.6.32-431.23.3.el6.x86_64)
        root (hd0)
        kernel /boot/vmlinuz-2.6.32-431.23.3.el6.x86_64 root=/dev/xvde ro crashkernel=auto LANG=en_US.UTF-8 KEYTABLE=us
        initrd /boot/initramfs-2.6.32-431.23.3.el6.x86_64.img

这与grub.conf正在运行的实例进行比较：

[root@ip-172-31-4-249 grub]# cat /boot/grub/grub.conf
default=0
timeout=1

title CentOS-6-x86_64-20130527-03 2.6.32-358.6.2.el6.x86_64
        root (hd0)
        kernel /boot/vmlinuz-2.6.32-358.6.2.el6.x86_64 root=/dev/xvde ro
        initrd /boot/initramfs-2.6.32-358.6.2.el6.x86_64.img

initrd第一个选项中没有线有关系吗？

我尝试使用 将 EBS 卷安装到新实例/dev/sda，但它仍然无法启动并出现相同的错误Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)。

CentOS 6

答案1

我通过转到映像 > AMI > 私有映像 > 选择启动实例的映像 > 启动来创建了一个新实例。我在完全相同的可用区启动，而不仅仅是美国或地区，而且 2a、2b、2c 也必须匹配。我停止了新实例。我断开了 EBS 卷与旧实例的连接。我将 EBS 卷重新连接到新实例/dev/sdf。我启动了新实例。EBS 卷在实例内部显示为，因此/dev/xvdj我用它挂载了它mkdir /xvdj; mount /dev/xvdj /xvdj。我编辑/xvdj/boot/grub/grub.conf并更改default=0为default=1。我保存了文件，停止了新实例，将 EBS 卷重新连接到旧实例，然后它启动了。我yum update在旧实例中运行并反复检查/boot/grub/grub.conf它是否会重新启动。

我还发现了有关 CentOS 内核更新的内容：内核更新后 grub.conf 缺少 initrd 路径

我注意到跑步后yum update我2条目中grub.conf没有initrd。运行# yum reinstall kernel.x86_64可修复该问题。

答案2

我多次遇到过同样的问题，不得不通过从 EBS 快照备份中恢复实例来解决它。今天我遇到了同样的问题，并决定在不从备份中恢复的情况下解决它。我做了以下事情：

  1. 从故障实例 /dev/sda1 中分离根卷。
  2. 将卷附加到工作实例并安装该卷（例如mount /dev/xvdh /xvdhmount）
  3. 备份启动文件夹：mv /xvdhmount/boot /xvdhmount/boot-backup
  4. 从具有相同版本操作系统（我的情况是 RHEL 7.4）的工作实例通过 SCP 或 WinScp 将 /boot 文件夹的全部内容复制到 /xvdhmount/ 中。
  5. 将卷从工作实例中分离并重新附加到故障实例。
  6. 启动失败的实例....实例确实启动了并且我能够登录。

我希望这有帮助！

答案3

我也是！

根本原因是工作中断yum upgrade，一名正在做这项工作的初级职员重新连接，并跑去yum-complete-transactions完成所有工作。

然而，某些内容并未写入文件，/boot/initrd....newver.... 这可能与最新的内核条目完全grub2.cfg丢失其initrd=/....行有关。

快速修复方法是将启动磁盘卷重新连接到另一个实例，挂载它，然后进行编辑/mountpoint/etc/grub2.cfg，以便该实例启动旧版本的内核。然后重新断开连接并重新连接到/dev/sda1原始实例。

注意：最近很难将 centos 启动卷附加到不同的 centos 机器，因为 UUID 在根卷上是相同的。解决方法是使用不同的操作系统作为临时机器，例如 Debian 用于 CentOS 磁盘修复。

再次进入后，运行yum reinstall kernel*重复缺失的步骤，完成后再次重新启动以确保这次正确重新启动并进入最新的内核。

答案4

在我看来，你的内核已经升级，以至于它不再理解你的根文件系统。最好的办法是创建一个新节点并从旧节点安装 EBS 卷作为非 root / 非 boot 用户设备并传输关键数据。

相关内容