企业官网建设流程全解析

Pop!_OS 22.04 虚拟机运维实录：根目录扩容与网络排障

前言

在虚拟化环境中维护 Linux 虚拟机，磁盘扩容和网络故障是最常遇到的两类问题。最近处理一台 Pop!_OS 22.04（基于 Ubuntu 22.04）虚拟机时，连续遇到了两个典型场景：

1. 磁盘已扩展到 80GB，但根目录仍只显示 36GB；
2. 安装 LlamaFactory 时 pip 报Name or service not known，排查发现是网卡未激活导致整个网络不通。

本文将完整记录从排查到解决的全过程，重点梳理每一步的判断逻辑，方便遇到类似问题时快速定位。

一、根目录扩容：分区表对了，文件系统还没跟上

现象

df -h显示/dev/sda1总大小仅 36G，使用率 91%；但lsblk显示sda磁盘本身已经是 80G，剩余空间处于未分配状态。

排查

sudofdisk-l/dev/sdasudoparted/dev/sda unit s printfree

关键发现：分区表已经被修改过了，sda1的结束扇区已经延伸到磁盘末尾（Sector 167772159），但df -h仍然显示 36G。

这说明问题不在分区表，而是文件系统（ext4）还停留在原来的大小，没有跟随分区一起扩展。

解决

ext4 支持在线扩容，根分区挂载状态下直接执行：

sudoresize2fs /dev/sda1

执行后df -h /显示 78G 左右（80G 减去文件系统元数据开销），扩容完成。

Pop!_OS 特有处理：清理残留的 cryptswap

Pop!_OS 安装时如果勾选了加密，会创建cryptswap。本例中sda2已被合并进sda1，但/etc/crypttab和/etc/fstab中可能仍残留相关配置，不处理的话下次启动可能报错或卡住：

sudonano/etc/crypttab# 注释掉 cryptswap 行sudonano/etc/fstab# 注释掉 /dev/mapper/cryptswap 行sudoupdate-initramfs-usudoupdate-grub

经验总结

• parted resizepart或fdisk修改的是分区表（容器大小）；
• resize2fs（ext4）或xfs_growfs（xfs）修改的是文件系统（内容大小）；
• 两者缺一不可。本例中分区表已经是满的，所以只需要做第二步。

二、网络排障：从 pip 安装失败到网卡 DOWN

现象

在 conda 环境中执行pip install -e .安装 LlamaFactory 时失败：

ERROR: No matching distribution found for hatchling ... [Errno -2] Name or service not known

排查链路

第一层：确认是 DNS 还是网络问题

pingbaidu.com# Name or service not knownping223.5.5.5# Network is unreachable

pingIP 也报Network is unreachable，说明不是单纯的 DNS 问题，而是链路层/路由就不通。

第二层：查看网卡和路由状态

ipaiproute

关键发现：

• ens33状态为<BROADCAST,MULTICAST>，没有UP标记；
• ip route中完全没有default via的默认路由，只有 docker0 和自定义网桥的本地网段。

这就是Network is unreachable的直接原因：网卡没起来，没有默认路由。

解决

第一步：激活网卡

sudoiplinksetens33 up

第二步：获取 IP 地址

sudodhclient-vens33

-v可以看到详细交互过程。输出显示完整的 DHCP 流程：

DHCPDISCOVER → DHCPOFFER (10.30.0.130 from 10.30.0.254) DHCPREQUEST → DHCPACK bound to 10.30.0.130

第三步：验证

ipa show ens33# 确认 inet 10.30.0.130/24iproute# 确认 default via 10.30.0.xping-c3baidu.com# 确认 DNS 解析正常

全部通过后，回到 pip 重新安装即可。

持久化配置

dhclient手动获取的地址是临时的，重启后可能失效。建议确认 NetworkManager 的自动连接设置：

nmcli connection showsudonmcli connection modify<连接名>connection.autoconnectyessudonmcli connection modify<连接名>ipv4.method auto

VMware 侧的排查要点

如果dhclient一直收不到DHCPOFFER，问题大概率在虚拟化网络层面：

• NAT 模式：确认宿主机上VMware NAT Service和VMware DHCP Service两个服务都在运行；
• 桥接模式：确认桥接绑定的是宿主机当前实际在用的物理网卡，而不是已禁用或虚拟的适配器；
• 修改过虚拟网络配置后，建议在 VMware 里重启虚拟网络服务，或直接重启虚拟机。

三、排查方法论小结

这两次排障都遵循了同一个思路：从报错信息出发，逐层向下排查，每一层都先用最简单的命令验证假设。

这种自顶向下的排查方式，能避免在错误的方向上浪费时间。比如一开始如果直接去改 pip 源或者换 DNS，就永远解决不了网卡 DOWN 的问题。

附：常用命令速查

# 磁盘相关lsblksudofdisk-l/dev/sdasudoparted/dev/sda unit s printfreesudoresize2fs /dev/sda1df-h/# 网络相关ipaiproutesudoiplinksetens33 upsudodhclient-vens33ping-c3baidu.com resolvectl status# NetworkManagernmcli connection showsudonmcli connection up<连接名>sudonmcli connection modify<连接名>connection.autoconnectyes