ある日、いつものようにUbuntu（物理マシン）にsshログインしていると、ログイン時のメッセージに、新しいLTSがリリースされているから do-release-upgrade してやっていうメッセージがありました。新しい物好きの自分としては早速実行しました。が、これはsshからやるべきではなかったようです。

結論を言うと起動すらしなくなりました。Ubuntuのロゴにすら到達しない。これをGrokの助けの元修復しました。そのメモ書きを書いておきます。
とりあえず GNU/Linux 6.8.0-57-generic から 6.8.0-58-genericへのアップグレード。Ubuntuは24.04.2 LTSのときです。

申し訳ないのですが、入出力を確保しておらず、あいまいな記憶の言葉のまま書いていきます。現象の細部も実際とは違うかもしれません。

あらすじ

カーネルアップグレードを実行
途中、多分 dpkg の対話処理のあたりで中断
その後起動しなくなった。sshも「no route」
USBブートのUbuntu起動 → GRUBを書き換え
以前のGRUB設定で起動し、dpkgを実行
多分、新カーネルで起動できるようになった

詳細

カーネルアップデート

リリースをアップグレードするやつです。いつもどおりsshで入って実行していましたが、

(https://forum.getodk.org/t/configuring-grub-pc-when-upgrading-ubuntu-system-things/37442 より)
この画像のメニューのときに、たしかOKを選んだ記憶があります。多分これがよくなかったですね。
Grokに状況説明したときには何か障害が起きたと伝えましたが、今思うと自分でやらかしてますね、これは。

問題発生

なんか挙動があやしいなと思いつつ、まあええわとリブート。sshに入れなくなりました。
これはアカンと思い、モニタを繋いでみましたが電源投入しても真っ暗なまま。Ubuntuのロゴも出ません。

復旧準備

まあ状況確認とOS修復、最悪再インストールするか、とUbuntuのUSB起動ドライブを準備。
USBからブートして、元のサーバーのデータを覗いてみますと、データは一通り大丈夫でした。 /home 以下のデータはコピーできるので、確保したいのがそれだけだったら再インストールだけでも大丈夫だったのですが、/srv 以下にサービス化したユーザーのデータがあり、そこにはUSBブートの権限ではアクセスできなかったので、修復を頑張ってみることにしました。

GRUB復旧

Grokに聞くとまず boot-repair を勧められました。今どきこういう事態にも対応するアプリがあるのですね。
ということでUSBからUbuntuをトライアルモードで起動、端末を立ち上げて次のコマンドを実行します：

sudo add-apt-repository ppa:yannubuntu/boot-repair
sudo apt update
sudo apt install -y boot-repair
boot-repair

これを実行するとGUIの対話ウィンドウが立ち上がります。案内通りに推奨設定の修復を試みました。
ところが、UEFI Compatible modeではだめだと文句を言ってきます。面倒ですがいったん再起動、UEFI設定画面に戻り、Bootの設定で「CSM（Compatibility Support Module）」を「Disabled」に設定しました。
再びUSBブートUbuntuに戻り、先のコマンドを実行、またGUIの案内に従い推奨設定の修復を試みました。出力を見るととりあえずは行けそうです。

GRUB修正

再起動しますと、今度はGRUBが見れたようで、最新カーネルのUbuntuを選択できるようになりました。それを実行してみましたが、うまく起動できません。
そこで同最新カーネルのリカバリーモードで見てみると、

cannot open root device "/dev/sda3" or unknown-block(0, 0); error
Please append a correct "root=" boot option;

という感じのエラーが出ていました。まだ上手くいっていないようです。

いろいろ考えてみたところ、1つ前のカーネルを選んでみることにしました。つまり、起動時にGRUBはいくつかカーネルを見つけているので、

Ubuntu
Ubuntu 6.8.0-58-generic 最新カーネル
Ubuntu 6.8.0-58-generic リカバリーモード
Ubuntu 6.8.0-57-generic ひとつ前カーネル
Ubuntu 6.8.0-57-generic リカバリーモード

という感じのリストになっています。このひとつ前のカーネルを選んでみます。すると起動ができました。

GRUBにデフォルトはこれだよと教えてやるととりあえずサーバーを引き続き使えそうです。

sudo vi /etc/default/grub

として、デフォルトの選択オプションを設定します：

GRUB_DEFAULT="1>2"

これをロードして再起動します。

sudo update-grub
reboot

なんかうまくいったようです。

アップデート処理

せっかくなので、アップデートをやり直そうとしました（無謀）。

とりあえず

sudo apt update
sudo apt upgrade

とすると、なんかパッケージの状態がおかしいから dpkg の設定をちゃんとしなさいというエラーになりました。言われた通り

sudo dpkg --configure -a

を実行すると、先のカーネルアップグレードの節にあったような見覚えのある対話処理が出てきました。今度はOKを選ばず、一番上のメンテナーのバージョンを設定するという感じのものを選びました。
すると、なんか問題なく処理が終わった感じ。恐る恐る再起動します。

起動確認

しばらくすると、普通にUbuntuのロゴが立ち上がり、今度はログイン画面まで進みました。デスクトップは問題なさそう。
続いてリモートからsshしてみると、ログイン時の端末に

Welcome to Ubuntu 24.04.2 LTS (GNU/Linux 6.8.0-58-generic x86_64)

と出ました。修復成功したようです。

Grokに聞いたプロンプト

誤字とか、改行とか変換モードのつもりのEnterキー入力がそのまま途中で送信してしまったのもありますが、返答は大丈夫だったのでそのまま書いておきます。

あるノードAのUbuntuを最新のLTSにアップデートするコマンドをSSH上から実行すると何らかの障害が発生し、底から起動しなくなりました。USBブートするUbuntuを別に用意しました。ここからノードAのUbuntuを修復することはできますか？

これでまずは boot-repair を使うように提案されました。

boot-repairはUSBブートのときそのUSBドライブがUEFI Compatible modeだと文句を言ってきます。ASROCKのマザーボードですが、ASROCKのUEFIから設定できますか？

CSM（Compatibility Support Module） を Disable に、また Secure boot も OFF にしてみようと提案されました。

bootrepairは実行でき、recovery mode での実行が可能となりましたが、
cannot open root device "/dev/sda3" or unknown-block(0, 0); error
Please append a correct "root=" boot option; heare are the available partitions:
List of all bdev filesystems:
ext3

ここでGRUBが読み込むドライブを設定する方法を教えてくれましたが、一つ前のカーネルなら上手くできるということに気づきましたので無視しました。

buntu 起動時のAdvanced optionで、ひとつ前のGRUBを実行すると以前のノードAのアカウントで起動できました。この状態だとGRUBを修復すればかなり改善できる（電源投入するとこのGRUBでログインでき、SSHからリモート操作できる）と思うのですが、正しいでしょうか、またその場合どうすればよいでしょうか

ここで /etc/default/grub を 1>2 とする提案を受けました。

前回のGRUBでログイン後、apt  upgradeしようとすると sudo dpkg --configure -a しなさいと言われ、これを実行すると残りのアップグレードが行われ、最新のカーネルとGRUBで問題なく起動できるようになりました。これは何が起こっていたと推測できますか？

これで原因を一通り教えてくれました。たぶん妥当な内容だと思いますが、ここでは割愛します。アップデートのときは tmux とかでセッションの安定を確保しようなどといったアドバイスもありました。

最後に一つだけ、自分nanoやなくてviやねん

viの使い方とかを関西弁で返事してきました。

最後に

アップデートは物理端末上か、せめて screen とかリモートデスクトップなどのより安定な環境でするべき。
ググり散らかして情報を脳内まとめする作業をGrokとかに投げるとだいぶん楽。
なおこの記事の校正とタグ選びはChatGPTにやってもらいました。