主页 / server / 问题 / 853951
Accepted
Chloe
Asked: 2017-06-05 16:18:41 +0800 CST

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

  • 772

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

Linux 版本 2.6.32-642.11.1.el6.x86_64 ([email protected]) (gcc 版本 4.4.7 20120313 (Red Hat 4.4.7-17) (GCC)) #1 SMP Fri Nov 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）上挂载根 fs

/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)。

中央操作系统 6

centos

6 个回答

  1. Best Answer

    我通过转到图像 > 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 missing initrd path after kernel update

    我注意到在我跑之后yum update我现在有2个条目grub.confwithout initrd. 跑步# yum reinstall kernel.x86_64可以解决这个问题。

    • 6

  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. 启动失败的实例....实例确实启动并且我能够登录。

    我希望这有帮助！

    • 2

  3. 我对 CentOS 实例也有类似的问题。这篇 AWS 支持文章提供了很好的概述。以下是我并设法解决我的问题的方法：

    • 关闭原始 EC2 实例，然后分离/dev/sda1磁盘
    • 启动一个新的临时 EC2 实例，并将磁盘附加/dev/sdp到新的 EC2 实例
    • SSH 进入新的 EC2 实例并挂载/dev/sdp到/data

    然后我想回到以前的内核。CentOS wiki上的说明很有帮助：

    • 列出所有 Grub 条目grep "^menuentry" /data/boot/grub2/grub.cfg | cut -d "'" -f2
    • 从顶部选择第二个，就我而言，这是CentOS Linux (3.10.0-957.12.1.el7.x86_64) 7 (Core)
    • 配置引导默认值grub2-set-default --boot-directory /data/boot/ 'CentOS Linux (3.10.0-957.12.1.el7.x86_64) 7 (Core)'

    然后关闭新的 EC2 实例，分离卷，将其附加回原始实例 (to /dev/sda1) 并启动初始实例。

    • 1

  4. 我也是！

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

    然而，有些东西没有写入/boot/initrd....newver.... 可能与最新内核条目相关的文件，因为它完全grub2.cfg丢失了它的initrd=/....行。

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

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

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

    • 1

  5. 在我看来，您的内核已升级为不再理解您的根文件系统。您最好的选择是创建一个新节点并将旧节点的 EBS 卷挂载为非根/非引导设备，然后传输关键数据。

    • 0

  6. 我遇到了类似的问题，事实证明，AWS EC2 默认启动实例与创建 AMI 不同：硬件虚拟化 (HVM) 是第一种情况的默认选择，但半虚拟化 (PV) 是映像创建的默认选择。

    当我试图通过快照其 EBS 卷并创建一个新的 AMI 来在可用区之间移动 EC2 实例时，我偶然发现了这一点，而这种设置差异（我也没有注意到）浪费了我一个小时。

    tl;dr：从自定义 AMI 启动时只需选择 HVM，您的实例应该可以正常启动。

    • 0

相关问题