![Amazon EC2 实例无法启动:内核恐慌 - 未同步:VFS:无法在未知块(0,0)上挂载根 fs](https://linux22.com/image/705348/Amazon%20EC2%20%E5%AE%9E%E4%BE%8B%E6%97%A0%E6%B3%95%E5%90%AF%E5%8A%A8%EF%BC%9A%E5%86%85%E6%A0%B8%E6%81%90%E6%85%8C%20-%20%E6%9C%AA%E5%90%8C%E6%AD%A5%EF%BC%9AVFS%EF%BC%9A%E6%97%A0%E6%B3%95%E5%9C%A8%E6%9C%AA%E7%9F%A5%E5%9D%97%EF%BC%880%2C0%EF%BC%89%E4%B8%8A%E6%8C%82%E8%BD%BD%E6%A0%B9%20fs.png)
我的实例运行了好几年,突然在 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 快照备份中恢复实例来解决它。今天我遇到了同样的问题,并决定在不从备份中恢复的情况下解决它。我做了以下事情:
- 从故障实例 /dev/sda1 中分离根卷。
- 将卷附加到工作实例并安装该卷(例如
mount /dev/xvdh /xvdhmount
) - 备份启动文件夹:
mv /xvdhmount/boot /xvdhmount/boot-backup
- 从具有相同版本操作系统(我的情况是 RHEL 7.4)的工作实例通过 SCP 或 WinScp 将 /boot 文件夹的全部内容复制到 /xvdhmount/ 中。
- 将卷从工作实例中分离并重新附加到故障实例。
- 启动失败的实例....实例确实启动了并且我能够登录。
我希望这有帮助!
答案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 用户设备并传输关键数据。