Ubuntu 22.04 / Pop!_OS 根目录扩容实战从 36G 到 80G 的完整记录 前言为什么需要扩容在虚拟机环境中磁盘空间不足是常有的事。最近在处理一台 Pop!_OS 22.04基于 Ubuntu 22.04虚拟机时遇到了一个典型场景磁盘总容量已扩展至 80GB但系统根目录/仍然只识别出原本的 36GB剩余的 40GB 处于“未分配”状态。本文将完整记录从排查分区表异常、处理残留 Swap 配置到最终成功扩容文件系统的全过程。如果你也遇到了df -h显示空间已满但lsblk显示磁盘还有大量空闲的情况这篇指南或许能帮到你。 第一步现状排查与“幽灵”分区在动手之前必须搞清楚磁盘的真实布局。很多时候工具之间的信息不一致会导致误判。1. 查看挂载情况df-h/输出显示/dev/sda1总大小仅36G使用率高达 91%急需扩容。2. 查看块设备布局lsblk输出显示sda总大小为80G但sda1依然只有 36G。值得注意的是此时lsblk中并没有看到sda2Swap 分区只有一个zram0作为交换空间。3. 查看底层分区表这是最关键的一步。我们需要确认那 40GB 空闲空间到底在哪里。sudofdisk-l/dev/sdasudoparted/dev/sda unit s printfree关键发现fdisk和parted均显示sda1的结束扇区已经延伸到了磁盘末尾Sector 167772159。这意味着分区表实际上已经被修改过了可能是之前的操作遗留或者是虚拟化平台的自动调整但文件系统Filesystem还停留在原来的大小。之前的blkid能读到sda2的 UUID但分区表里已经没有它了。这说明sda2是一个“幽灵”残留内核缓存或旧配置导致的假象。️ 第二步执行扩容操作既然分区表已经正确sda1占据了整个磁盘我们只需要做一件事让 ext4 文件系统“撑满”整个分区。1. 在线扩容文件系统Ext4 文件系统支持在线扩容无需卸载根目录。sudoresize2fs /dev/sda1注如果提示需要先检查文件系统可尝试sudo e2fsck -f /dev/sda1需卸载或在 Live 环境下进行但在大多数现代 Ubuntu/Pop!_OS 版本中直接 resize 即可成功。2. 验证结果df-h/此时应看到/dev/sda1的大小变为78G左右80G 减去文件系统元数据开销扩容成功 第三步清理“幽灵”Swap 配置重要虽然扩容完成了但如果不处理之前的 Swap 残留下次重启可能会报错或卡住。1. 现象分析之前的blkid显示过/dev/sda2的 UUID且/etc/crypttab中配置了cryptswap。现在sda2物理上已经不存在了被合并进 sda1 了如果保留这些配置系统启动时会尝试寻找不存在的设备导致启动延迟或进入紧急模式。2. 清理步骤编辑 crypttabsudonano/etc/crypttab找到类似下面这一行将其注释掉加#或删除# cryptswap UUID83033830-e995-40bb-bfcf-c7cf376cd42f /dev/urandom swap,plain...编辑 fstabsudonano/etc/fstab找到引用/dev/mapper/cryptswap的行同样注释掉# /dev/mapper/cryptswap none swap defaults 0 0更新引导配置为了让更改生效并避免潜在问题建议更新 initramfs 和 GRUBsudoupdate-initramfs-usudoupdate-grub 避坑指南与经验总结分区表 vs 文件系统parted resizepart或fdisk修改的只是“容器”分区表的大小。resize2fs(ext4) 或xfs_growfs(xfs) 修改的才是“内容”文件系统的大小。两者缺一不可。本案例中因为分区表已经是满的所以只需要做第二步。关于 Pop!_OS 的 SwapPop!_OS 默认倾向于使用zram内存压缩作为交换空间而不是传统的磁盘 Swap 分区。如果你的系统里有zram0且工作正常其实完全可以废弃磁盘上的 Swap 分区这样扩容时就不用担心移动分区的风险了。数据安全虽然resize2fs很成熟但涉及底层存储操作务必先打快照Snapshot。如果是物理机请务必备份重要数据。工具选择命令行工具parted,resize2fs比图形界面GParted更精准尤其是在处理扇区对齐和脚本化操作时。但在复杂场景下如需要移动分区GParted 的可视化界面能帮你避免很多逻辑错误。