Ubuntu20.04をUbuntu21.10にdo-release-upgradeしたらemergencyになった件
今回はLinuxネタです。
本ブログのサーバの役目を担っているThinkPad x121eですが、Ubuntu20.04（LTS）で稼働していました。
それも、つい数時間前までは・・・。
ここ最近はManjaroLinuxやArchLinuxをインストールしたり、周囲が最新になっていくのに、
Ubuntuだけがまだ20.04（LTS）の状態ってのもね、やっぱりもう古い感じですよね？
pythonだってバージョンが新しくなっていくしね。
それと、やっとManjaroLinuxで予備のWEBサーバも構築できて、
コンテンツ同期とDB同期もして冗長体制で稼働開始したし、
だったらUbuntuも最新の21.10にしてしまおう！
というわけで、アップデートを実行することにしました。
だが、しかし、この決断が後に、Ubuntuが
emergencyで起動することになる悪夢の始まりだったのです・・・。
アップグレードの方法は２通り
OSを最新化するにあたっての方法は、既存のデータを初期化してしまう方式「クリーンインストール」と
既存のデータそのままで更新を行う方式の「アップグレード」がありますが、
今回筆者はバックアップなどの手間掛けたくないためクリーンインストールではなく、
アップグレードの方法を選択しました。
ではなぜアップグレードにしたか？
その理由ですが、最近WSL（Windows上のLinux）では、
Ubuntu20.04をUbuntu21.10にアップグレードできたので、
その成功実績からいけるだろうと判断したのです。
UbuntuLinuxのアップグレード手順
アップグレード作業にあったて、Ubuntuには「do-release-upgrade」という
OSのアップグレードコマンドが用意されており、ほぼ全ての作業をやってくれます。
途中で何度か設定ファイルなどの確認を求められる箇所があるくらいです。
自身で設定したファイルは上書きされないように基本は「N」で回答します。
LTS版の場合は以下の修正が必要です。
尚、LTS版を使っている場合、上記コマンドではアップグレードできないと言われます。
LTS版からアップグレードをするには以下のファイルを編集して、
「Prompt=lts」の箇所を「Prompt=normal」にしてやる必要があります。
ltsは安定版、normalは先進の取り組み版という位置付けになります。
そのためltsの方がアップグレードが来るのが2年おきとなるわけです。
ま、筆者は今回はUbuntuのLTS版でしたので、まずは以下のファイルを修正しました。
$ sudo vi /etc/update-manager/release-upgrades# Default behavior for the release upgrader.
[DEFAULT]
# Default prompting and upgrade behavior, valid options:
#
# never - Never check for, or allow upgrading to, a new release.
# normal - Check to see if a new release is available. If more than one new
# release is found, the release upgrader will attempt to upgrade to
# the supported release that immediately succeeds the
# currently-running release.
# lts - Check to see if a new LTS release is available. The upgrader
# will attempt to upgrade to the first LTS release available after
# the currently-running one. Note that if this option is used and
# the currently-running release is not itself an LTS release the
# upgrader will assume prompt was meant to be normal.
Prompt=normal上記を編集したら以下を実行でアップグレードが開始されます。
$ sudo do-release-upgradeUbuntu20.04からUbuntu 21.04へアップグレード成功！！
作業は2〜30分ほどで完了しました。
先ほどまでの20.04が21.04になっていました。
カーネルも5.11となっていますね。
しかしですね、今の最新のUbuntuのバージョンは21.10だったはず。
これでは最新のUbuntu21.10ではありません。
つまり一気に最新へのアップグレードは行えず、
ひとつずつアップデートしなさいってことですかね。
１回で間をすっとばして最新にはならない、そんな仕組みなんですかね。
そんなわけで再度、先程のコマンドを打ち込みました。
「sudo do-release-upgrade」
その後、20分程度経過し、ファイル更新が完了し、OS再起動となったところで、
いくら待ってもssh接続ができません。
いやな予感がしますね。
まさかのemergencyモードに！！
サーバとして棚に置いてあるThinkPadを手元に持ってきて確認したところ、
emergencyモードで入力待ちとなっていました・・・。
表示されているメッセージから、graphicalモードで起動できないと言ってました。
アップグレードで起動モードが勝手に変わっていた！！
どうやら21.04から21.10の過程でデフォルトの起動モードが、「do-release-upgrade」で
今回アップグレードした際に「graphical.target」に変更されてしまったようです。
起動モードを変更
元々はサーバ用途なのでmulti-user.targetにしてあり、XWindows関連のアプリは含まれてません。
これでエラーになったのでしょうね、まずはこれを修正します。
# systemctl set-default mutil-user.targetこれで再起動しましたが、まだ止まってしまいました。
そこで、エラーログを確認してみます。
以下の３通りのパターンで確認しました。
jounalctl -xb|grep error
jounalctl -xb|grep Error
jounalctl -xb|grep ERROR
するとACPI関連でエラーが出ていました、これはカーネルのバグか？
それともThinkPadの方がACPI電源関連の部品不良かなにかで寿命なのか？
ACPIを無効化してみる
起動時のkernelの呼び出しでACPIを無効化してみます。
grubのコンフィグファイルを開きます。
# vi /boot/grub/grub.cfg
いくつかありますが、メインで呼び出すところは以下になります。
linux /boot/vmlinuz-5.13.0-20-generic root=UUID=e6a59b2a-98c0-49c4-93bc-6cce51f1a8eb ro
initrd /boot/initrd.img-5.13.0-20-generic上記へ「acpi=off」を追加します。以下のようになります。
linux /boot/vmlinuz-5.13.0-20-generic root=UUID=e6a59b2a-98c0-49c4-93bc-6cce51f1a8eb ro acpi=off
initrd /boot/initrd.img-5.13.0-20-genericこれでrebootしてみましたが、まだダメです。
最後は/etc/fstabを修正
ディスクのマウントで止まっているように見えました。
そこでバックアップ用にUSBメモリを自動マウントするようにしているのですが、
/etc/fstabの記述からUSBメモリ部分をコメントアウトしたところ無事復旧しました。
なんとか復旧！！
トラブルシューティングは勉強になりますが、今回の件で筆者も学習しました。
やはりUbuntuはdo-release-upgradeしてはいかん、クリーンインストールが良いですなぁと。
今回のように設定書き換えられたり、/etc/fstabなどに影響ある可能性もありますし、
想定できない修正の場合は、手に負えない場合があるかもしれません。
それでもという場合、実機の場合は慎重に、万が一起動しない場合に備えて、
バックアップをしっかり取ってから実施しましょう。
今回筆者は焦りましたよ、スキルや経験のおかげでなんとか復旧できましたが、ね。
というわけで、今回の21.10のneofetchを取得！
ふと過去のBlog記事見ていたら、実はUbuntu19.10→20.04→21.04→21.10だったわ。。
となると、かなり、いろいろゴミが溜まっているかもしれないですね。
やっぱりそろそろクリーンインストールしたいなぁ。
それでは！！
HappyHackingLifeを！
