WSL2 Ubuntu 18.04 下 NFS 挂载 rootfs 失败：现象、原因与完整修复

WSL2 Ubuntu 18.04 下 NFS 挂载 rootfs 失败：现象、原因与完整修复

问题现象

在使用嵌入式设备通过 NFS 挂载 rootfs 时，网络已经通了（能 ping 通主机），环境变量也配置完成，但内核启动后卡在挂载阶段：

约 30 秒后出现挂载失败信息：

结论是：目标板没有成功挂载到主机导出的 NFS 根文件系统。

结论

在 WSL2 中，NFS 相关服务有时不会处于可用状态。每次使用 NFS 启动前，先重建运行目录并重启rpcbind与nfs-kernel-server，再重新导出共享目录，可稳定恢复挂载。

解决方案

新建脚本（例如start_nfs.sh）：

#!/bin/bashsudomkdir-p/run/sendsigs.omit.dsudoservicerpcbind restartsudoservicenfs-kernel-server restartsudoexportfs-arv

赋予执行权限并运行：

chmod+x start_nfs.sh ./start_nfs.sh

然后再启动开发板进行 rootfs 挂载。

原因分析

1. WSL2 默认并不总是自动拉起完整服务链

在传统 Ubuntu（物理机/虚拟机）里，系统初始化阶段会按顺序拉起系统服务，NFS 相关组件通常能自动就绪。

WSL2 的启动机制与传统 Linux 主机不同，很多服务不会像服务器发行版那样“开机即稳定可用”。因此，rpcbind、nfs-kernel-server可能在当前会话中未正确就绪，需要手动重启。

可用以下命令确认当前 PID 1：

ps-p1-ocomm=

你的环境显示为init（WSL 的初始化进程），这也解释了为什么服务行为与传统 Ubuntu 有差异。

2./run是易失目录，重启后会清空

/run挂载在tmpfs上，属于内存文件系统。WSL 会话关闭或重启后，其内容会消失。

rpcbind运行依赖/run下的若干运行时路径；当这些路径缺失时，服务可能启动异常。脚本中的mkdir -p /run/sendsigs.omit.d就是在补齐该类运行目录。

注意：目录应为/run/sendsigs.omit.d，不是/run/sendsigs.omit/d。

验证现象如下：

上图是运行完脚本后，下图是重启WSL2之后

重启后发现缺少了rpcbind、rpcbind.lock、rpcbind.pid、rpcbind.sock、sendsigs.omit.d、sudo文件。

3. NFS 依赖 RPC 注册，启动顺序很关键

NFS 服务依赖 RPC 机制进行端口与服务注册。

如果rpcbind未先正确运行，后续nfs-kernel-server的注册状态就可能异常，最终导致客户端挂载失败。

脚本中这三步的作用分别是：

• service rpcbind restart：重置 RPC 端口映射服务。
• service nfs-kernel-server restart：重启 NFS 服务并重新注册。
• exportfs -arv：重新加载导出目录配置并输出详细信息，便于确认导出是否生效。

结束

如果经常用 NFS 启动开发板，建议在每次进入 WSL 开发会话后先执行一次该脚本。当然也可以把这个脚本写在一些启动文件中，让每次开启一个会话自动执行，这里不多赘述。

果经常用 NFS 启动开发板，建议在每次进入 WSL 开发会话后先执行一次该脚本。当然也可以把这个脚本写在一些启动文件中，让每次开启一个会话自动执行，这里不多赘述。