先日サーバーメンテナンス時にちょっとした不具合が発生しEC2の起動ができなくなりました。一瞬気が遠くなったのですが(笑)、原因がわかったので無理やり対処した記録です。
他のメンバーからの報告で、再起動しても、AMIから復旧しようとしても起動しない、というか起動しても接続できないとのことだったので、Management Consoleから System Log を確認すると以下のメッセージが。
*** ファイルシステム検査中にエラー *** シェルに移行します、システムは再起動します。 *** シェルから抜ける時。 Give root password for maintenance (or type Control-D to continue):
エラー発生しているのはrootボリュームではなくデータ専用ボリュームだったのですが、入力待ち状態のため正常起動せず /etc/fstab すら書き換えられない状態だったのです。
ということで、手順をまとめるとこんな感じ。
- 該当インスタンス停止
- rootボリュームを detach（デバイス名をメモ、たぶん /dev/sda1）
- rootボリュームを同じAZ内の他のインスタンスへ attach
- 他のインスタンス、適当な位置に mount
- vi で fstab を編集し不具合のあるボリュームの行をコメントアウト（起動時に mount/fsck 対象としないようにする）
/dev/sda1 / ext3 defaults 1 1 none /dev/pts devpts gid=5,mode=620 0 0 none /dev/shm tmpfs defaults 0 0 none /proc proc defaults 0 0 none /sys sysfs defaults 0 0 /dev/sda3 swap swap defaults 0 0 # /dev/sdf1 /home ext3 defaults 1 1
- rootボリュームを umount
- rootボリュームを detach
- 該当インスタンスに attach（デバイス名に注意）
- インスタンス起動
- 起動できたら不具合のあるボリュームを調査＆修復
ボリュームの不具合は結局スーパーブロックがぶっ飛んでたようで、データそのものは安全でした。よかったよかった。（もしかしてAmazon純正のAMIだったらこんなに苦労しないのかなぁ？）
AWS便利すぎて気が抜けていたのがバレたかのように発生した不具合。再度姿勢を正すきっかけになりました。ありがとうございました…
参考: ＠IT: 壊れたパーティションを修復するには