web-dev-qa-db-ja.com

8月8日の停止後にリカバリスナップショットから有効なAMIを再作成する方法

Amazonの 8月8日の停止 の後、すべての（EBSベースの）AMIは manysers で機能しなくなりました。これは、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つで、私は thisアドバイス を同様の問題を持つ誰かから見つけました：

回避策は、スナップショットからボリュームを作成し、実行中のインスタンスにアタッチし、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のボリュームでファイルシステムチェックを強制する方法を知っている人はいますか？リカバリスナップショットに基づいて動作するインスタンスを起動する方法に関する他のアイデアはありますか？

今のところ、 clean Ubuntu AMI からやり直して、すべてのサービスを再セットアップする方が速いかもしれません。 :-(しかし、もちろん、リカバリスナップショットを実際に機能させる方法がある場合は、そうしない方がよいでしょう。

ubuntuamazon-ec2amazon-amiamazon-web-services
11
Jonik

マシンを複製しようとしたときに、同じ問題に遭遇しました。

問題はカーネルであることが判明しました。 AMIとインスタンスを作成するときに、カーネルイメージにデフォルトを選択しました。

この問題を解決するために、元のインスタンスと同じカーネルイメージを使用してAMIを再作成しました。

14
DCYorke

次のコマンドを試してみてください（--forceではなく-fオプションに注意してください）：Sudo fsck -f /dev/xvdg

お役に立てれば。フレッド

2
fred

AWS特有の奇妙な問題との戦いにこれ以上時間を費やしたくなかったので、公式の buntu AMI （私の場合はAMI-359ea941これは、eu-west-1リージョンにあるUbuntu 11.04の32ビットEBS-backedイメージであり、サーバー設定をそこに再作成しました。

リカバリスナップショットから作成されたボリュームを新しいインスタンスにマウントできるという事実は、再セットアップをはるかに高速にしました。たとえば、私は何かをしましたお気に入り cp -a /mnt/recovery/usr/local /usrの下にあるものすべてを復元するには/usr/local。

したがって、私の場合、リカバリバックアップはデータにアクセスできるため、役に立たないことはありませんでした。ただし、もちろん、スナップショットからAMIを作成し、インシデント全体が発生したことのないように（からのインスタンス）を使用し続けたほうがよいでしょう。 （それを達成する方法を知っている場合は、自由に回答を追加してください！）

0
Jonik