GCEがKernel Panic で起動しないときの対処

By /

症状

  • GCEに対して再起動を実施したら起動してない
  • シリアルポートログを確認すると「Kernel Panic」で停止している
  • Kernel panic – not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

環境

  • Ubuntu 22.04 ( upgradeで来ている）
  • e2-micro (一番小さいやつ）
  • ストレージサイズ 10G (一番小さいやつ）

原因

結果的には以下が原因となっていた

  • Kernel Update の際にディスクの容量不足？でUpdate が正常に行えず、かつロールバックも出来ない状態になっていた
  • その際に、ディスク装置に問題が発生しておりSuperBlockか何処かがおかしい状態になっている（通常の mount が出来ない状態）

対処

GCEなので対処の方法は色々取れるのは助かりました。結果として実施した内容を以下に整理しておきます。原因は別でも似たような症状になった場合には対処できることもあるかもしれません。

  1. ストレージのスナップショットから「ディスクを作成」する
    • 今回は日々スナップショットをスケジュールで実行していたので昨日のスナップショットを利用した（大切、1世代でも取得しておくことをおすすめ）
    • 復元するリージョン・ゾーンと同じ場所に作る
    • サイズをこの段階で20Gに変更しておく（サイズはGCEの場合にはオンラインでも変更可能）
    • 名前は適当に
  2. 新規に同じリージョン・ゾーンでインスタンス①を作成する
    • 復旧の一時的なものなのでマシンスペックは大きめにしておくほうが良い（特にメモリは4Gとかはある方が無難、一時的なのでそれほど費用はかからない想定）
      先程作成した「ディスク」をセカンドディスクとして接続しておく
    • ネットワークなどの通信設定は不要（ディフォルトで作成して問題ない）
    • OSは故障したものと同じOSのバージョンのイメージ（今回はUbuntu22.04 min LTS）を利用して作成する
  3. インスタンス①を起動したらディスクを修復
    • fdisk -l でストレージを確認（/dev/sdb）
    • parted -l で GPTエラーが出ていたら修復する
    • ディスクサイズを大きくしているので以下で拡張をする
      • growpart /dev/sdb 1 を実施してパーティションを拡張（※sdb1がデータが入っている本体のパーティションの場合）
      • resize2fs /dev/sdb1 を実施（ファイルシステムを拡張）
    • ディスクを修復 e2fsck -f /dev/sdb1
  4. ディスクをマウントしてChrootを実施
    • mkdir /data_disk
    • mount -o nouuid /dev/sdb1 /data_disk
    • mount –bind /dev /data_disk/dev/
    • mount –bind /dev/pts /data_disk/dev/pts
    • mount –bind /proc /data_disk/proc
    • mount –bind /sys /data_disk/sys
    • chroot /data_disk
    • これでルートが追加したディスクになっていることを確認しておく
    • 何故か初期で mount -o nouuid でマウントできずオプションなしでマウントすることになった（同じマシンで起動する場合には競合する可能性があるので注意）
  5. Kernelの再導入
    • 色々この段階で調査をしているのだが今回はKernelが半端に入っているので再度導入を行う（実際には apt –reinstall install linxu-xxx をしたのだが実行が出来ず結果的には apt autoremmove で修復が実施された
    • Kernelを導入するとその段階でGrub系のコマンドも実行される
    • 今回のケースではない場合には grub install や update-grub などを利用してブート (/boot) を修復する必要があるかもしれない。
    • インスタンス②を停止
    • 編集からディスクを取り外す
  6. 新規にインスタンス②を起動
    • 最終的にはこのインスタンス②を利用するか、壊れたインスタンスのディスクを取り外しても良い（怖いのでここは②を利用して確認をおこなう）
    • 作成時に、先程のディスクを boot diskとして選択する
    • ネットワークの設定などは壊れたインスタンスの内容と同じにしておく
    • 起動を実施してシリアルログから起動メッセージを確認する
    • 起動しない場合にはBoot領域がおかしいなどの場合がある。今回のケースで言えば修復だけして起動したら指定されたKernelがないために起動することが出来なかった。多分 grubで一つ前のものをうまくしてするように修正すれば起動したと思われる

感想

まぁクラウドで良かった。色々試せたので。たまにはスナップショット意外にもマシンイメージとしてバックアップも必要だなと感じた次第。スナップショットの定期実行は便利。Config Managerの自動アップデートの構成（のせい？）は怖い。KernelはUpdateしないほうが無難かもしれない。あとそもそもの原因はストレージ不足とメモリ不足もある気がするのでストレージ拡張した上でZramとかSwapをきちんと定義しておくことで予防にはなる

上部へスクロール