wsl_update_x64.msi 装不上、要不要下？Windows 11 装 WSL2 的正确顺序与离线包真实适用范围

2026-09-07 WSL2 Windows 离线安装 Ubuntu 踩坑运维排错运维实践

wsl_update_x64.msi 装不上、要不要下？

如果你是在搜 wsl_update_x64.msi、wsl_update_x64.msi 下载、Ubuntu2204-221101.AppxBundle 这类关键词进来的，先停一下——你很可能正在照一份过时的教程操作。

这类教程的核心思路是："别用官方一键安装（怕微软下载慢），改成开功能 + 手动下离线包 + 本地装"。

听起来稳妥，实际上在现在的 Windows 上几乎必然翻车。我按这条路完整走过一遍，把结论和真实数据写在这里。

一、结论先行

问题	结论
`wsl_update_x64.msi` 要不要下？	新版 Windows 上不需要，且大概率装不上
正确装法	`wsl --update` → `wsl --set-default-version 2` → `wsl --install -d Ubuntu-22.04`
离线包什么时候有用？	仅在你完全无法访问微软 CDN / 商店的纯内网环境
那我搜的这个包还有意义吗？	有——但用途是纯内网离线部署，不是加速

先对号入座：你搜到的这些名字，分别是什么

搜 WSL2 离线安装的人，手里拿到的文件名五花八门。下面这张表按实际搜到的名字归类——先确认你手上的是哪一类，再决定要不要继续：

你搜到 / 拿到的名字	它到底是什么	要不要下	正确做法
`wsl_update_x64.msi`	2021 年给 Windows 10 用的 WSL2 内核补丁包（本地实测 16.3 MB）	❌ 新版系统不需要，且装不上	`wsl --update`
`wsl_x64.msi`、`WSL2 kernel update package x64 msi`	同上，只是命名不同	❌	同上
`wsl.2.7.12.0.x64.msi`、`wsl.2.7.11.0.x64.msi`、`wsl.2.7.10.0.x64.msi`、`wsl.2.7.8.0.x64.msi`、`wsl.2.4.12.0.x64.msixbundle`、`wsl.2.3.26.0_x64.msixbundle` 等	内核更新包的各个历史版本（搜索里出现的版本号很多）	❌ 不用手动挑版本	`wsl --update` 会自动取匹配你系统的版本
`Microsoft.WSL_x64.msixbundle`	新版 WSL 应用包（商店分发形态）	⚠️ 仅纯内网	商店安装或 `wsl --update`
`Ubuntu2204-221101.AppxBundle`	Ubuntu 22.04 的商店应用包（本地实测 1.04 GB）	⚠️ 不能喂给 `--from-file`	双击装；要离线导入请改用下方 rootfs
`Ubuntu2204.appx`、`Ubuntu2204 _x64.appx`、`ubuntu_2204.appx`、`Ubuntu-22.04.appxbundle`	同一家族的别称 / 内部包	同上	同上
`ubuntu2204.tar`、`ubuntu2204.rootfs`、`rootfs.tar.gz`	真正的 Linux 根文件系统归档	✅ 离线就用它	见「第六节」官方途径 + 校验 + `--import`

一句话判断：带 msi / msixbundle / Appx / appxbundle 的都是 Windows 应用包，
只有 .tar / .tar.gz 的 rootfs 才是 wsl --import / --from-file 能吃的。

高频疑问速答（按真实搜索词整理）

你在搜	答案
`wsl_update_x64.msi是不是在线更新包`	不是。它是离线内核安装包，且是 2021 年的老版本；在线更新请用 `wsl --update`
`Ubuntu2204.appx 有多大` / `WSL 版 Ubuntu-22.04 有多大`	商店包（AppxBundle）实测 1.04 GB；而官方 rootfs 只有 325 MB——差 3 倍多
`wsl --install 太慢`	先看第三节「时间账」：多数情况是网络问题，可错峰重试；纯内网走第六节离线方案
`wsl出现...ended prematurely`	第二节详解：这是新版系统拒绝安装旧内核包的正常行为，不是故障
`win11 wslregisterdistri` 报错	坑 3：系统功能未开或未重启就装 → 开功能后必须重启
`ubuntu2204.tar 下载` / `ubuntu2204 rootfs`	第六节：Ubuntu 官方 cloud-images 直链 + SHA256 校验

二、为什么 `wsl_update_x64.msi` 会装不上

双击运行后，安装向导跑几秒就退出，常见提示：

Windows Subsystem for Linux Update SetupWizard ended prematurely

这不是你的系统坏了，也不是包下载坏了。

原因是：wsl_update_x64.msi 是微软在 2021 年为 Windows 10 提供的 WSL2 内核补丁包。
Windows 11（以及较新的 Windows 10）出厂已内置 WSL2 内核。
wsl.exe 检测到系统内核版本比这个老包更新时，会直接拒绝重复安装。

所以在新系统上：这个包不仅不需要，而且必然失败。

该做什么替代它

wsl --update
wsl --status

wsl --update 走的是官方在线升级通道，拿到的永远是匹配你系统的当前版本。
很多老教程从头到尾假设"用离线 MSI 装内核"，完全没提 wsl --update 这一步——它们的知识还停在离线包时代。

三、正确的安装顺序（三行）

以管理员身份打开 PowerShell：

# 1) 升级 WSL（替代老 MSI）
wsl --update

# 2) 设默认版本为 2
wsl --set-default-version 2

# 3) 安装发行版
wsl --install -d Ubuntu-22.04

就这三行。自动下载、注册 Ubuntu 22.04，弹出终端设用户名密码，一气呵成。

反直觉的一点：在线安装的下载速度通常完全可接受，
甚至比提前去下那个 1 GB 的离线包更快——因为离线包来自 CDN，而 wsl --install 走的是同一批官方源。
"离线更稳"这个假设，在能连微软 CDN 的前提下不成立，反而多引入一层兼容性坑。

四、四个高频坑

坑 1：`AppxBundle` 不能喂给 `--from-file`

wsl --install --from-file .\Ubuntu2204-221101.AppxBundle   # ❌ 报错

--from-file 只接受 tar 格式的根文件系统（rootfs），不认 .AppxBundle 这种 Windows 应用包。

而且老教程里的文件名经常对不上：它说"双击 Ubuntu_2204.0.10.0_x64.appx"，
实际拿到的是 Ubuntu2204-221101.AppxBundle，里面才是 Ubuntu_2204.1.7.0_x64.appx——版本号、文件名、格式全都不一样，照抄必翻车。

AppxBundle 的正确装法只有两种：资源管理器双击，或 Add-AppxPackage。

坑 2：把 `AppxBundle` 改名成 `.tar.gz` 冒充 rootfs

网上有些地方会把 AppxBundle 直接改名成 .tar.gz 来"喂" --from-file。
这行不通——AppxBundle 是 MSIX 容器，不是 tar 归档，改名改不了内部格式。

判断方法：真正的 rootfs 归档用压缩软件打开，里面是 Linux 目录结构（/bin、/etc、/usr…），
或内部含有 install.tar.gz。

坑 3：系统功能没开就硬装

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

执行后必须重启再继续。没重启就装，是 WslRegisterDistribution failed 的高频原因。

坑 4：`wsl -l -v` 显示 VERSION 为 1

说明该发行版跑在 WSL1 上，转换它：

wsl --set-version Ubuntu-22.04 2

五、离线包到底什么时候才需要

只有一种场景：完全无法访问微软 CDN / 商店的纯内网环境。

如果确实属于这种场景，请注意：

别用 2021 年那套老包（wsl_update_x64.msi 在新系统上不兼容）；
应使用新版离线包，例如 Microsoft.WSL_x64.msixbundle，
以及 AppxBundle 内部解出的 install.tar.gz（这才是 --from-file 能吃的真 rootfs）；
拿到文件后务必校验，确认完整未被二次打包。

实测文件特征（供内网离线部署比对）

以下为本地实际文件的精确体积与 SHA256（实测值）：

wsl_update_x64.msi
  大小   : 17,104,896 字节（16.3 MB）
  SHA256 : 4d09c776c8d45f70a202281d18e19be1118f53159b0c217a5274a31ce18525fe

Ubuntu2204-221101.AppxBundle
  大小   : 1,116,834,851 字节（1065.1 MB，约 1.04 GB）
  SHA256 : 6ad6d88763451a50f98f2469ce80464d666204c08d07f8f6a89e0d5ca05b097a

⚠️ 一个极易混淆的坑：rootfs 归档与 AppxBundle 体积都在 1 GB 量级，
文件名又都带 Ubuntu2204，非常容易搞混或被覆盖。

我就踩过：本地一个名为 ubuntu-22.04-rootfs.tar.gz 的文件，
实测 SHA256 竟与 Ubuntu2204-221101.AppxBundle 完全一致——
说明它在下载或后续整理过程中被覆盖成了 AppxBundle 的内容，
并不是真正的 tar 归档。这类文件喂给 --from-file 必定失败。

实测：拿 AppxBundle 当 rootfs 导入，会发生什么

我在本机做了对照验证，直接用 wsl --import 导入一个名为 *.tar.gz、
实际却是 AppxBundle 内容的文件：

wsl --import Ubuntu-Test D:\WSL\Ubuntu-Test .\ubuntu-22.04-rootfs.tar.gz --version 2

实际输出（原文照录）：

导入的文件不是有效的 Linux 分发。
错误代码: Wsl/Service/RegisterDistro/WSL_E_NOT_A_LINUX_DISTRO

失败的实例没有被注册，也不会影响已装好的其它发行版——可以放心试。

这个报错很有迷惑性：它只说"不是有效的 Linux 分发"，不告诉你文件其实是 Windows 应用包。
所以很多人会以为是文件下载坏了，反复重下，浪费几小时。

反例：真归档导入是什么样

同一台机器，用一份真正的 tar 归档导入：

wsl --import Ubuntu-Test D:\WSL\Ubuntu-Test .\ubuntu-2204-offline.tar --version 2

操作成功完成。

wsl -d Ubuntu-Test -- cat /etc/os-release | head -2

PRETTY_NAME="Ubuntu 22.04.5 LTS"
NAME="Ubuntu"

导入耗时约 30 秒（5.3 GB），新实例与原有发行版并存，互不影响。

📎 附注：已有环境怎么导出成离线包（备份 / 迁移用）

本节是附注，不影响主线结论。 要公开分发或在新机器全新安装，请用官方原版镜像。
下面的方法只适合自用——把你现有的 WSL 环境打包，用于备份或迁移到你自己的另一台机器。

如果你机器上已经有一个能正常运行的 WSL 发行版，可以直接把它导出来：

# 导出（tar 归档，实测 5.3 GB 约 70 秒）
wsl --export Ubuntu-22.04 D:\WSL\ubuntu-2204-offline.tar

# 在任意机器导入
wsl --import Ubuntu-Test D:\WSL\Ubuntu-Test D:\WSL\ubuntu-2204-offline.tar --version 2

为什么比网上下载靠谱：

对比项	网上找的离线包	`wsl --export` 导出
格式是否正确	要自己鉴别（可能拿到 AppxBundle 冒充的）	一定是标准 tar
版本是否匹配	可能是 2021 年的老包	就是你当前在用的
能否直接导入	常失败	一定成功（亲测）
环境是否可用	全新，要重配	连你装好的软件、配置都在

⚠️ 注意：导出包含你的个人文件、项目代码、数据库内容。
它只适合自用备份 / 迁移到你自己的另一台机器，不要公开分享到网盘。
公开分发请用官方原版镜像——那才是本文推荐的主线做法。

10 秒自检法：看文件头，别看后缀

比算哈希更快的方法——直接看文件前 4 个字节：

$b = [System.IO.File]::ReadAllBytes(".\ubuntu-22.04-rootfs.tar.gz")[0..3]
($b | ForEach-Object { $_.ToString("X2") }) -join " "

输出	真实格式	能否 `--import`
`1F 8B 08 …`	gzip → tar 归档	✅ 可以
`50 4B 03 04`	ZIP / MSIX（AppxBundle）	❌ 必然失败

后缀可以随便改，文件头改不了。下载完先看这一眼，能省掉后面几小时的排查。

规避文件被覆盖的三条习惯

上面这个坑我踩过，根因是两个 1 GB 大文件同名不同目录，在下载或整理时串了。
后来养成三个习惯：

下载完成后立刻算哈希或看文件头，确认格式对得上；
用压缩软件打开确认：内部是 bin/etc/usr 这类 Linux 目录结构，
或内部含 install.tar.gz；
两个大文件分目录存放，不要放同一目录顺手改名。

校验命令：

Get-FileHash .\wsl_update_x64.msi -Algorithm SHA256
Get-FileHash .\Ubuntu2204-221101.AppxBundle -Algorithm SHA256

六、如果你确实需要离线：正确做法（实测可行）

先说清楚：能联网就别折腾离线（三行命令的事）。但在纯内网、批量部署、
或者要给多台同配置机器装的场景下，离线是刚需——这时请按下面的路径走。

第一步：拿官方 rootfs，别拿 AppxBundle

Ubuntu 官方在 cloud-images 站点提供 WSL 专用 rootfs：

https://cloud-images.ubuntu.com/wsl/jammy/current/
   ├── ubuntu-jammy-wsl-amd64-ubuntu22.04lts.rootfs.tar.gz   ← x64 机器选这个
   └── ubuntu-jammy-wsl-arm64-ubuntu22.04lts.rootfs.tar.gz

两个获取途径（任选，内容相同）：

途径	地址	适用
官方直链（首选）	`https://cloud-images.ubuntu.com/wsl/jammy/current/ubuntu-jammy-wsl-amd64-ubuntu22.04lts.rootfs.tar.gz`	能直连官方源；实测国内访问速度可接受（325 MB，几分钟）
网盘镜像（国内加速）	https://pan.baidu.com/s/1uFXU-S8MdtG-Q-cUVWpEgQ?pwd=tan7 （提取码 `tan7`）	官方源慢或连不上时

关于网盘镜像：文件为 Ubuntu 官方原版，未做任何修改，本站仅提供国内下载加速。
无论从哪个途径下载，都必须做第二步的 SHA256 校验——校验通过才能证明文件与官方逐字节一致。
如权利方有异议可联系删除。

jammy = 22.04，noble = 24.04。
注意：写这篇文章时 24.04（noble）目录下只有 manifest，没有 rootfs 归档，
要离线装 24.04 得另找途径——这也是我推荐先用 22.04 的原因之一。

第二步：用官方 SHA256 校验（关键）

目录下有 SHA256SUMS 文件，下载后逐字符比对，一致才说明文件与官方逐字节相同：

Get-FileHash .\ubuntu-jammy-wsl-amd64-ubuntu22.04lts.rootfs.tar.gz -Algorithm SHA256

实测一份（2025-03 版本，325 MB）：

大小   : 341,130,963 字节（325.3 MB）
文件头 : 1F 8B 08 00          ← gzip/tar，正确
SHA256 : 1483cc5c1dce13064f774834cbffdff226559fd522a67a381a8ea77d63fb4109

版本更新后哈希会变，请以你下载时目录下的 SHA256SUMS 为准。

第三步：导入

wsl --import Ubuntu-Offline D:\WSL\Ubuntu-Offline .\ubuntu-jammy-wsl-amd64-ubuntu22.04lts.rootfs.tar.gz --version 2

实测输出：

操作成功完成。        # 耗时约 8 秒

wsl -d Ubuntu-Offline -- cat /etc/os-release | head -3

PRETTY_NAME="Ubuntu 22.04.5 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"

根目录结构完整（bin / etc / home / lib …），可直接使用。

📌 --import 装出来的实例默认是 root 用户，不像在线安装会引导你建普通账号。
需要的话自己加一个：
bash useradd -m -s /bin/bash <用户名> && passwd <用户名>

离线 vs 在线：什么时候该用哪个

你的情况	建议
能连微软 CDN（绝大多数人）	直接在线装，别折腾离线包
下载确实很慢但不至于断	在线装；可错峰重试
纯内网 / 完全访问不到官方源	离线，用上面的官方 rootfs
需要装多台同配置机器	官方 rootfs 导入一次，或 `wsl --export` 分发到自己的机器

一笔真实的时间账

为了把"离线到底能不能走通"这件事搞清楚，我实际做了这些事：

#	动作	耗时	结果
1	按老教程下载 `Ubuntu2204-221101.AppxBundle`（1.1 GB）	很久	❌ 安装出错
2	又下了一个自称 rootfs 的文件（1.1 GB）	很久	❌ 导入报 `WSL_E_NOT_A_LINUX_DISTRO`（实为 AppxBundle）
3	不耐烦改用 `wsl --install -d Ubuntu-22.04`	几分钟	✅ 一次成功，比下离线包还快
4	最后从 Ubuntu 官方 cloud-images 下真正的 rootfs（325 MB）	几分钟	✅ 导入成功，8 秒

结论要分两句说：

① 走错路的成本是实打实的——前两步花掉两个 1 GB 的下载时间，全是无用功，
根源在于"老教程给的那个包根本不是 --import 能吃的格式"。

② 走对路其实很便宜——官方 rootfs 只有 325 MB（不是 1.1 GB），
导入只要 8 秒。所以"离线"本身不慢、也不可怕，可怕的是照着老教程下了错的东西。

离线真正的适用场景只有一个：完全访问不到官方源的内网。
不属于这种场景，wsl --install 三行命令就够了。

小结

wsl_update_x64.msi 在新版 Windows 上不需要，装不上是正常拒绝，不是故障；
正确顺序只有三行：wsl --update → --set-default-version 2 → --install -d；
AppxBundle 不能喂 --from-file，改名成 .tar.gz 也不行；
离线包只在纯内网有价值；真需要时用 Ubuntu 官方 rootfs（325 MB，实测导入 8 秒），
别用 AppxBundle，下完先对 SHA256；
遇到教程与你的系统对不上时——以官方文档和你自己系统的报错为准，不要强行兼容。

本文环境：Windows 11 / WSL2 / Ubuntu 22.04
文件体积与 SHA256 为本地实测值；WSL 安装方式以微软官方文档为准。

延伸阅读：

本文讲的是「离线包怎么选、怎么校验」。如果你想知道当初是怎么一步步踩进这些坑的（含 wsl --update 前置、换源 DEB822 等细节），
见别再被过时教程坑了：Windows 11 安装 WSL2 + Ubuntu 22.04 完整踩坑实录。
装的过程中报错了？见 WSL2 安装失败排查：ended prematurely、WslRegisterDistribution 与「装太慢」的成因和对策——
四个高频报错的判定要点与修复命令。

← 返回博客

wsl_update_x64.msi 装不上、要不要下？Windows 11 装 WSL2 的正确顺序与离线包真实适用范围