【トラブル(解決済)】【AWS】EC2が起動しない恐怖。「カーネルパニックを解消せよ」(インスタンスの接続性チェックに失敗しました)

当サイトはAWS上で稼働させていますが、今までも色々とトラブルはありました。
しかし「EC2が起動できない」という事態は初でした。

「どうするんだ、コレ・・・」状態でしたが、なんとか解決できましたのでメモを残しておきます。

「EC2が起動できない」原因は様々かと思います。
必ずしも当内容で対応できるかは分かりませんので、ご了承ください。

発生事象

EC2の調子がおかしかったため、EC2のコンソールから「インスタンスを再起動」を実行。

すると、起動時のチェックで「インスタンスの接続性チェックに失敗しました」となり、EC2が起動できず。
SSHで接続することもできません。

EC2 インスタンスの接続性チェックに失敗しました

発生環境

  • AWS EC2
  • CentOS8系(KUSANAGI利用)

対応方法

原因の絞り込み

AWSコンソールにて、EC2 > 該当のインスタンス > アクション > モニタリングとトラブルシューティング > システムログを取得
にて、起動時のログが確認できます。

すると、下記のようなエラーが発生していました。

[ 3.948588] No filesystem could mount root, tried: 
[ 3.954357] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

「Kernel panic」とあるように、どうやらカーネル(OSの核となるプログラム)が壊れているように見えました。

確かに、先日サーバーのモジュールをアップデートしましたが、何かがダメだったのでしょう。
再起動がかかることで、破損が顕在化したものだと思われます。

修復の流れ

カーネルが壊れているのであれば、カーネルを修復すればOKのはず、です。

しかし、そもそもEC2が起動できないため、自力では復旧できません。

そのため、修復手順をザックリとお伝えすると以下になります。

  1. 破損しているボリュームを、該当のEC2から切り離す(ボリュームをデタッチ)
  2. 別EC2(レスキュー用EC2)から、そのボリュームに接続(ボリュームをアタッチ)
  3. レスキュー用EC2でカーネルを修復
  4. レスキュー用EC2から元EC2にボリュームを戻す
  5. 元EC2を起動

詳細手順

AWS公式に対処法が掲載されておりました。
そちらに従って実施する形になります。

Amazon Web Services, Inc.

本件のポイントを下記に挙げておきます。

カーネルのバージョンを戻さないとダメだった

今回、カーネルのバージョンを戻さないと起動できませんでした。(最新だとうまく起動しなかった?)

カーネルを戻す手順も、AWS公式に掲載されております。

Amazon Web Services, Inc.

カーネルの更新により Amazon Elastic Compute Cloud (Amazon EC2) インスタンスが…

カーネルの過去バージョンがボリュームに残っているので、昔のバージョンで起動するように設定してあげるイメージですね。

破損ボリュームのマウントでエラー

手順に従ってもエラーとなりました。
レスキュー用EC2が破損したEC2の(破損前の)コピーであったため、ボリュームのUUID(固有の識別子)が同じであったことが原因と思われます。

一時的にマウントするのみですので、重複を無視する形で接続します。

# エラーになります
mount /dev/xvdf1 /mnt

#mount: wrong fs type, bad option, bad superblock on /dev/xvdf1,
#       missing codepage or helper program, or other error
#       In some cases useful info is found in syslog - try
#       dmesg | tail or so.

# 重複を無視してマウント
mount -o nouuid /dev/xvdf1 /mnt
クラスメソッド発「やってみた」系技術メディア | DevelopersIO

Amazon EBSマウント時にUUIDの重複エラーが発生した時の解決方法を紹介します。…

EC2が起動しなかった時はどうしようかと思いましたが、1つずつ紐解くことでなんとかなりました。

最悪、1週間前くらいのバックアップはありましたが、記事など更新していたため、できるだけ過去断面に戻りたくはなかったというのが本音です。

どこまでバックアップをとりながら運用するか。
これはコストと手間のバランスですね。

※本件は、当運用レベルからすると許容範囲の内容でした。

※ご回答希望の場合は、ご連絡先も記入ください
"意見が持てる" デジタルコラム
絶賛配信中!

メルマガ詳細はこちら >>>

送信時点で「Privacy Policy」に同意したものとみなします。
広告を含むご案内のメールをお送りする場合があります。
   
         
最後までお読みいただき、ありがとうございました。
以下も、ぜひご活用ください^^
出版物
ITmedia
メルマガ
Site Access Log by HTTP Header

      >情報システムの

      情報システムの"教科書"本を発売中!


      ■ 情シス、システムコンサルタント、システムエンジニアの方へ
      情シスの定石(技術評論社)

      ■ システムエンジニア、情シスの方へ
      システム設計の教科書(技術評論社)

      CTR IMG

      株式会社グロリア ご紹介