AWSでカーネルパニックを起こした際、問題となるのが手元にサーバーマシンが無いこと。
起動して設定の編集をしようにも手元にマシンが無いため、編集できません。
実際にはコマンドラインツールというものがありますが、
環境を用意している暇もないという事の方が多いはず。
というわけで手っ取り早くカーネルを修復する方法をご紹介します。
現状を把握する
まず、現状の把握。
AWSのマネージメントコンソールからシステムログを確認します。
インスタンスの一覧で起動しないインスタンスをクリックして「Action」
もしくはインスタンスを右クリックして下記のメニューから
「Get System Log」を選択します。
ここで現状把握。エラーをよく確認しましょう。
ちなみにこのシステムログカーネルパニックなどで、起動しない場合
中々反映されず真っ黒い画面のままの事が多いので、根気よく待ちましょう。
例えば出てくるメッセージと言えば
「microcode: CPU0 update to revision 0x710 failed」
とか
「Error 9: Unknown boot failure」
とか
「xc_dom_probe_bzimage_kernel: kernel is not a bzImage」
とか！
とりあずもうこうなったらカーネルがダメな状態です。
スナップショットを取る
念のためバックアップを取りたいところですが、起動すらしてくれないので
サイドメニューの「Snapshots」から「Create Snapshot」を選択してスナップショットを取ります。
別のインスタンスを立てる
既に稼働している別のインスタンスがあればこの項目はスキップしてOKですが、
一つだけのインスタンスで稼働させていた場合は、とりあえずmicroインスタンスでもいいので、
sshでログインできるインスタンスを作成します。
ボリュームのDetach
まずは中途半端な状態で起動しているインスタンスを停止させて下さい。
この時、カーネルパニックを起こしているからかどうなのか不明ですが
やたら停止までに時間がかかります。
次に、サイドメニューの「Volume」から、インスタンスに割り当てられている
ボリュームをデタッチします。インスタンスが起動している場合は
メインのボリュームとなっているものについてはエラー、
マウントされているだけの場合はペンディングとなります。
正常に起動しているインスタンスにマウント
起動できないカーネルとなったボリュームを先程のvolumeの画面上から
正常に起動しているインスタンスにアタッチします。
次に、sshで起動しているボリュームに入り、アタッチしたボリュームを
マウントしてあげます。
マウントの方法については下記URLの2,4,5,6が参考になるかと思います。
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-using-volumes.html
カーネルを修復
マウントができれば起動できないボリュームのboot領域にアクセスできるはずなので
直接カーネルを落としてきて上書きするか、起動しているインスタンスの
boot領域から拝借するかは自由。
これでカーネルを書き換えたら、先程までの流れと同じように
アタッチしたボリュームをデタッチし、もともとのインスタンスに
アタッチして起動すれば、解決するはずです。
ちなみに再度アタッチする場合デバイスIDが自動採番されて
元のデバイスIDと変わってしまわないよう注意してください。
と、いうわけで手っ取り早くAWSで破損したカーネルを修復する方法でした。
他にもいろいろ方法はあるようなんですが、カーネルIDを直すとか
正常に動いていた時にスナップショットに戻すとか
どれを試してもいまいち上手くいかなかったので、この方法を取りました。
なんというか、HDDを引っこ抜いて動くマシンに外付けドライブとして
マウントさせて修復させるような感じですね。
コメント