尧图网站建设 
Pop!_OS 22.04 虚拟机运维实录根目录扩容与网络排障前言在虚拟化环境中维护 Linux 虚拟机磁盘扩容和网络故障是最常遇到的两类问题。最近处理一台 Pop!_OS 22.04基于 Ubuntu 22.04虚拟机时连续遇到了两个典型场景磁盘已扩展到 80GB但根目录仍只显示 36GB安装 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 特有处理清理残留的 cryptswapPop!_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修改的是分区表容器大小resize2fsext4或xfs_growfsxfs修改的是文件系统内容大小两者缺一不可。本例中分区表已经是满的所以只需要做第二步。二、网络排障从 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 unreachablepingIP 也报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 autoVMware 侧的排查要点如果dhclient一直收不到DHCPOFFER问题大概率在虚拟化网络层面NAT 模式确认宿主机上VMware NAT Service和VMware DHCP Service两个服务都在运行桥接模式确认桥接绑定的是宿主机当前实际在用的物理网卡而不是已禁用或虚拟的适配器修改过虚拟网络配置后建议在 VMware 里重启虚拟网络服务或直接重启虚拟机。三、排查方法论小结这两次排障都遵循了同一个思路从报错信息出发逐层向下排查每一层都先用最简单的命令验证假设。层级命令判断依据应用层pip install报错信息指向网络或源DNS 层ping 域名vsping IP区分是解析失败还是链路不通路由层ip route有无默认路由链路层ip a网卡是否 UP、有无 IP虚拟化层检查 VMware 服务DHCP/NAT 服务是否运行这种自顶向下的排查方式能避免在错误的方向上浪费时间。比如一开始如果直接去改 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 Pop!_OS 22.04 Linux运维实录：根目录扩容与网络排障
Pop!_OS 22.04 虚拟机运维实录根目录扩容与网络排障前言在虚拟化环境中维护 Linux 虚拟机磁盘扩容和网络故障是最常遇到的两类问题。最近处理一台 Pop!_OS 22.04基于 Ubuntu 22.04虚拟机时连续遇到了两个典型场景磁盘已扩展到 80GB但根目录仍只显示 36GB安装 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 特有处理清理残留的 cryptswapPop!_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修改的是分区表容器大小resize2fsext4或xfs_growfsxfs修改的是文件系统内容大小两者缺一不可。本例中分区表已经是满的所以只需要做第二步。二、网络排障从 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 unreachablepingIP 也报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 autoVMware 侧的排查要点如果dhclient一直收不到DHCPOFFER问题大概率在虚拟化网络层面NAT 模式确认宿主机上VMware NAT Service和VMware DHCP Service两个服务都在运行桥接模式确认桥接绑定的是宿主机当前实际在用的物理网卡而不是已禁用或虚拟的适配器修改过虚拟网络配置后建议在 VMware 里重启虚拟网络服务或直接重启虚拟机。三、排查方法论小结这两次排障都遵循了同一个思路从报错信息出发逐层向下排查每一层都先用最简单的命令验证假设。层级命令判断依据应用层pip install报错信息指向网络或源DNS 层ping 域名vsping IP区分是解析失败还是链路不通路由层ip route有无默认路由链路层ip a网卡是否 UP、有无 IP虚拟化层检查 VMware 服务DHCP/NAT 服务是否运行这种自顶向下的排查方式能避免在错误的方向上浪费时间。比如一开始如果直接去改 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