记一次Ubuntu 22.04 LTS虚拟机开机故障排查：从GDM启动失败到根目录扩容的完整记录

Ubuntu 22.04 LTS虚拟机磁盘空间耗尽故障全记录从GDM崩溃到LVM扩容实战那天早晨的咖啡还没喝完Ubuntu虚拟机的图形界面突然拒绝启动。屏幕上赫然显示着failed to start gdm.service的红色警告随后卡在systemd-update-utmp-runlevel.service的提示符前不再响应。作为承载着多个Docker实验环境的开发机这个突发状况直接打乱了当天的全部工作计划。接下来72小时的故障排查意外成为了一次精彩的Linux存储管理实战课。1. 故障现象与初步诊断按下电源键后Ubuntu 22.04 LTS的启动过程在显示厂商Logo后突然停滞。仔细观察启动日志关键报错序列如下[FAILED] Failed to start GNOME Display Manager [ OK ] Finished systemd-update-utmp-runlevel.service - Record Runlevel Change in UTMP典型误判陷阱看到GDM服务失败第一反应往往是图形驱动或Xorg配置问题。但经验告诉我们当多个不相关的服务同时异常时应该优先考虑底层资源问题。通过AltCtrlF2切换到TTY终端登录后几个关键命令揭示了真相$ df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/ubuntu--vg-root 19G 19G 0 100% /磁盘使用率100%的红色数字解释了所有现象——系统根本没有空间创建临时文件、记录日志或维持基本服务运行。此时journalctl -xe显示的各类服务失败其实都是磁盘空间耗尽的连锁反应。2. 深入分析存储结构在扩容之前必须全面了解当前存储配置。以下命令组合提供了完整视角$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 50G 0 disk ├─sda1 8:1 0 1M 0 part ├─sda2 8:2 0 1G 0 part /boot └─sda3 8:3 0 29G 0 part ├─ubuntu--vg-root 253:0 0 19G 0 lvm / └─ubuntu--vg-swap_1 253:1 0 4G 0 lvm [SWAP] $ sudo vgs VG #PV #LV #SN Attr VSize VFree ubuntu-vg 1 2 0 wz--n- 29.00g 0输出显示虚拟机使用LVM逻辑卷管理但卷组已无剩余空间。而sda物理磁盘仍有21G未分配空间——这正是我们可以利用的资源。3. 虚拟机层与系统层联动扩容3.1 虚拟机磁盘扩展以VMware为例关闭虚拟机电源右键虚拟机 → 设置 → 硬盘 → 扩展容量至50GB确认后启动虚拟机3.2 操作系统层分区调整识别新增的未分配空间并创建新分区$ sudo fdisk /dev/sda Welcome to fdisk (util-linux 2.37.2). Command (m for help): n Partition type p primary (3 primary, 0 extended, 1 free) e extended (container for logical partitions) Select (default p): p Partition number (4, default 4): First sector (60923904-104857599, default 60923904): Last sector, /-sectors or /-size{K,M,G,T,P} (60923904-104857599, default 104857599): Created a new partition 4 of type Linux and of size 21 GiB. Command (m for help): t Partition number (1-4, default 4): 4 Hex code (type L to list all codes): 8e Changed type of partition Linux to Linux LVM. Command (m for help): w The partition table has been altered.3.3 LVM卷组扩展将新分区纳入LVM体系并扩展根分区$ sudo pvcreate /dev/sda4 Physical volume /dev/sda4 successfully created. $ sudo vgextend ubuntu-vg /dev/sda4 Volume group ubuntu-vg successfully extended $ sudo lvextend -L 20G /dev/mapper/ubuntu--vg-root Size of logical volume ubuntu-vg/root changed from 19.00 GiB to 39.00 GiB. $ sudo resize2fs /dev/mapper/ubuntu--vg-root resize2fs 1.46.5 (30-Dec-2021) Filesystem at /dev/mapper/ubuntu--vg-root is mounted on /; on-line resizing required old_desc_blocks 3, new_desc_blocks 5 The filesystem on /dev/mapper/ubuntu--vg-root is now 10223616 (4k) blocks long.4. 验证与预防措施扩容完成后df -h显示根分区已获得新生Filesystem Size Used Avail Use% Mounted on /dev/mapper/ubuntu--vg-root 39G 19G 20G 49% /为避免再次陷入同样困境建议设置以下监控机制自动化预警脚本保存为/usr/local/bin/disk_alert.sh#!/bin/bash THRESHOLD90 CURRENT$(df --outputpcent / | tail -1 | tr -d %) if [ $CURRENT -ge $THRESHOLD ]; then echo Warning: Root filesystem usage $CURRENT% | \ mail -s Disk Space Alert on $(hostname) adminexample.com ficrontab定时任务每天检查一次$ sudo crontab -e 0 9 * * * /usr/local/bin/disk_alert.sh这次故障教会我们在Linux系统中当多个服务莫名崩溃时磁盘空间、内存等基础资源状态应该成为首要排查点。LVM的弹性设计虽然提供了扩容的便利但提前规划存储空间和建立监控机制才是避免紧急救援的最佳实践。