Jetson Nano系统盘空间告急？别慌，手把手教你用GParted给Ubuntu 20.04无损扩容
当你兴奋地启动新配置的Jetson Nano准备大展拳脚时，系统突然弹出"磁盘空间不足"的警告，这种场景对开发者来说再熟悉不过。默认镜像往往只分配了部分SD卡容量，而真正的挑战在于如何安全地释放那些"被封印"的存储空间。本文将带你深入理解分区扩容的底层逻辑，并演示如何像专业运维人员一样操作GParted工具。
1. 解密Jetson Nano的默认分区布局
刚拆封的Jetson Nano就像被预先规划好格局的精装房，32GB的SD卡实际可用空间可能只有16GB。通过lsblk命令查看磁盘结构时，你会看到类似这样的输出：
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT mmcblk0 179:0 0 29.7G 0 disk ├─mmcblk0p1 179:1 0 512M 0 part /boot └─mmcblk0p2 179:2 0 14.9G 0 part /这里隐藏着三个关键信息点：
- mmcblk0p1：512MB的boot分区，存放内核和启动文件
- mmcblk0p2：实际可用的rootfs分区，通常只占SD卡一半容量
- 未分配空间：剩余容量处于"待命"状态，需要手动激活
有趣的是，这种设计源于镜像的通用性考虑——确保系统能在最小容量的SD卡上运行。但对我们这些使用大容量存储设备的用户来说，反而成了需要解决的"历史遗留问题"。
2. ARM架构下的GParted生存指南
在x86平台安装软件是家常便饭，但在ARM架构的Jetson Nano上，有些操作需要特别关注。执行sudo apt install gparted时，你可能会遇到依赖问题。这时需要先更新软件源：
sudo apt update sudo apt install -f安装完成后，直接运行sudo gparted可能会遇到一个典型陷阱——图形界面无法启动。这是因为在无显示器环境下需要指定显示输出：
export DISPLAY=:0 sudo gparted注意：如果使用SSH远程连接，需要添加X11转发参数：
ssh -X username@jetson-ip
工具界面打开后，你会看到这样的分区结构示意：
| 分区 | 大小 | 文件系统 | 标签 |
|---|---|---|---|
| /dev/sda1 | 512MB | fat32 | boot |
| /dev/sda2 | 14.9GB | ext4 | rootfs |
| 未分配 | 剩余空间 | - | - |
3. 分区调整的精细手术
点击未分配空间前的警告图标不是摆设——它提醒我们分区操作具有潜在风险。稳妥起见，建议先进行数据备份：
sudo tar -cvpzf /backup.tar.gz --exclude=/backup.tar.gz --one-file-system /真正的扩容操作需要遵循严格步骤：
- 右键点击rootfs分区选择"Resize/Move"
- 将分区右侧边界拖拽到磁盘末端
- 在"Free space following"栏确认数值为0
- 点击"Resize"按钮暂存操作
- 最后点击工具栏的绿色对勾执行变更
关键细节：调整分区大小时，GParted实际执行的是以下底层命令序列：
# 检查文件系统 e2fsck -f /dev/mmcblk0p2 # 调整分区边界 resize2fs /dev/mmcblk0p2整个过程可能持续2-15分钟，取决于SD卡速度和未分配空间大小。期间绝对不要中断电源或移除SD卡，否则可能导致文件系统损坏。
4. 扩容后的系统调优
成功扩容只是开始，合理的空间管理才能让Jetson Nano发挥最大效能。几个实用命令帮你掌握存储使用情况：
# 查看整体磁盘使用 df -h # 分析目录空间占用 sudo du -sh /* # 清理APT缓存 sudo apt clean对于经常安装大型AI模型的情况，建议建立专门的符号链接：
# 将PyTorch模型库转移到外接存储 mv ~/.cache/torch /mnt/external_drive/ ln -s /mnt/external_drive/torch ~/.cache/torch最后分享一个真实案例：有位开发者扩容后系统启动失败，原因是误删了boot分区。通过SD卡读卡器挂载到其他Linux设备，用fsck修复文件系统后成功恢复。这提醒我们——操作分区表就像修改DNA，需要严谨的态度和应急预案。
