はじめに
以前から使用していたUbuntuサーバーを、Ubuntu 26.04 LTSへアップグレードすることにしました。
今回は、普段使用しているWindows PCからRDP（リモートデスクトップ）でUbuntuに接続した状態のまま、リリースアップグレードを実行しました。
アップグレードは順調に進んでいるように見えましたが、途中で突然RDP接続が切断されました。
「アップグレードによって再起動したのだろう」と考え、その後あらためてRDP接続を試みました。
ところが、思ったように接続できません。
結果的には、アップグレード自体はかなり進んでいたものの、多数のパッケージがまだ設定されていない状態になっていました。
この後、ChatGPTに状況を相談しながら状態を一つずつ確認し、最終的にUbuntu 26.04.1 LTSを正常な状態まで復旧することができました。
今回は、その顛末を記録しておきます。
1．リモートデスクトップからUbuntuをアップグレード
今回の環境は、
- Ubuntu 25.10系からUbuntu 26.04 LTSへアップグレード
- GNOMEデスクトップ環境
- Wayland
- GNOME Remote DesktopによるRDP接続
- Windows PCからリモート操作
という構成です。
UbuntuはノートPCにインストールし、直接ノートPCのモニターとキーボードを使用するのではなく、Windows PCからRDPで接続して使用しています。
そこで今回も、リモート接続した状態でUbuntuのリリースアップグレードを開始しました。
2．アップグレード途中でRDPが切断
アップグレード処理は大量のパッケージを更新するため、かなり時間がかかります。
しばらくすると、突然RDP接続が切れました。
ここで、
「アップグレードが終了して再起動したのだろう」
と考えてしまいました。
しかし、これは少し早い判断でした。
アップグレードでは、GNOME、GDM、Wayland、ネットワーク関連など、現在のリモートデスクトップ環境そのものに関係するパッケージも更新されます。
そのため、アップグレード途中でGUIやRDPのセッションが切断されることがあります。
問題は、
「RDPが切れたこと」と「アップグレードが完了したこと」は同じではない
ということでした。
3．再接続できず、アップグレードの状態を確認
RDP接続を再度試みましたが、思ったように接続できませんでした。
そこでChatGPTに状況を説明し、まずシステムのパッケージ状態を確認することにしました。
実行したのが、
sudo dpkg --audit
です。
すると、
展開されましたが、まだ設定されていません
というパッケージが大量に表示されました。
GNOME関連のパッケージをはじめ、デスクトップ環境を構成する多数のパッケージが未設定の状態になっていました。
つまり、
Ubuntuのアップグレードは途中まで進んでいたものの、完全には終了していなかった
ことが分かりました。
4．apt-get -f installで未設定パッケージを処理
次にChatGPTの助言に従い、
sudo apt-get -f install
を実行しました。
すると、大量のパッケージについて、
○○○ を設定しています ...
という処理が始まりました。
GNOME、GDM、polkit、ibus、Remmina、Nautilusなど、デスクトップ環境に関係するパッケージが次々と設定されていきます。
また、カーネルについても、
linux-image-7.0.0-30-generic
が処理され、initramfsの生成やGRUBの更新も行われました。
最終的には、未設定だったパッケージの処理が完了しました。
5．dpkg --auditで状態を確認
修復できたかどうかを確認するため、再度、
sudo dpkg --audit
を実行しました。
今度は何も表示されません。
これは、dpkgから見て未設定のパッケージが残っていないことを意味します。
ひとまずパッケージ管理上は正常な状態に戻ったと判断しました。
6．再起動
その後、システムを再起動しました。
sudo reboot
再起動後、Ubuntuのバージョンを確認すると、
uname -r
の結果は、
7.0.0-30-generic
となっていました。
さらに、
lsb_release -a
では、
Distributor ID: Ubuntu
Description: Ubuntu 26.04.1 LTS
Release: 26.04
Codename: resolute
と表示されました。
これで、Ubuntu 26.04.1 LTSへのアップグレードが正常に完了していることを確認できました。
7．ところが、RDPにはもう一つ問題があった
OSのアップグレードは完了しましたが、ここで別の問題が出てきました。
今回の目的は、
Ubuntu本体側でログインしていなくても、Windows PCからRDP接続してUbuntuにログインしたい
というものです。
ところが、通常のユーザーセッション用RDPでは、本体側ですでにUbuntuへログインしていないと、思ったように接続できませんでした。
そこでChatGPTと一緒にGNOME Remote Desktopの状態を確認しました。
grdctl status
と、
sudo grdctl --system status
を比較すると、通常ユーザー用とsystem-wideのRDPが別々に存在していることが分かりました。
8．system-wideのRDPを有効化
そこで、system-wideのGNOME Remote Desktopを有効にしました。
sudo grdctl --system rdp enable
状態を確認すると、
RDP:
Status: enabled
Port: 3389
となりました。
一方、通常ユーザー側のRDPについては、
gsettings set org.gnome.desktop.remote-desktop.rdp enable false
として無効化しました。
これは、通常ユーザー用とsystem-wideのRDPが二重に動作して混乱することを避けるためです。
9．ログイン前のRDP接続に成功
ここまで設定したところ、期待していた動作が実現しました。
Ubuntu本体ではログインしていない状態で、
Windows PCからRDP接続。
すると、リモート側からUbuntuへログインできました。
つまり、
Ubuntu本体
↓
ログインしていない
↓
Windows PCからRDP
↓
Ubuntuのログイン
↓
GNOMEデスクトップ
という使い方が可能になりました。
10．しかもリモート側は大画面で使用できた
当初は、RDP接続すると本体画面が表示されたままになり、リモート側が「拡張デスクトップ」のようになってしまう問題もありました。
現在の設定を確認すると、
gsettings get org.gnome.desktop.remote-desktop.rdp screen-share-mode
は、
'extend'
となっています。
ところが、system-wideのRDPからログインした場合には、以前とは異なり、リモート側の大きな画面を使って通常のUbuntuデスクトップを操作できるようになりました。
また、
echo $XDG_SESSION_TYPE
は、
wayland
echo $WAYLAND_DISPLAY
は、
wayland-0
となっていました。
結果として、現在はリモート側で快適にUbuntuを操作できています。
11．今回分かったこと
今回のトラブルを通して、いくつか重要なことが分かりました。
① RDPが切断されたからといって、アップグレードが終了したとは限らない
アップグレード中は、GNOMEやGDMなどの更新によってGUIセッションが切断されることがあります。
そのため、
RDPが切れた → アップグレード完了
と判断するのは危険です。
② dpkg --auditは非常に有効だった
今回、アップグレードが正常に終了しているかどうかを確認するために、
sudo dpkg --audit
を使用しました。
大量の未設定パッケージが表示されたことで、アップグレードが完全には終了していないことが分かりました。
復旧後に再度実行して何も表示されないことを確認することで、パッケージ管理上の状態を確認できました。
③ apt-get -f installで未完了の処理を継続できた
今回の復旧では、
sudo apt-get -f install
によって、未設定だった大量のパッケージが順次設定されました。
結果として、GNOMEを含むデスクトップ環境を正常な状態まで戻すことができました。
④ リモート環境では「接続が切れること」を前提にした方がよい
今回もっとも勉強になったのは、この点です。
OSのアップグレードをRDPだけに頼って実行すると、アップグレードによってRDPそのものが切断される可能性があります。
今後、同じような作業を行う場合には、SSHやtmuxなど、GUIとは独立した方法でアップグレードの状態を確認できるようにしておく方が安全だと思います。
12．今回のまとめ
今回のトラブルは、
「リモートデスクトップでUbuntuをアップグレードしていたところ、途中でRDPが切断され、アップグレードが完全に終了していない状態になっていた」
ことから始まりました。
その後、
dpkg --audit
↓
未設定パッケージを確認
↓
apt-get -f install
↓
パッケージ設定を完了
↓
dpkg --audit
↓
問題なし
↓
再起動
↓
Ubuntu 26.04.1 LTSを確認
↓
system-wide RDPを有効化
↓
ログイン前のRDP接続に成功
という手順で復旧しました。
今回の復旧では、ChatGPTに実際のターミナル画面の結果を一つずつ提示しながら、原因を切り分けていきました。
「何となく操作して直す」のではなく、コマンドの結果を確認しながら次の操作を決めることが、今回の復旧につながったと思います。
最終的には、Ubuntu 26.04.1 LTSへのアップグレードを完了し、さらに、
「本体側でログインしていなくても、Windows PCからRDP接続してUbuntuへログインし、大画面で操作する」
という当初の目的も達成することができました。
おわりに
今回の経験から、リモート環境でOSの大きなアップグレードを行う場合には、
「リモート接続が切れる可能性をあらかじめ想定しておく」
ことが重要だと感じました。
また、トラブルが発生したときには、いきなり設定を変更するのではなく、
sudo dpkg --audit
などで現在の状態を確認し、その結果をもとに復旧作業を進めることが大切です。
今回はChatGPTにも協力してもらいながら、最終的に無事復旧することができました。
同じようにリモート環境からUbuntuをアップグレードする方の参考になればと思い、今回の顛末を記録として残しておきます。
コメントを残す