Ubuntu 20.04下，让uboot的NFS下载不再报TTT和cannot mount错误（实测避坑）
Ubuntu 20.04与嵌入式开发板NFS兼容性深度调优指南
当你在Ubuntu 20.04上搭建嵌入式开发环境时，是否遇到过这样的场景：uboot反复报出"TTT"超时错误，或是"cannot mount"的绝望提示？这背后往往隐藏着NFS协议版本不匹配的陷阱。本文将带你深入理解Ubuntu新版本中NFS配置的变革，并提供一套经过实战验证的解决方案。
1. 问题根源：新旧NFS协议的碰撞
现代Ubuntu系统（20.04及以后）默认使用NFSv4，而大多数嵌入式开发板上的uboot仅支持NFSv2或v3。这种版本断层导致握手失败，具体表现为：
- TTT超时错误：客户端不断重试但服务端无响应
- Cannot mount报错：协议协商失败后的最终结果
- 权限拒绝：NFSv4的权限模型与旧版本存在差异
关键发现：Ubuntu 18.04到20.04的升级中，NFS配置体系从/etc/default/nfs-*迁移到了/etc/nfs.conf，这个变化让许多开发者措手不及。
2. 环境准备与兼容性检查
2.1 系统环境确认
首先验证你的Ubuntu版本和NFS服务状态：
lsb_release -a sudo systemctl status nfs-server典型输出应显示：
No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 20.04.3 LTS Release: 20.04 Codename: focal2.2 开发板uboot版本确认
在uboot命令行执行：
version记录输出的uboot版本号，这对后续方案选择至关重要。
3. 终极解决方案：多版本NFS服务配置
3.1 修改NFS服务端配置
编辑关键配置文件：
sudo nano /etc/nfs.conf添加或修改以下内容：
[nfsd] vers2=y vers3=y udp=y3.2 调整exports文件权限
确保共享目录配置正确（示例）：
sudo nano /etc/exports内容参考：
/home/developer/rootfs *(rw,sync,no_subtree_check,no_root_squash)3.3 服务重启与验证
执行以下命令序列：
sudo systemctl restart nfs-server sudo exportfs -v验证输出应包含：
/home/developer/rootfs <world>(rw,wdelay,no_root_squash,no_subtree_check)4. 高级调试技巧与备选方案
4.1 网络抓包分析
当基础方案不奏效时，tcpdump是终极武器：
sudo tcpdump -i any port 2049 -vv关键观察点：
- 是否看到NFS协议协商过程
- 是否有版本不匹配的明确提示
4.2 备选方案：TFTP过渡
当NFS问题短期内无法解决时，可临时使用TFTP传输内核和dtb：
# 安装TFTP服务 sudo apt install tftpd-hpa # 配置示例 echo 'TFTP_DIRECTORY="/srv/tftp"' | sudo tee -a /etc/default/tftpd-hpa4.3 内核参数调优
在uboot环境变量中添加这些参数可能有所帮助：
setenv nfsargs 'vers=3,udp,nolock' setenv bootargs ${nfsargs} root=/dev/nfs nfsroot=${serverip}:${rootpath}5. 不同Ubuntu版本的配置差异
通过实测对比发现各版本默认行为：
| 版本 | 默认NFS版本 | 配置文件位置 | 需要的手动修改 |
|---|---|---|---|
| 18.04 | v3 | /etc/default/nfs-kernel-server | 较少 |
| 20.04 | v4 | /etc/nfs.conf | 必须开启v2/v3 |
| 22.04 | v4.2 | /etc/nfs.conf | 同20.04 |
6. 实战案例：全志H3开发板调试记
最近调试一块全志H3开发板时，遇到典型的NFSv4不兼容问题。uboot 2015.04版本不断报错：
Loading: T T T T T T T T T T Retry count exceeded; starting again解决步骤：
- 确认Ubuntu 20.04的NFS服务版本
- 修改/etc/nfs.conf启用v3支持
- 在uboot中明确指定nfsvers=3
- 最终成功挂载并启动系统
关键教训：永远不要假设新系统会向后兼容旧硬件。每次Ubuntu大版本升级，都需要重新验证嵌入式工具链的兼容性。