症状
-
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なので対処の方法は色々取れるのは助かりました。結果として実施した内容を以下に整理しておきます。原因は別でも似たような症状になった場合には対処できることもあるかもしれません。
- ストレージのスナップショットから「ディスクを作成」する
-
復元するリージョン・ゾーンと同じ場所に作る
-
サイズをこの段階で20Gに変更しておく（サイズはGCEの場合にはオンラインでも変更可能）
-
名前は適当に
- 新規に同じリージョン・ゾーンでインスタンス①を作成する
-
ネットワークなどの通信設定は不要（ディフォルトで作成して問題ない）
-
OSは故障したものと同じOSのバージョンのイメージ（今回はUbuntu22.04 min LTS）を利用して作成する
- インスタンス①を起動したらディスクを修復
-
parted -lで GPTエラーが出ていたら修復する -
ディスクサイズを大きくしているので以下で拡張をする
resize2fs /dev/sdb1を実施（ファイルシステムを拡張）
- ディスクを修復
e2fsck -f /dev/sdb1
- ディスクをマウントしてChrootを実施
-
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 でマウントできずオプションなしでマウントすることになった（同じマシンで起動する場合には競合する可能性があるので注意）
- Kernelの再導入
-
Kernelを導入するとその段階でGrub系のコマンドも実行される
-
今回のケースではない場合には grub install や update-grub などを利用してブート (/boot) を修復する必要があるかもしれない。
-
インスタンス②を停止
-
編集からディスクを取り外す
- 新規にインスタンス②を起動
-
作成時に、先程のディスクを
boot diskとして選択する -
ネットワークの設定などは壊れたインスタンスの内容と同じにしておく
-
起動を実施してシリアルログから起動メッセージを確認する
-
起動しない場合にはBoot領域がおかしいなどの場合がある。今回のケースで言えば修復だけして起動したら指定されたKernelがないために起動することが出来なかった。多分 grubで一つ前のものをうまくしてするように修正すれば起動したと思われる
感想
まぁクラウドで良かった。色々試せたので。たまにはスナップショット意外にもマシンイメージとしてバックアップも必要だなと感じた次第。スナップショットの定期実行は便利。Config Managerの自動アップデートの構成（のせい？）は怖い。KernelはUpdateしないほうが無難かもしれない。あとそもそもの原因はストレージ不足とメモリ不足もある気がするのでストレージ拡張した上でZramとかSwapをきちんと定義しておくことで予防にはなる