またしてもBlogが止まっていたのをようやく修復

以前書いたの項目と同じ症状

  • KernekのUpgardeがうまく行かない → カーネルが見つからず(link切れになっている)

この結果再起動した際にカーネルパニックが発生して起動しなくなる。
回復の手段はわかっているのだが面倒すぎる。ということで一旦GCEの自動更新をやめておこうと思う。

復旧手順は変わらないが

  1. 以前のGCEのストレージを「複製」
  2. 新しいGCEサーバ作る、複製したディスクをセカンダリにつける。Versionは合わせておく(今回あであれば 22.04 )
  3. 起動したら以下のコマンドを実行
mkdir /data_disk
mount /dev/sdb1 /data_disk
for m in dev proc run sys; do mount -o bind {,/data_disk}/$m; done
chroot /data_disk
apt update
apt upgrade

実際に手動で upgradeしてもすごい時間がかかるのでこれはうまく言ってないのじゃなくてGCE側のUpdateのTimeoutでも起こっているんじゃないのかとも思われる。

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

症状

  • 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をきちんと定義しておくことで予防にはなる

GCE(VM)のUbuntuサーバのUpgradeの実施とVM Managerの設定

Read More

OSのアップグレードを実施するためにSSHで接続をしていると警告を言われるため、シリアルコンソール接続を利用してクラウド側から接続を行います。
Google Cloud Consoleから接続し該当のVMを編集し「シリアルポートへの接続を有効にする」をチェックを入れます。その後「シリアルコンソールに接続」ボタンからブラウザ経由で接続を行います(この機能はホント便利ですね、クラウドでの利用でも不便さを感じないのはすばらしい)

シリアルコンソールを接続しているプロンプトで do-release-upgrade を実行します。(途中かりに接続がきれても再度接続すればつながると思います)

GCEのリソースサイズが小さすぎてものすごい時間(2時間強)を経てやっとUpdate完了、再起動をします。

No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.6 LTS
Release: 18.04
Codename: bionic

何故か、自動起動をしてないはずの apache2が自動起動してきたりして焦りましたが disableにしておきます。

VM Managerの設定

https://cloud.google.com/compute/docs/manage-os?hl=ja#ubuntu に記載がありますがUbuntuのバージョンによってもことなりますが今回は18.0以降になるので以下のコマンドで導入をします。

sudo su -c "echo 'deb http://packages.cloud.google.com/apt google-compute-engine-bionic-stable main' > \
/etc/apt/sources.list.d/google-compute-engine.list"
curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
vi /etc/apt/sources.list.d/google-compute-engine.list
sudo apt update
sudo apt -y install google-osconfig-agent

これでコンソールからVMの情報が見ることが出来るようになります。

バッチのジョブ作成

GCEでは、apt update を自動的に実施するためのサービスが提供されていますのでこちらを設定してみます。

日々の更新をしたいので apt upgrade を選択します。

作成した後に一度実施するために「今すぐデプロイ」を選択して実行してみます。

上記のように結果が出ています、問題がある場合にはどういう感じで出てくるのかはまだ見れてないのでしばらく利用してから考えていきたいと思います。今回は除外パッケージ等を入れてないのですが実際に本番で使う場合などはコアのパッケージはブロックして手動で確認するなど運用のルールは決めておいたほうがよいでしょう。

(追伸)

  • その後 22.04までアップデートしましたがせっかくのクラウドなのでサーバのリソースを増強してすべき
  • 22.04になった段階でphp-fpmが 7.4系から 8.1系に変わってしまう。通常であれば「保留」になっているのだが無理にdist-upgradeしたために7.4系が消えてしまう問題が起こった(結局リストアして対応)※このサイトのどうしても php8系だとエラーが消えずに対応できず
  • 上記の問題も有り phpが4つバージョンで起動していたので修正
  • 途中で apache2が何故か有効化されてしまったので(このサイトはnginx)で停止
  • 結果としては時間がかかったくらいで大きな問題もなく完了