WindowsでWSLのUbuntuが再起動後に起動しないときは、削除や再インストールの前に、まず Windows 側の WSL 機能と仮想化、次に WSL 本体の更新、最後に Ubuntu 個別設定を切り分けるのが最短です。wsl --status と wsl -l -v で状態を見て、wsl --shutdown と wsl --update を実行し、それでも戻らなければ Windows 機能、ユーザー、LocalState、.wslconfig / wsl.conf を確認します。 (Microsoft Learn)
急ぎの開発環境ほど、再起動後に Ubuntu が開かないと焦って再インストールしがちです。ですが、実際は「Windows Update のあとに WSL 機能が外れた」「BIOS の仮想化が無効」「直前に変えた WSL 設定が再起動で反映された」といった、戻せる原因が少なくありません。この記事では、起きやすい条件、確認する設定、更新や権限の影響、そしてデータを消しにくい復旧手順まで、実務向けに整理します。
WindowsでWSLのUbuntuが再起動後に起動しないときに、まず見るべき症状
再起動後の見え方ごとに、最初の一手を決めると遠回りしません。以下は Microsoft Learn のトラブルシューティングと基本コマンドをもとにした、現場向けの切り分け表です。 (Microsoft Learn)
| 症状 | 可能性が高い原因 | 最初の一手 |
|---|---|---|
wsl コマンド自体が認識されない | WSL 機能が無効、または Windows 側のコンポーネント不整合 | WSL 機能の有効状態を確認する |
wsl -l -v では Ubuntu が見えるのに起動しない | Ubuntu 側の設定、既定ユーザー、systemd 設定の問題 | wsl -d Ubuntu --user root で切り分ける |
0x80370102 など仮想化系のエラーが出る | BIOS の仮想化、Virtual Machine Platform の無効化 | BIOS と Windows 機能を確認する |
| 「インストールされたディストリビューションがありません」と出る | 別ユーザー、組み込み Administrator で起動している | 元の Windows ユーザーで開き直す |
| 仮想ディスク関連のエラーが出る | Ubuntu の LocalState が圧縮または暗号化されている | LocalState のプロパティを確認する |
なお、古い記事でよく見る LxssManager は、Store 版 WSL では WSLService に置き換えられています。サービス名で調べるときに、ここで迷いやすいです。 (Microsoft Learn)
まずは3分でできる復旧手順
状態を確認する
最初に PowerShell かコマンド プロンプトを開き、次の 3 つを確認します。
wsl --status
wsl --version
wsl -l -vwsl --status は WSL 全体の状態、wsl --version は WSL 本体とコンポーネントのバージョン、wsl -l -v はインストール済みディストリビューションの状態と WSL 1/2 を表示します。ここで Ubuntu が一覧に出るかどうかで、「WSL 全体の問題」か「Ubuntu だけの問題」かがほぼ分かれます。 (Microsoft Learn)
Ubuntu ではなく Ubuntu-22.04 のような名前で登録されていることもあるので、以降のコマンドは一覧に出た名前をそのまま使うのが安全です。
WSL を完全停止して更新する
次に、WSL をいったん止めてから更新します。
wsl --shutdown
wsl --update
wsl -d Ubuntuwsl --shutdown は WSL 2 の軽量 VM を含めて停止し、wsl --update は WSL 本体を最新化します。再起動後だけ起動しないケースでは、更新不整合や一時的なハングが原因のことがあり、この手順で戻ることがあります。 (Microsoft Learn)
もし wsl --update で「この更新プログラムは、Linux 用 Windows サブシステムを搭載したマシンにのみ適用されます」と出るなら、WSL 機能自体が無効、あるいは再起動不足の可能性があります。次の Windows 機能確認に進むのが早いです。 (Microsoft Learn)
Ubuntu だけの問題かを root で切り分ける
Ubuntu だけ起動しないなら、既定ユーザーを介さずに起動してみます。
wsl -d Ubuntu --user root--user で指定ユーザーとして起動できます。root では入れるのに通常起動で失敗するなら、WSL 本体よりも Ubuntu 側の設定を疑うべきです。たとえば、直前に systemd を有効にした、/etc/wsl.conf を触った、既定ユーザー側の起動設定を変えた、というケースです。これは「Windows 側の故障」ではなく「Ubuntu 側の起動条件の問題」である可能性が高い、という切り分けに使えます。 (Microsoft Learn)
原因別に見る、再起動後に起動しなくなる典型パターン
Windows Update のあとに WSL 機能が無効になった
再起動後に急に起動しなくなったとき、意外と多いのがこれです。Microsoft Learn でも、Windows Update 後に WSL 機能が無効になる可能性があると案内されています。 (Microsoft Learn)
確認は管理者権限の PowerShell で行います。
Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
Get-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatformWSL 機能の確認には Microsoft-Windows-Subsystem-Linux、WSL 2 側の土台には VirtualMachinePlatform を見ます。どちらかが Disabled なら、Ubuntu 以前に Windows 側の準備が足りていません。 (Microsoft Learn)
無効なら、次で再有効化します。
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestartその後、Windows を再起動してから、もう一度 wsl -l -v を確認してください。WSL 2 を使うには Virtual Machine Platform と仮想化機能が必要です。 (Microsoft Learn)
BIOS の仮想化が無効になっている
0x80370102 など、仮想化まわりのエラーは BIOS 側の設定が本命です。Microsoft Learn でも、WSL 2 の利用には BIOS 内で仮想化が有効であることを確認するよう案内しています。 (Microsoft Learn)
ありがちなのは、次のようなケースです。
- BIOS 更新後に設定が初期化された
- 会社支給 PC でセキュリティ設定が変更された
- Windows 側では WSL 機能が有効でも、BIOS で Intel VT-x / AMD-V が無効
この場合は Windows の再設定だけでは直らず、BIOS 側の有効化が必要です。Windows 機能が正しいのに WSL 2 が立ち上がらないなら、ここを優先して確認してください。 (Microsoft Learn)
.wslconfig や WSL Settings の変更が再起動で反映された
「昨日までは開いていたのに、再起動したら起動しない」というときは、直前に変えた WSL 設定が再起動で効き始めた可能性があります。Microsoft Learn では、.wslconfig の変更は wsl --shutdown や再起動後に反映されることがあると説明しています。 (Microsoft Learn)
特に疑うべきなのは、%UserProfile%\.wslconfig に入れた次のような設定です。
memoryprocessorsnetworkingModekernelsafeModeswap
.wslconfig は WSL 2 全体に効くグローバル設定で、/etc/wsl.conf はディストリビューション単位です。Ubuntu だけおかしいなら wsl.conf、すべてのディストリビューションでおかしいなら .wslconfig を先に疑うと切り分けが速いです。Microsoft Learn でも、.wslconfig はユーザープロファイル配下の任意ファイルで、見つからない場合や書式が正しくない場合は設定を適用せず通常起動すると説明されています。したがって、原因調査としては一時的に .wslconfig を .wslconfig.bak に退避し、既定値で試すのが実務的です。 (Microsoft Learn)
最近の環境では、手で編集するよりも Start メニューにある WSL Settings から戻すほうが安全です。Microsoft も .wslconfig を直接編集するより、WSL Settings での変更を推奨しています。 (Microsoft Learn)
systemd を有効化した直後におかしくなった
Ubuntu で systemd を有効化したあと、再起動や wsl --shutdown 後に挙動が変わることがあります。公式手順では /etc/wsl.conf に次を追加します。
[boot]
systemd=trueこの変更を有効にするには、WSL を閉じたあとに wsl.exe --shutdown が必要です。また、Ubuntu / Debian / Kali Rolling では systemd パッケージだけでなく systemd-sysv も必要とされています。つまり、設定だけ入れて必要なパッケージが足りないと、再起動後に起動条件が変わって問題が表面化する可能性があります。 (Microsoft Learn)
直前に systemd=true を入れたなら、まずは safe mode か root 起動で入り、設定を戻すか、必要なパッケージを確認してください。
sudo apt-get update -y && sudo apt-get install systemd systemd-sysv -yWindows 11 なら safe mode で救出できることがある
Windows 11 かつ WSL 0.66.2 以降では、.wslconfig の safeMode=true を使って、機能を絞った状態で回復を試せます。これは Microsoft Learn でも「不適切な状態にあるディストリビューションを回復するため」に用意された設定です。 (Microsoft Learn)
%UserProfile%\.wslconfig に次を入れます。
[wsl2]
safeMode=true保存後に次を実行します。
wsl --shutdown
wsl -d Ubuntusafe mode で起動できたら、/etc/wsl.conf や不要な起動処理を見直し、復旧後は safeMode=true を外してください。常用設定ではなく、あくまで回復用です。 (Microsoft Learn)
ユーザーや権限が変わっていて、別環境を見ている
再起動後に「Ubuntu が消えた」と感じても、実際は別の Windows ユーザーで開いているだけのことがあります。Microsoft Learn でも、Error: Linux 用 Windows サブシステムにインストールされたディストリビューションがありません というケースで、別ユーザーや組み込み Administrator を使っていないか確認するよう案内しています。 (Microsoft Learn)
特に引っかかりやすいのは次の場面です。
- 普段のユーザーではなく、別の管理者アカウントでターミナルを開いた
- 右クリックの「別のユーザーとして実行」を使った
- 組み込み Administrator で作業している
再インストール前に、普段 Ubuntu を使っていた Windows アカウントで wsl -l -v を実行し直す のが先です。ここを飛ばすと、正常な Ubuntu を自分で壊すことがあります。 (Microsoft Learn)
Ubuntu の LocalState が圧縮・暗号化されている
再起動後から仮想ディスク系のエラーが出るなら、Ubuntu の LocalState フォルダーの属性も要確認です。Microsoft Learn では、仮想ハードディスクは圧縮・暗号化・スパースでは扱えないため、%LocalAppData%\Packages\CanonicalGroupLimited... 配下の LocalState の圧縮や暗号化を外すよう案内しています。 (Microsoft Learn)
確認手順は次の通りです。
- エクスプローラーで
%LocalAppData%\Packages\を開く CanonicalGroupLimited...から始まる Ubuntu のフォルダーを探すLocalStateを右クリックして プロパティ を開く- 詳細設定 で「ディスク領域を節約するために内容を圧縮する」「内容を暗号化してデータをセキュリティで保護する」を外す
- 適用範囲は このフォルダーのみ を選ぶ
ユーザープロファイル全体を圧縮している PC で起きやすいので、ディスク節約設定を見直した直後なら特に疑ってください。 (Microsoft Learn)
Windows 自体が仮想マシンなら nested virtualization も確認する
社内 VDI、Hyper-V、VMware、Azure VM 上の Windows で WSL 2 を使っているなら、親側で nested virtualization が有効である必要があります。Microsoft Learn の FAQ でも、仮想マシンで WSL 2 を使うには nested virtualization を有効にする必要があると案内されています。 (Microsoft Learn)
物理 PC では問題ないのに、会社の仮想デスクトップだけ再起動後に Ubuntu が上がらないなら、Windows 側ではなく 仮想化基盤の設定変更 を疑うべきです。利用者権限で直せないことも多いため、このケースはインフラ担当への連携が早道です。 (Microsoft Learn)
Ubuntu を消さずに復旧したいときの手順
まずは export を取る
wsl -l -v で Ubuntu の登録が見えているなら、危ない操作の前にエクスポートを試す価値があります。Microsoft Learn の基本コマンドと FAQ では、wsl --export でディストリビューションをエクスポートできると案内しています。 (Microsoft Learn)
wsl --export Ubuntu D:\backup\ubuntu.vhdx --vhdこれが取れていれば、最悪でも「今の状態を保管したうえで再構築する」という選択ができます。いきなり unregister するよりはるかに安全です。 (Microsoft Learn)
別名で import して起動確認する
バックアップが取れたら、別名でインポートして復旧確認できます。
wsl --import Ubuntu-Recovered D:\WSL\Ubuntu-Recovered D:\backup\ubuntu.vhdx --vhd--import は別ディレクトリに別名で復元できるので、元の Ubuntu を残したまま検証しやすいのが利点です。「本番の Ubuntu はそのまま、復旧コピーで先に試す」というやり方は、開発環境を壊しにくいです。 (Microsoft Learn)
wsl --unregister は最後に使う
どうしても再インストールしかないときだけ、最後に使います。
wsl --unregister Ubuntuこれは Ubuntu の登録解除とアンインストールで、関連データ、設定、ソフトウェアが失われます。Microsoft Learn でも、unregister はデータが完全に失われる操作として案内されています。export を取る前に実行しない のが鉄則です。 (Microsoft Learn)
それでも直らないときの最後の確認
WSL 機能を有効化し直しても wsl 自体がおかしい、サービスや DLL 周りの不整合が疑わしい、という場合は Windows 側のシステムファイル破損も視野に入ります。Microsoft サポートでも、Windows コンポーネント修復には DISM のあと SFC を実行する手順が案内されています。 (Microsoft サポート)
管理者権限のコマンド プロンプトで次を実行します。
DISM.exe /Online /Cleanup-image /Restorehealth
sfc /scannowこれで Windows 側の破損を修復できることがあります。修復後は Windows を再起動し、WSL 機能の状態と wsl -l -v をもう一度確認してください。 (Microsoft サポート)
迷ったときの優先順位はこの順番
WindowsでWSLのUbuntuが再起動後に起動しない場合、優先順位はかなりはっきりしています。まず wsl --status と wsl -l -v で WSL 全体か Ubuntu 個別か を分ける。次に wsl --shutdown と wsl --update。それでもだめなら WSL 機能、Virtual Machine Platform、BIOS 仮想化 を確認し、直前に変更した .wslconfig や systemd 設定を戻します。Ubuntu が見えているなら、消す前に export を取り、最後の手段として再構築に進むのが安全です。 (Microsoft Learn)
急いでいるほど、再インストールより 切り分けの順番 が効きます。今日やるべきことは、まず wsl -l -v を実行し、Ubuntu が見えるかどうかを確認することです。そこが分かれば、次にやるべき対処はほぼ決まります。
コメント