公司内网环境下安装 WSL2 的正确姿势

事情的起因是想编译 Linux 内核——后续打算做单片机的内核裁剪，先在 PC 上跑通全量编译作为基础。虚拟机太重，双系统切换麻烦，WSL2 是最合适的选择——原生 Linux 内核跑在轻量虚拟机里，文件系统性能够用，还能和 Windows 侧无缝共享文件。

公司内网把微软商店封了，wsl --install 执行到一半就会卡在下载阶段。网上大部分教程都默认你能访问 Store，不适用。折腾了一个下午，踩了几个不明显的坑，记录一下最终跑通的方案。

目标

• WSL2 引擎通过离线 MSI 安装，不依赖 Store
• Ubuntu 24.04 发行版安装到 D 盘（C 盘 SSD 空间紧张）
• 日常登录用户是普通账号，不是 root

BIOS 虚拟化：容易忽略的前提

第一次装的时候直接跳过了这步，结果 wsl --import 报了一个很模糊的 0x80370102 错误，查了半天才意识到是虚拟化没开。

进 BIOS 确认 Intel VT-x 或 AMD-V 已启用。公司的联想台式机默认是关的，需要手动开。

启用 Windows 组件

管理员 PowerShell 里执行：

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

这两条缺一不可。第一条启用 WSL 子系统，第二条启用 Hyper-V 虚拟化平台（WSL2 的底层依赖）。执行完必须重启，不重启后面全白搭。

安装 WSL 引擎（MSI 离线包）

这是绕开 Store 的关键。从 WSL GitHub Releases 下载对应版本的 MSI：

msiexec /i "$env:USERPROFILE\Downloads\wsl.2.6.3.0.x64.msi" /passive /norestart

安装完再重启一次。对，又要重启——Windows 组件启用和 WSL 引擎安装各需要一次重启才生效。跳过任何一次重启，后面的 wsl --import 都会报错。

导入 Ubuntu 到 D 盘

准备离线发行版包

同样因为 Store 不可用，发行版也需要离线准备。Ubuntu 的 WSL 包可以从 Canonical 的 cloud-images 下载，选 ubuntu-24.04-wsl-amd64.rootfs.tar.gz 或 .wsl 格式。我把它放在 C:\WSL\rootfs\ 下。

清理旧实例（如果有的话）

中间试了好几次才装成功，每次重来前都需要先清理：

& "C:\Program Files\WSL\wsl.exe" --shutdown
& "C:\Program Files\WSL\wsl.exe" --unregister Ubuntu-24.04

--unregister 会删除该发行版的整个虚拟磁盘（ext4.vhdx），数据不可恢复，执行前确认没有要保留的东西。

导入

New-Item -ItemType Directory -Force -Path "D:\WSL\Ubuntu-24.04" | Out-Null
& "C:\Program Files\WSL\wsl.exe" --import Ubuntu-24.04 "D:\WSL\Ubuntu-24.04" "C:\WSL\rootfs\ubuntu-24.04.2-wsl-amd64.wsl" --version 2

--version 2 指定使用 WSL2（而不是 WSL1）。WSL2 是真正的 Linux 内核跑在轻量虚拟机里，文件系统性能和兼容性都远好于 WSL1 的系统调用翻译层。

导入完成后验证：

& "C:\Program Files\WSL\wsl.exe" --version
& "C:\Program Files\WSL\wsl.exe" -l -v

能看到 Ubuntu-24.04 且 VERSION 列显示 2 就对了。

默认用户：别用 root 日常登录

--import 方式安装的发行版默认以 root 身份登录，这和从 Store 安装的体验不一样（Store 版会在首次启动时引导你创建普通用户）。长期用 root 登录有安全风险，也会导致一些工具的行为不符合预期——比如 npm 会拒绝以 root 身份运行某些脚本。

创建普通用户并设为默认：

& "C:\Program Files\WSL\wsl.exe" -d Ubuntu-24.04 -u root --cd / -e /bin/sh -c `
  "id -u <user> >/dev/null 2>&1 || useradd -m -s /bin/bash <user>; echo <user>:<password> | chpasswd; usermod -aG sudo <user>; printf '[user]\ndefault=<user>\n' > /etc/wsl.conf"

这条命令做了四件事：创建用户 → 设密码 → 加入 sudo 组 → 写 /etc/wsl.conf 指定默认用户。把 <user> 和 <password> 换成你自己的用户名和密码。写完之后需要关闭 WSL 让配置生效：

& "C:\Program Files\WSL\wsl.exe" --shutdown
& "C:\Program Files\WSL\wsl.exe" -d Ubuntu-24.04 -e whoami

输出你设定的用户名就说明生效了。

/etc/wsl.conf 是 WSL 的实例级配置文件，内容很简单：

[user]
default=<user>

后续还可以在这里配置自动挂载行为、网络模式等，但默认配置基本够用。

路径选择：大小写敏感才是关键

装好之后马上会面对一个选择：代码放哪？

• /mnt/d/...（Windows NTFS，通过 9P 协议挂载）
• /home/<user>/...（WSL 原生 ext4）

直觉上 /mnt/d/ 更方便——Windows 和 WSL 两边都能直接访问。但 NTFS 默认是大小写不敏感的，这在 Linux 项目开发中是致命伤。Linux 内核源码里存在大量仅靠大小写区分的文件对——比如 include/uapi/linux/netfilter/ 下同时有 xt_CONNMARK.h 和 xt_connmark.h、xt_DSCP.h 和 xt_dscp.h 等十几组。在 NTFS 上解压时后者会覆盖前者，导致构建时头文件丢失，报错信息完全看不出是大小写问题。

Windows 10 1803 之后可以通过 fsutil file setCaseSensitiveInfo 按目录启用大小写敏感，但这只对新创建的目录生效，而且不是所有 Windows 工具都能正确处理大小写敏感的 NTFS 目录。与其到处打补丁，不如直接用 ext4。

除了大小写问题，9P 协议的 I/O 性能损耗也不可忽视——git status 在中等规模仓库上实测慢 5-10 倍，编译大型项目的差距更大。

结论：

• Linux 项目源码放 /home/<user>/ 下（ext4），天然支持大小写敏感，I/O 性能也好
• 需要两边共享的文件（安装包、文档、产物）放 /mnt/ 下对应的 Windows 盘符路径
• Windows 侧查看 WSL 文件用 \\wsl$\Ubuntu-24.04\home\...

这个选择对后续的内核编译尤其重要——下一篇 WSL 中编译 Linux 内核 会详细展开。

踩坑汇总

问题	表现	原因
0x80370102	wsl --import 报错	BIOS 虚拟化未启用
0x800701bc	wsl --import 报错	WSL 引擎版本过旧，需要更新 MSI
导入成功但启动报错	各种奇怪错误	只重启了一次，组件启用和引擎安装各需要一次重启
默认 root 登录	whoami 输出 root	--import 方式的默认行为，需要手动配 /etc/wsl.conf
/mnt/ 下编译巨慢	make -j$(nproc) 比预期慢十倍	9P 跨文件系统性能损耗，应该用 ext4 路径