前々から行わねばと思いつつも、WSL2を最初にセットアップしたままズルズルと今日まで使用して来ましたが、ようやく重い腰を上げて、アップグレードすることにしましたので、その手順を記録に残しておきたいと思います。
- Ubuntuのアップグレードをする！
- 1. 現状の調査
- 2. アップグレード実施
- 3. WSLインスタンスのシャットダウン方法
- 4. Snapd関連エラーの発生
- 5. Snapd問題を解決しアップグレードを再開する手順
- 6. Systemd設定の確認と強制適用
- 7. 再度確認と強制実行
- 8. アップグレード再開のための最終ステップ
- 9. アップグレード再開のための最終ステップ
- 10. Ubuntu起動
- 11. アップグレード再開のための最終確認と実行
- 最終的な解決手順：PostgreSQL 12の削除
- 13. アップグレードが完了したかどうかの確認
- 14. 最終的なクリーンアップとPostgreSQLの処理
- 15. Ubuntuを起動したときの動作について
- 参考にしたサイト等
Ubuntuのアップグレードをする！
1. 現状の調査
まずは現在の環境。
PowerShellを立ち上げ、コマンドで調査した結果です。
|
1 2 3 4 5 |
PS C:\WINDOWS\system32> wsl -l -v NAME STATE VERSION * Ubuntu-20.04 Running 2 docker-desktop-data Running 2 docker-desktop Running 2 |
もうひとつ実行。
|
1 2 3 4 5 6 7 8 |
PS C:\WINDOWS\system32> wsl --version WSL バージョン: 2.6.1.0 カーネル バージョン: 6.6.87.2-1 WSLg バージョン: 1.0.66 MSRDC バージョン: 1.2.6353 Direct3D バージョン: 1.611.1-81528511 DXCore バージョン: 10.0.26100.1-240331-1435.ge-release Windows バージョン: 10.0.26200.7019 |
はい、初めてWSL環境を作成した３年ぐらい前のままですね。
Ubuntuのバージョンは20.04です。
調べたところ、本日の段階でUbuntuのバージョンは24.04です。
おおう（苦笑）
次に、一応Ubuntu 24.04が利用できるかを確認します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
PS C:\WINDOWS\system32> wsl --list --online インストールできる有効なディストリビューションの一覧を次に示します。 'wsl.exe --install <Distro>' を使用してインストールします。 NAME FRIENDLY NAME AlmaLinux-8 AlmaLinux OS 8 AlmaLinux-9 AlmaLinux OS 9 AlmaLinux-Kitten-10 AlmaLinux OS Kitten 10 AlmaLinux-10 AlmaLinux OS 10 Debian Debian GNU/Linux FedoraLinux-43 Fedora Linux 43 FedoraLinux-42 Fedora Linux 42 SUSE-Linux-Enterprise-15-SP7 SUSE Linux Enterprise 15 SP7 SUSE-Linux-Enterprise-16.0 SUSE Linux Enterprise 16.0 Ubuntu Ubuntu Ubuntu-24.04 Ubuntu 24.04 LTS ←★これ archlinux Arch Linux kali-linux Kali Linux Rolling openSUSE-Tumbleweed openSUSE Tumbleweed openSUSE-Leap-16.0 openSUSE Leap 16.0 Ubuntu-20.04 Ubuntu 20.04 LTS Ubuntu-22.04 Ubuntu 22.04 LTS OracleLinux_7_9 Oracle Linux 7.9 OracleLinux_8_10 Oracle Linux 8.10 OracleLinux_9_5 Oracle Linux 9.5 openSUSE-Leap-15.6 openSUSE Leap 15.6 SUSE-Linux-Enterprise-15-SP6 SUSE Linux Enterprise 15 SP6 |
Ubuntu-24.04 との表記があるので、どうやら使用できるようです。
一安心。
2. アップグレード実施
ではここからは、アップグレードの手順です。
基本的に、Ubuntuのアップグレードは、do-release-upgradeコマンドを使用すればできるっぽいのですが、パッケージのバージョンなどもアップグレードする必要があるので、パッケージ、本体という手順を踏みます。
なお、アップグレードには PowerShell ではなく、現状でインストール済みの Ubuntu のターミナルから行います。
ということで、PowerShell には一旦退場してもらって、Ubuntu20.04 のターミナルにチェンジします。
2-1. 既存パッケージの更新
まず、現在のUbuntu環境のパッケージを最新の状態にします。
|
1 2 3 |
sudo apt update sudo apt upgrade sudo apt autoremove |
コマンドの解説
- sudo apt update：パッケージリストを更新します
- sudo apt upgrade：インストール済みのパッケージをアップグレードします
- sudo apt autoremove：不要になった依存関係のパッケージを削除します
順番にコマンドを実行していきます。
画面は上記のような感じです。
続いてコマンドを実行します。
途中、空き容量がこれぐらい必要だが、続けるか？ との質問があったので、Y（イエス） と答えて続行しました。
ちょっと時間がかかりますが、無事終了。
では最後のコマンド。
2番目のコマンド同様、今度はこれぐらい解放されるが、良いか？ との質問が表示されたので Y（イエス）で続行します。
これも問題なく終了。
2-2. アップグレードマネージャーの確認とインストール
ディストリビューションのアップグレードに必要なパッケージがインストールされているか確認します。
通常、LTSバージョンではデフォルトでインストールされていますが、念のため実行します。
|
1 |
sudo apt install update-manager-core |
2-3. アップグレードポリシーの確認 (LTS版へのアップグレード)
/etc/update-manager/release-upgrades ファイルを開き、Prompt の設定を確認します。
LTSバージョンのみにアップグレードしたい場合は、ltsになっていることを確認してください。
（20.04から22.04へのアップグレードでは通常ltsで問題ありません）
|
1 2 |
cat /etc/update-manager/release-upgrades # Prompt=lts となっていることを確認 |
↑ Prompt = lts となっていることを確認できました。
2-4. アップグレードの実行
以下のコマンドを実行して、アップグレードプロセスを開始します。
|
1 |
sudo do-release-upgrade |
上記コマンドを実行すると、アップグレードに関する情報が表示され、続行するか尋ねられます。
内容を確認し、問題なければ y を入力して進めます。
アップグレード中に、設定ファイル（sshd_configなど）の上書きに関する質問や、廃止されるパッケージの削除に関する確認が何度か求められます。
画面の指示をよく読み、適切に判断して進めてください。
設定ファイルの上書きについては、通常は「N（現在のファイルを保持）」を選択することが多いですが、変更内容を確認して判断してください。
途中で再起動（リブート）が必要か尋ねられます。
WSL環境の場合、これは Linux ディストリビューション内の再起動ではなく、WSL インスタンス自体の終了と再起動を意味します。
指示に従い y を選択し、アップグレードを完了させます。
などと色々と書きましたが、実際にコマンドを実行してみると以下のようになりました。
|
1 2 3 4 |
tsujisaka@DESKTOP-7GBREKH:~$ sudo do-release-upgrade [sudo] password for tsujisaka: Checking for a new Ubuntu release You have not rebooted after updating a package which requires a reboot. Please reboot before upgrading. |
パスワードを求められたので、入力しますが何やらメッセージが表示されました。
どうやら、パッケージの更新後にシステムが再起動されていないために、アップグレードに進めないことを示しているようです。
なるほどですね。
このメッセージが出た場合の対処法は、WSLインスタンスをシャットダウンして再起動することです。
3. WSLインスタンスのシャットダウン方法
3-1. WSLインスタンスの完全シャットダウン
まず、WindowsのPowerShellを開いてください。
以下のコマンドを実行し、実行中の全ての WSL ディストリビューションを停止します。
|
1 2 |
# WindowsのPowerShellまたはコマンドプロンプトで実行 wsl --shutdown |
すると、次のウィンドウが表示されました。
よくわかりませんが、面白そうなので「Restart」ボタンを押してみます。
うーむ、どうやらDockerデスクトップの起動が行われたようです。
やっぱりよくわからなかったので、このまま進めてみます。
3-2. Ubuntuの再起動
シャットダウンが完了したら、再度 Ubuntuのターミナルを起動します。
これで、WSLインスタンスがリフレッシュされた状態で再起動されます。
|
1 2 3 4 5 |
[sudo] password for tsujisaka: * Starting PostgreSQL 12 database server [ OK ] tsujisaka@DESKTOP-7GBREKH:~$ sudo service postgresql stop * Stopping PostgreSQL 12 database server [ OK ] tsujisaka@DESKTOP-7GBREKH:~$ |
ここでなぜかPostgreSQL12 が起動しましたので、次のコマンドで停止します。
|
1 |
sudo service postgresql stop |
WSLを起動した際、パスワード入力後に PostgreSQL が自動で起動しているのは、おそらく PostgreSQL が WSL 環境の起動スクリプトまたはサービス管理システムによって自動的に起動されるように設定されているためです。
ちなみに PostgreSQL を起動したまま進めると、下記画面が表示され何回かループしてしまったので、禍根を断つべく PostgreSQL を停止することとしました。
なおこのメッセージは、システムの中核となるライブラリである glibc（GNU C Library）をアップグレードするにあたり、いくつかの実行中のサービスを再起動または停止する必要があることを示しています。
特に重要なのは、以下の警告と質問です。
サービスの停止が必要：
This script detected the following installed services which must be stopped before the upgrade: postgresql
アップグレードの前に、PostgreSQL サービスを停止する必要があります。
glibcのアップグレードに関する質問：
Do you want to upgrade glibc now?
今、glibcをアップグレードしますか？
3-2 で PostgreSQL が起動したのが原因で表示されるメッセージです。
この状況では、まず 「No」を選択してアップグレードを一時中断し、PostgreSQLサービスを手動で停止してから、再度アップグレードを試みるのが最も安全な進め方とのことなので、そのとおりにしましたがうまくいかなかったので、最初っから PostgreSQL を停止することしました。
一筋縄ではいかないのがアップグレードなのです（苦笑）
まぁこれも経験です。
気を取り直して、再度パッケージのアップデートからやり直します。
|
1 2 3 |
sudo apt update sudo apt upgrade sudo apt autoremove |
を行いましたが、途中で下記メッセージが表示されました。
|
1 |
Please install all available updates for your release before upgrading. |
これは、apt upgrade ではインストールされないパッケージが残っている可能性を示唆しています。
具体的には、新しいバージョンのパッケージが依存関係の変更によりインストールが必要だが、既存のパッケージを削除する必要がある場合、apt upgrade は安全のためそれをスキップします。
これを強制的に解決するには、パッケージを削除・インストールする可能性のある apt dist-upgrade を試す必要があるとのことです。
|
1 |
sudo apt dist-upgrade |
終了後は PowerShell から WSL をシャットダウンします。
Ubuntu を起動すると例によって PostgreSQL が起動するので、停止コマンドで停止します。
ようやく全ての障害が取り除かれましたので、下記コマンドでアップグレードを実行します。
|
1 |
sudo do-release-upgrade |
4. Snapd関連エラーの発生
これでうまくいくのかと思いきや、またもエラー発生。
|
1 2 3 |
raise CalledProcessError(retcode, process.args, subprocess.CalledProcessError: Command '['snap', 'list']' returned non-zero exit status 1. === Command terminated with exit status 1 (Fri Nov 7 18:33:02 2025) === |
4-1. 原因の考察
ここで表示されたエラーメッセージは、Ubuntuのパッケージ管理システムである Snap に関連する問題を示しており、アップグレードプロセスが実行した snap list コマンドが、正常終了を示す終了ステータス 0 ではなく、エラーを示す終了ステータス 1 を返したために、アップグレード処理が中断されたことを意味します。
この問題の主な原因は、WSL環境におけるSnapdサービスが正しく起動していない ことにあると考えられるとのこと。
また他のサイトを検索したところ、以下の考察がされていました。
snapd を動かすためには systemd が必要で、systemd はいつのころからか WSL2 で動くようになっているようです。
たぶん、ある時期より古いタイミングでインストールした WSL2 (Ubuntu) では動いてなかったんでしょう
私も調査のため、下記コマンドを実行します。
|
1 2 3 |
tsujisaka@DESKTOP-7GBREKH:~$ snap list error: cannot list snaps: cannot communicate with server: Get "http://localhost/v2/snaps": dial unix /run/snapd.socket: connect: no such file or directory |
やはり Snapd サービスが起動しておらず、エラーとなっているようです。
5. Snapd問題を解決しアップグレードを再開する手順
5-1. WSLインスタンスの完全シャットダウン
まず、WSL 2環境をリフレッシュするために、インスタンスを完全に停止します。
PowerShellから、WSLを停止します。
|
1 |
wsl --shutdown |
5-2. PostgreSQLサービスの停止
Ubuntu を起動。
私の環境では PostgreSQL が自動起動しているので、邪魔をするかもしれない PostgreSQL を停止します。
|
1 2 3 |
# 1. Ubuntuを起動し、パスワードを入力 # 2. PostgreSQLサービスを停止 sudo service postgresql stop |
5-3. systemdの有効化
WSL 2の設定ファイル /etc/wsl.conf を編集して systemd を有効にします。
Ubuntu のターミナルから下記コマンドで設定ファイルを開きます。
|
1 |
sudo vi /etc/wsl.conf |
以下の設定を記述して保存（ファイルが存在しない場合は新規作成する）
|
1 2 |
[boot] systemd=true |
5-4. Ubuntuを再起動
先程と同じく、PowerShellからコマンドを送り、WSLを停止します。
|
1 |
wsl --shutdown |
Ubuntuを起動し、例によってPostgreSQLを停止。
|
1 2 3 |
# 1. Ubuntuを起動し、パスワードを入力 # 2. PostgreSQLサービスを停止 sudo service postgresql stop |
5-5. Snapdサービスの状態を確認
今度は systemd 経由でサービスが起動しているはずです。
Ubuntuターミナルで実行。
|
1 2 3 4 |
# systemctlで状態を確認 sudo systemctl status snapd # ここで状態が 'active (running)' であればOK |
5-6. サービス状態の確認結果
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
[sudo] password for tsujisaka: * Starting PostgreSQL 12 database server [ OK ] * Starting PostgreSQL 14 database server [ OK ] tsujisaka@DESKTOP-7GBREKH:~$ sudo service postgresql stop * Stopping PostgreSQL 12 database server [ OK ] * Stopping PostgreSQL 14 database server [ OK ] tsujisaka@DESKTOP-7GBREKH:~$ sudo systemctl status snapd ←★snapdのステータス確認 System has not been booted with systemd as init system (PID 1). Can't operate. Failed to connect to bus: Host is down |
ステータスは active にならず。うーむ、まだダメなようです。
最後に表示されているエラーメッセージは
|
1 2 |
System has not been booted with systemd as init system (PID 1). Can't operate. Failed to connect to bus: Host is down |
WSL2 の設定ファイル /etc/wsl.conf を編集した後、「WSLの完全シャットダウン」が正しく行われなかった、あるいは /etc/wsl.conf ファイルに記述ミスがあったため、変更が適用されていないことを示しています。
なんでや。
6. Systemd設定の確認と強制適用
WSL2 環境で systemd を確実に有効化するために、以下の手順をもう一度実行して、設定を適用させます。
6-1. /etc/wsl.conf の内容確認
設定ファイルが正しく記述されているかを確認します（Utuntuターミナルで実行）。
表示される内容が、[boot] セクションと systemd=true の行で構成されていることを確認してください。
|
1 2 3 4 |
cat /etc/wsl.conf [boot] systemd=true |
ここは問題なかったようです。
6-2. WSLの完全シャットダウン
設定を適用し、WSL環境をリフレッシュするため、WSL全体を停止します。
PowerShellで実行します。
|
1 2 |
# WSL全体のシャットダウン wsl --shutdown |
6-3. Ubuntuの起動
Ubuntuを起動。
私の環境ではPostgreSQLが自動起動しているので、邪魔をするかもしれないPostgreSQLを停止します。
|
1 2 3 |
# 1. Ubuntuを起動し、パスワードを入力 # 2. PostgreSQLサービスを停止 sudo service postgresql stop |
6-4. Systemdが有効になったかを確認
Ubuntuターミナルで実行。
|
1 2 |
# PID 1のプロセス名を確認 ps -p 1 -o comm= |
ここで systemd と表示されれば成功です。もし init などと表示された場合は、まだ設定が適用されていません。
ダメでしたー。
なんでや。
7. 再度確認と強制実行
プロセス名が出で来ない状態で無理やり sudo do-release-upgrade コマンドを実行しましたが、案の定うまく行きません。
だんだん面倒くさくなってきた。。。
|
1 2 3 4 5 6 7 |
sudo do-release-upgrade Aborting Reading package lists... Done Building dependency tree... Done Reading state information... Done === Command terminated with exit status 1 (Fri Nov 7 18:59:51 2025) === |
sudo do-release-upgrade を実行した後に、特にエラーメッセージが表示されず Aborting とだけ表示されてプロセスが終了（終了ステータス 1）している状況です。
これは、アップグレード前の重要なパッケージや依存関係のチェックの段階で、まだ何らかの解決すべき問題が残っていることを示唆しています。
以前の問題（パッケージの未更新やSnapd/PostgreSQL）とは別の、隠れた依存関係の問題である可能性が高いです。
7-1. パッケージ管理システムのクリーンアップ
この「Aborting」問題を解決するために、パッケージ管理システムの強制的なクリーンアップとより詳細なログの確認を行います。
パッケージのリストやキャッシュに不整合が残っている場合、アップグレードが中断することがあります。
Ubuntuターミナルで実行します。
|
1 2 3 4 5 6 7 8 9 10 |
# 1. ダウンロードしたパッケージキャッシュを削除 sudo apt clean # 2. 破損した依存関係を修復 (重要) sudo apt install -f # 3. アップデートを再度実行し、依存関係を解決 sudo apt update sudo apt upgrade sudo apt autoremove |
7-2. WSLの完全シャットダウン
パッケージのクリーンアップと更新を行ったので、必ずWSLをリフレッシュします。
PowerShellで実行。
|
1 |
wsl --shutdown |
7-3. サービスの停止とログ確認（重要）
Ubuntuを起動し、PostgreSQLを停止してから、アップグレードを再実行します。
（Ubuntuターミナルで）PostgreSQLを停止。
|
1 |
sudo service postgresql stop |
（Ubuntuターミナルで） アップグレードを再実行します。
|
1 |
sudo do-release-upgrade |
(ヒント)それでも解決しない場合は、ログの確認を行う
もし再度 Aborting で終了した場合は、アップグレードプロセスが残しているログファイルを確認することで、中断された具体的な理由を知ることができます。
Ubuntuターミナルで実行。
|
1 2 |
# アップグレードログを表示 cat /var/log/dist-upgrade/main.log |
このログの末尾付近に、アップグレードが中断された具体的な原因を示すエラーや警告が記録されているはずです。
ひとまずは、上記7-1 〜 7-3のパッケージのクリーンアップと再実行を試します。
7-4. 途中経過
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
tsujisaka@DESKTOP-7GBREKH:~$ sudo apt clean tsujisaka@DESKTOP-7GBREKH:~$ sudo apt install -f Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages were automatically installed and are no longer required: alsa-topology-conf alsa-ucm-conf libasound2 libasound2-data libcanberra0 libfuse2 libltdl7 libmpdec2 libntfs-3g883 libpython3.8 libpython3.8-minimal libpython3.8-stdlib libtdb1 libvorbisfile3 python3.8 python3.8-minimal sound-theme-freedesktop Use 'sudo apt autoremove' to remove them. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. |
sudo apt install -f を実行した結果、「0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.」と表示されましたので、
パッケージの依存関係に大きな破損は見られず、修復の必要はなかったようです。
これは良い兆候。
この後は、前回ご案内した手順の続きを実行し、残っているかもしれないパッケージを完全に更新した後に、アップグレードを再実行します。
8. アップグレード再開のための最終ステップ
8-1. パッケージの完全更新とクリーンアップ
依存関係修復の必要はなかったものの、念のため残りの更新コマンドを続行し、システムをクリーンな状態にします。
以下を Ubuntuターミナルで実行します。
|
1 2 3 4 5 6 7 8 |
# 1. パッケージリストの再更新 sudo apt update # 2. 残っているパッケージのアップグレード sudo apt upgrade # 3. 不要になったパッケージの削除 (前回表示されたパッケージを削除します) sudo apt autoremove |
8-2. WSLの完全シャットダウン（適用とリフレッシュ）
更新後に必ずWSL全体をリフレッシュします。
PowerShellで実行。
|
1 |
wsl --shutdown |
8-3. サービスの停止とアップグレードの再実行
WSL起動後、PostgreSQLを停止してからアップグレードを再実行します。
Ubuntuターミナルで実行。
|
1 2 3 4 5 6 |
# 1. Ubuntuを起動し、パスワードを入力 # 2. PostgreSQLサービスを停止 sudo service postgresql stop # 3. ディストリビューションアップグレードを再実行します。 sudo do-release-upgrade |
8-4. 再度 Aborting の場合
もし、この手順を実行しても再度 Aborting で終了してしまった場合は、アップグレードが中断された具体的な理由を知るために、以下のログファイルの内容を確認する必要があります。
Ubuntuターミナルで実行。
|
1 |
cat /var/log/dist-upgrade/main.log |
8-4. やはりエラー
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
tsujisaka@DESKTOP-7GBREKH:~$ sudo apt update Hit:1 http://security.ubuntu.com/ubuntu jammy-security InRelease Hit:2 http://archive.ubuntu.com/ubuntu jammy InRelease Hit:3 http://archive.ubuntu.com/ubuntu jammy-updates InRelease Hit:4 http://archive.ubuntu.com/ubuntu jammy-backports InRelease Reading package lists... Done Building dependency tree... Done Reading state information... Done All packages are up to date. tsujisaka@DESKTOP-7GBREKH:~$ sudo apt upgrade Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done The following packages were automatically installed and are no longer required: alsa-topology-conf alsa-ucm-conf libasound2 libasound2-data libcanberra0 libfuse2 libltdl7 libmpdec2 libntfs-3g883 libpython3.8 libpython3.8-minimal libpython3.8-stdlib libtdb1 libvorbisfile3 python3.8 python3.8-minimal sound-theme-freedesktop Use 'sudo apt autoremove' to remove them. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. |
sudo apt update と sudo apt upgrade の結果、「All packages are up to date.」 および 「0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.」 と表示されています。
これは、現在のパッケージがすべて最新の状態であり、ディストリビューションアップグレードの前提条件は満たされていることを示しています。
しかし、前回のやり取りでは、これらの処理後に wsl --shutdown と PostgreSQLの停止を行っても、sudo do-release-upgrade が Aborting で終了していました。
この状況では、パッケージの問題ではなく、アップグレードツールの実行環境、特に前回ご指摘した Snapd/Systemd関連のセットアップの不備が、アップグレードの初期チェックを通過できていない主な原因である可能性が極めて高いです。
9. アップグレード再開のための最終ステップ
9-1. 不要パッケージの削除とシャットダウン
apt upgrade で表示された不要パッケージを削除し、WSL全体をリフレッシュします。
Ubuntuターミナルで実行。
|
1 2 |
# 不要になったパッケージを削除 sudo apt autoremove |
WSL のシャットダウン。
PowerShell で実行。
|
1 2 |
# WSL全体のシャットダウン wsl --shutdown |
9-2. サービスの停止とアップグレードの再実行
WSL 起動後、PostgreSQL の自動起動がアップグレードを妨げるため、必ず停止します。
Ubuntuターミナルで実行。
|
1 2 3 4 5 6 |
# 1. Ubuntuを起動し、パスワードを入力。 # 2. PostgreSQLを停止。 sudo service postgresql stop # 3. ディストリビューションアップグレードを再実行。 sudo do-release-upgrade |
9-3.再度 Aborting の場合：ログの確認
もし、この手順でも Aborting で終了してしまった場合は、アップグレードが中断された決定的な理由を特定するため、ログファイルを確認する必要があります。
ログの確認方法は以下のようにすれば確認可能です。
Ubuntu ターミナルで実行。
|
1 2 |
# アップグレードログの末尾を表示 tail /var/log/dist-upgrade/main.log |
まずは上記の 9-1、9-2 を試します。
10. Ubuntu起動
Ubuntu を起動すると、これまでとは少し違う事が起きました。
|
1 2 |
wsl: Failed to start the systemd user session for 'tsujisaka'. See journalctl for more details. [sudo] password for tsujisaka: |
エラーメッセージっぽいものは出ていますが、これでついに systemd の有効化の設定がWSLに適用され、システムが systemd を使用して起動しようとしていることが確認できました。
やれやれ。
このメッセージは、「systemd 自体は起動したが、ユーザーセッション（tsujisaka ユーザー用の環境）の開始に失敗した」ことを示しています。
これはよくある問題で、多くの場合、ディストリビューションのアップグレード作業には影響しません。
重要なのは、systemd が PID 1 で起動していることであり、これにより snapd などのサービスが正しく機能する基盤が整いました。
11. アップグレード再開のための最終確認と実行
PostgreSQL が起動し、systemd の準備も整った今、最後のステップとしてサービスの停止とアップグレードを再実行します。
11-1. PostgreSQLの停止
systemd のエラーが出ているものの、PostgreSQL サービスは起動しているため、これを停止します。
Ubuntuターミナルで実行。
|
1 |
sudo service postgresql stop |
11-2. アップグレードの再実行
環境は整いましたので、アップグレードを再開します。
systemd のユーザーセッションエラーは、ディストリビューションアップグレードの実行自体を妨げる可能性は低いです。
Ubuntuターミナルで実行。
|
1 |
sudo do-release-upgrade |
もし、今度こそアップグレードプロセスが中断せず、画面に「新しいリリースが利用可能です」といったメッセージや、アップグレードに関する確認画面が表示されたら成功です。
もし再度 Aborting で中断した場合は、前回の指示通り tail /var/log/dist-upgrade/main.log の内容を確認する。
11-3. Abortingで中断したので、ログを確認する
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
Restoring original system state Aborting Reading package lists... Done Building dependency tree... Done Reading state information... Done === Command terminated with exit status 1 (Fri Nov 7 19:07:18 2025) === tsujisaka@DESKTOP-7GBREKH:~$ tail /var/log/dist-upgrade/main.log 2025-11-07 19:07:15,576 DEBUG running Quirks.PostDistUpgradeCache 2025-11-07 19:07:15,765 INFO linux metapackage () not available 2025-11-07 19:07:15,821 DEBUG denylist expr '^postgresql-.*[0-9][0-9].*' matches 'postgresql-12' 2025-11-07 19:07:15,821 DEBUG The package 'postgresql-12' is marked for removal but it's in the removal deny list 2025-11-07 19:07:15,864 ERROR Dist-upgrade failed: 'The package 'postgresql-12' is marked for removal but it is in the removal deny list. To prevent data loss, postgresql packages are not removed automatically during the upgrade. If you are certain you no longer need postgresql-12, you can manually remove it and try the upgrade again.' 2025-11-07 19:07:15,867 DEBUG abort called 2025-11-07 19:07:15,868 DEBUG openCache() 2025-11-07 19:07:18,346 DEBUG /openCache(), new cache size 106700 |
アップグレードが中断されていた決定的な原因がログに明確に記録されていました。
|
1 2 3 |
`ERROR Dist-upgrade failed: 'The package 'postgresql-12' is marked for removal but it is in the removal deny list.` `To prevent data loss, postgresql packages are not removed automatically during the upgrade. If you are certain you no longer need postgresql-12, you can manually remove it and try the upgrade again.'` |
これは、「PostgreSQL 12 パッケージがアップグレード時に削除される予定だが、データ損失を防ぐためのリストに登録されているため、アップグレードプロセスが停止した」ことを意味します。
WSL 2の設定（systemd）の問題は脇に置いておき、この PostgreSQL の問題を解決すれば、アップグレードが成功するはずです。
最終的な解決手順：PostgreSQL 12の削除
アップグレードを続行するには、PostgreSQL 12を意図的に削除し、アップグレードツールが安全に進めるようにする必要があります。
PostgreSQL 12 が不要である、またはすでにデータを PostgreSQL 14 に移行済みであることを確認してから、以下の手順を実行します。
12-1. PostgreSQL 12の削除
PostgreSQL 12に関連するパッケージを削除します。
Ubuntuターミナルで実行。
|
1 2 |
# PostgreSQL 12とその依存関係を削除します sudo apt purge postgresql-12 postgresql-client-12 |
実行中に削除の確認（y/n）があれば、y を入力して進めます。
12-2. PostgreSQLサービスの停止
削除後も、万が一PostgreSQL 14が起動している可能性があるため、安全のため停止します。
Ubuntuターミナルで実行。
|
1 |
sudo service postgresql stop |
12-3. ディストリビューションアップグレードの再実行
PostgreSQL 12という障害物が取り除かれましたので、アップグレードを再実行します。
Ubuntuターミナルで実行。
|
1 |
sudo do-release-upgrade |
この手順で、アップグレードプロセスは依存関係のチェックを通過し、Ubuntu 20.04 から 22.04 LTS へのファイルダウンロードとインストールを開始するはずです。
補足: 再起動の質問について
アップグレードの終盤で、「再起動（リブート）しますか？」と聞かれたら、必ず y を選択してください。
その後、念のため WindowsのPowerShellから wsl --shutdown を実行してから、再度 Ubuntu を起動してください。
13. アップグレードが完了したかどうかの確認
アップグレードが無事に完了し、Ubuntuのバージョンが新しいもの（22.04 LTS）になっているかを確認する方法は簡単です。
主に、下記2つの方法で確認が可能です。
13-1. lsb_release -a コマンドを使用 (推奨)
表示された結果の Description の行や Release の行が以下のようになっていれば、アップグレードは成功です。
|
1 2 3 4 5 6 |
tsujisaka@DESKTOP-7GBREKH:~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 24.04.3 LTS Release: 24.04 Codename: noble |
13-2. /etc/os-release ファイルを参照する方法
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
tsujisaka@DESKTOP-7GBREKH:~$ cat /etc/os-release PRETTY_NAME="Ubuntu 24.04.3 LTS" NAME="Ubuntu" VERSION_ID="24.04" ←★ここ VERSION="24.04.3 LTS (Noble Numbat)" VERSION_CODENAME=noble ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/" SUPPORT_URL="https://help.ubuntu.com/" BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" UBUNTU_CODENAME=noble LOGO=ubuntu-logo |
VERSION_ID="22.04" と表示されていれば、20.04 LTS (Focal Fossa) から 22.04 LTS (Jammy Jellyfish) へのアップグレードは正常に完了しています。
以下はおまけ。
14. 最終的なクリーンアップとPostgreSQLの処理
アップグレードは完了しましたが、最後にシステムをクリーンな状態に保ち、PostgreSQLの環境を整えておきます。
14-1. システムクリーンアップ
アップグレード中に残った古い設定や不要なパッケージを削除します。
|
1 2 |
sudo apt autoremove sudo apt clean |
14-2. PostgreSQL サービスの確認
アップグレード後、PostgreSQLの新しいバージョン（PostgreSQL 16など、24.04で提供されるバージョン）がインストールされ、PostgreSQL 14 はまだ残っているはずです。
PostgreSQL 14 のデータが必要であれば、24.04環境で提供される最新バージョンへデータを移行し、その後、PostgreSQL 14を削除してください。
今回の場合、PostgreSQL環境は不要ですので、後顧の憂いをなくすといった意味も込め、14環境は削除することとします。
もしPostgreSQLをすぐに使用する予定がなければ、サービスを無効化しておくと、起動時のエラーメッセージ (wsl: Failed to start the systemd user session... など) を減らすことができます。
(Systemdが有効な場合)
|
1 2 |
# PostgreSQL 14を無効化（自動起動を停止） sudo systemctl disable postgresql@14-main.service |
さらにおまけ
15. Ubuntuを起動したときの動作について
これまでは、Ubuntuを起動するとすぐさま、ルートユーザのパスワードを求められていたのですが、今回のバージョンアップ後は、起動すると30秒ほど待たされ、また、ルートパスワードの入力を求められることがなくなりました。
いいのか悪いのかは別として、動作が変わったのが気持ち悪いので調査したところ、下記のような原因でした。
15-1. 起動が遅くなった件
原因： systemd サービスの初期化
WSL2で systemd を有効にすると、従来の init システムよりも多くのサービス（Snapd、ユーザーセッション、各種システムデーモンなど）が起動時に並行して初期化されます。
この systemd のサービス初期化プロセスは、Windows 側の WSL2 カーネルが安定して起動するのを待つ必要もあるため、起動時間が長くなります。
以前の init ベースの起動よりも時間がかかるのは、正常な動作です。
対処法： この待ち時間を劇的に短縮する設定はありませんが、システムが安定して動作している証拠として許容されることが多いです。
15-2. パスワードを入力しなくなった件
原因： /etc/wsl.conf の設定
これは、以前の起動プロセスで設定されていた 自動ログイン機能 が、systemd の有効化によって再度機能し始めたためと考えられます。
systemd が有効になる前のWSL環境では、通常、/etc/wsl.conf ファイルに以下の設定がある場合、自動ログインが有効になります。
|
1 2 |
[user] default=tsujisaka |
対処法：自動ログインを解除し、パスワード入力を有効にする
セキュリティを重視し、起動時にパスワード入力を求めるようにするには、WSLの設定を変更する必要があります。
15-2-1. /etc/wsl.conf の編集（Ubuntuターミナルで実行）
WSLの設定ファイルを開きます。
|
1 |
sudo vi /etc/wsl.conf |
[user] セクションを探し、default=... の行を削除するか、行頭に # をつけてコメントアウトします。
15-2-2. WSLの完全シャットダウン
設定変更を適用するために、WSLを完全に終了します。（PowerShellで実行）
|
1 |
wsl --shutdown |
その後、Ubuntuを再起動すると、以前のようにパスワードの入力を求められるようになるはずです。
もし [user] セクションが存在しない場合は、WSLの起動設定が別の場所（例: レジストリ）に格納されている可能性がありますが、通常は wsl.conf の設定を削除することでパスワード入力が復活します。
以上、ながながとなってしまいましたが、ひとまずWSL内のUbuntuのアップグレードでした。
お疲れ様でした。
参考にしたサイト等
