先日、サーバーメンテナンス時に細かな不具合が発生し、EC2の起動ができなくなったのですが、原因がわかり、少し強引にですが対処した際の記録になります。

他のメンバーからの報告で、再起動しても、AMIから復旧しようとしても起動しない、さらに起動しても接続できないとのことだったので、Management Consoleから System Log を確認すると以下のメッセージが出ていました。

*** ファイルシステム検査中にエラー
*** シェルに移行します、システムは再起動します。
*** シェルから抜ける時。
Give root password for maintenance
(or type Control-D to continue):

エラー発生しているのはrootボリュームではなくデータ専用ボリュームだったのですが、入力待ち状態のため正常起動せず /etc/fstab も書き換えられない状態でした。そこで、手順を下記にまとめてみました。

  1. 該当インスタンス停止
  2. rootボリュームを detach（デバイス名をメモ、/dev/sda1だと思います。）
  3. rootボリュームを同じAZ内の他のインスタンスへ attach
  4. 他のインスタンス、適当な位置に mount
  5. 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
  6. rootボリュームを umount
  7. rootボリュームを detach
  8. 該当インスタンスに attach（デバイス名に注意）
  9. インスタンス起動
  10. 起動できたら不具合のあるボリュームを調査し修復

ボリュームの不具合は結局スーパーブロックが飛んでいたようで、データそのものは安全でした。
（もし、Amazon純正のAMIを利用していたら、こんなに苦労しないのでしょうか。）
AWSが便利過ぎて気が抜けていたのが見透かされていたかのように発生した不具合でした。

今回のことで、再度姿勢を正すきっかけになりました。ありがとうございました。

こちらの記事はなかの人（klog）監修のもと掲載しています。
元記事は、こちら