Amazonの8月8日の停止後、すべての（EBSベースの）AMIが多くの ユーザーに対して機能しなくなりました。これは、AMIのベースとなっているスナップショットの一部のセクターが破損しているためです。
ただし、Amazonはディスクの問題を修正する必要があるリカバリスナップショットを作成しました。これらは、「vol-xxxxxxxxの回復スナップショット」の行に沿って名前が付けられています。
回復スナップショットから新しいAMIを作成しましたが、正常に機能しましたが、この新しいAMIから起動されたインスタンスは機能しません。それらの状態は「実行中」ですが、マシンにsshすることも、そこで実行される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フォーラムのディスカッションの1つで、同様の問題を抱えている人からのこのアドバイスを見つけました。
回避策は、スナップショットからボリュームを作成し、実行中のインスタンスにアタッチし、fsck --forceを使用してファイルシステムのチェックを強制し、クリアしたら、スナップショットを作成してAMIに使用できます。
しかし、Ubuntu（11.04）でfsckを強制する方法はわかりません。
$ sudo fsck --force /dev/xvdg
fsck from util-linux-ng 2.17.2
fsck.ext3: invalid option -- 'o'
Ubuntuのボリュームでファイルシステムチェックを強制する方法は誰でも知っていますか？回復スナップショットに基づいた作業インスタンスを起動する方法に関する他のアイデアはありますか？
現時点では、クリーンなUbuntu AMIからやり直して、すべてのサービスを再セットアップする方が速いかもしれません。:-(ただし、リカバリスナップショットを実際に機能させる方法がある場合は、もちろんそれを行わない方がよいでしょう。