Google Compute Engineで焦ってDebianのアップグレードをしてしまったらSSH接続が出来なくなってしまいました。
※自分の場合は個人利用のf1-microマシンなので適当ですが、まともなVMでアップグレードをする際にはスナップショットを取るなど、巻き戻せる準備もしておくべきですね。
いろいろ試しながら検索したところでは、
GCPでstretchをbusterに上げたらSSH鍵が転送されなくなった－blog.akimasa.jp
結局、ゲスト環境パッケージのインストールを行ったら直った。
google-compute-engine-osloginとgoogle-compute-engineが入っていなかったようだ。
というわけで、google-compute-engine-osloginを入れねば、と思いました。
SSHログインできないときはシリアルコンソール接続になります。
が、 パスワード設定していないのでログイン出来ません。
さらに調べたところ、
ゲスト環境のインストール | Compute Engine ドキュメント
の 「ブートディスクのクローンを作成して起動スクリプトでゲスト環境をインストール」をやっていけばなんとかなりそうです。
もうひとつVMインスタンスを立ち上げ、今使っているディスクをコピーしてrc.localに仕込んで動かす、という寸法です。
が、自分の環境の場合、別の依存関係で失敗してしまいます。
google-compute-engine : Depends: python3-google-compute-engine (= 20190124-3) but 2.8.16-1 is to be installed
みたいな感じです。アップグレードが古すぎたのですね。
都度都度rc.localに仕込んでブート時に対処するのは厳しいので、この仕組みを応用してアカウントにパスワードを設定することにしました。
Debian だと chpasswdでファイルを読み込めばパスワード設定できるはずです。
gcloud compute ssh rescue
export NEW_DISK_MOUNT_POINT="/tmp/sdb-root-vol"
DEV="/dev/sdb1"
sudo mkdir "$NEW_DISK_MOUNT_POINT"
sudo mount "$DEV" "$NEW_DISK_MOUNT_POINT"
cat <<'EOF' >/tmp/rc.local
#!/bin/bash
cat <<'EOL' > /tmp/myuser.txt
ログインユーザー名:パスワード
EOL
sudo chpasswd < /tmp/myuser.txt
rm /tmp/myuser.txt
reboot now
EOF
if [ -f "$NEW_DISK_MOUNT_POINT/etc/rc.local" ]; then
sudo mv "$NEW_DISK_MOUNT_POINT/etc/rc.local" \
"$NEW_DISK_MOUNT_POINT/etc/moved-rc.local"
fi
sudo mv /tmp/rc.local "$NEW_DISK_MOUNT_POINT/etc/rc.local"
sudo chmod 0755 "$NEW_DISK_MOUNT_POINT/etc/rc.local"
sudo chown root:root "$NEW_DISK_MOUNT_POINT/etc/rc.local"
sudo umount "$NEW_DISK_MOUNT_POINT" && sudo rmdir "$NEW_DISK_MOUNT_POINT"
みたいなことをしてみたら、パスワード設定されたディスクを準備できました。
ちなみに上記のサイトだと、さらに別のインスタンスを用意して新ディスクで動かしてね、みたいな流れでしたが、
ぶっちゃけ旧インスタンスのブートディスクを外してrescueインスタンスで上記みたいなrc.localを仕込めば2インスタンスで作業は済みます。
シリアルコンソール接続できれば、あとは
apt --fix-broken install
とかなんとか右往左往してSSH接続出来るようになりました。
いやーヒヤヒヤしました！