在亚马逊
Aug 8 outage之后,所有(基于EBS的)AMI都在
many
users停止工作.这是由于AMI所基于的快照中某些扇区的损坏.
但是,亚马逊创建了应修复磁盘问题的恢复快照.这些是按照“vol-xxxxxxxx的恢复快照”的命名.
我从恢复快照创建了一个新的AMI工作正常,但是从这个新的AMI启动的实例不起作用：它们的状态是“正在运行”,但我不能进入机器,也不能访问应该在那里运行的任何Web服务.归结为此(来自系统日志,可通过AWS管理控制台访问)：
EXT3-fs: sda1: couldn't mount because of unsupported optional features (240). EXT2-fs: sda1: couldn't mount because of unsupported optional features (244). Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)
我已经在AWS上的另一台服务器上安装了从该恢复快照创建的卷,但一切看起来都很正常.例如,fsck说：
$sudo fsck -a /dev/xvdg fsck from util-linux-ng 2.17.2 uec-rootfs: clean,53781/524288 files,546065/2097152 blocks
在其中一个AWS论坛讨论中,我发现this advice来自有类似问题的人：
A work around will be to make a volume from the snapshot and attach
it to a running instance,use fsck –force to force the checking of
the filesystem and once cleared,you can make a snapshot and use it
for the AMI.
但我不知道如何在Ubuntu上强制fsck(11.04)：
$sudo fsck --force /dev/xvdg fsck from util-linux-ng 2.17.2 fsck.ext3: invalid option -- 'o'
任何人都知道如何在Ubuntu上强制文件系统检查卷？有关如何启动基于恢复快照的工作实例的任何其他想法？
现在看起来从clean Ubuntu AMI重新开始并重新设置我们的所有服务可能会更快. :-(但当然,如果有任何办法让恢复快照实际工作,我宁愿不这样做.
我试图复制一台机器时遇到了同样的问题.
原文链接：https://www.f2er.com/ubuntu/348879.html结果问题是内核.在创建AMI和我为内核映像选择默认值的实例时都是如此.
为了解决这个问题,我使用与原始实例相同的内核映像重新创建了AMI.
