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赋予执行权限并运行chmodx start_nfs.sh ./start_nfs.sh然后再启动开发板进行 rootfs 挂载。原因分析1. WSL2 默认并不总是自动拉起完整服务链在传统 Ubuntu物理机/虚拟机里系统初始化阶段会按顺序拉起系统服务NFS 相关组件通常能自动就绪。WSL2 的启动机制与传统 Linux 主机不同很多服务不会像服务器发行版那样“开机即稳定可用”。因此rpcbind、nfs-kernel-server可能在当前会话中未正确就绪需要手动重启。可用以下命令确认当前 PID 1ps-p1-ocomm你的环境显示为initWSL 的初始化进程这也解释了为什么服务行为与传统 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 开发会话后先执行一次该脚本。当然也可以把这个脚本写在一些启动文件中让每次开启一个会话自动执行这里不多赘述。