如果你也遇到过 Ubuntu 开机黑屏、屏幕上只有一个光标在闪甚至直接全黑没有任何反应先别急着怀疑显卡驱动坏了。我去年就因为这个判断折腾了大半天的驱动最后才发现真正的杀手是根分区被写满了——系统连临时文件都写不进去图形桌面自然起不来。所以标题里那句“磁盘容量扩展”才是解决问题的终点。这篇内容我按实际排查的顺序来写怎么确认是磁盘满了而不是别的故障、怎么在进不去桌面的情况下拿到一个 shell、怎么在尽量不丢数据的前提下把根分区扩大以及扩完之后的验证和防复发措施。无论你用的是 Ubuntu 桌面版还是服务器版只要先把卷组、分区这些概念理清楚这套流程基本都能用得上。1. 黑屏背后的真实原因空间不足为什么能把系统“憋死”1.1 容易被误判的现象类似显卡问题但细节不同显卡驱动导致的黑屏通常发生在切换分辨率、加载驱动模块、或者启动到桌面之前的某个瞬间表现出来的是“内核已经打印完了屏幕忽然黑掉”偶尔伴随光驱疯狂读盘或者风扇拉满。而磁盘空间不足的黑屏往往更“安静”开机过程走到某个用户态服务就卡住桌面登录界面始终弹不出来系统状态看起来像是启动到一半就离了。两者最大的区别在系统日志里但问题是现在屏幕是黑的你没法直接看日志。所以第一步不是拆显卡而是想尽一切办法拿到一个能敲命令的终端。如果开机时能看到 GRUB 菜单说明引导器、内核基本是完好的问题大概率出在用户态。如果你连 GRUB 都看不到那可能是另一套故障这篇文章先不展开。总之空间不足导致的黑屏通常是后面各阶段的服务在尝试创建临时文件或写日志时报错叠加之后把桌面会话直接压垮了。1.2 为什么会“黑”ext4 保留块、临时文件和 journald 的连环反应很多 Linux 老玩家都知道 ext4 默认给 root 用户保留了 5% 的块即便普通用户空间写满root 还是能进系统删东西。但实际上桌面进程不是用 root 跑的GNOME Shell、dbus、systemd 用户实例这些进程一旦遇到No space left on device行为会非常奇怪有的是静默崩溃有的是一直尝试重试最终表现就是画面黑屏、鼠标键盘没响应。还有一个常见的雪崩点是 systemd-journald。日志服务不会因为磁盘满了就停止写它会返回写入失败然后某些服务进入重启循环重启循环又产生更多日志形成了一个典型的“死锁”。如果根分区是独立分区/tmp 和 /var 也都没空间整个系统就像人被掐住了脖子。所以当你在黑屏面前无从下手时记住一个关键原则先把系统能用的空间“抠”出来一点让基本服务能启动再做进一步的持久化扩容。1.3 三条路径拿到终端恢复模式、TTY、Live USB我分别试过下面三种方式按上手难度排序方式适用情况优点局限GRUB 恢复模式 root shell能看到 GRUB能进入 recovery mode不需要外部介质最快有时根分区以只读挂载需要手动重挂CtrlAltF3 切换到 TTY内核起来了桌面起不来原生终端操作简单如果图形会话把资源占死TTY 可能也会卡Live USB 挂载 chroot完全进不去或者要执行分区扩容这种“大手术”最稳固扩容操作的首选需要准备启动盘耗时更长我自己的经历是先试 TTY结果图形会话虽然黑屏但没完全死TTY 能进去等我把日志清掉之后桌面反而自动恢复了。但如果你遇到的是“彻底进不去”直接走 Live USB 路径别在恢复模式里耗太久。2. 扩容动手前的三连问环境、分区布局、可用空间在哪里2.1 第一问你的 Ubuntu 用的是 LVM 还是普通分区这是整个扩容操作最关键的岔路口。LVM逻辑卷管理和普通分区采用的扩容流程完全不同命令和风险等级也差很多。用lsblk -f一看便知$ lsblk -f NAME FSTYPE LABEL UUID MOUNTPOINT sda ├─sda1 vfat ABCD-1234 /boot/efi ├─sda2 LVM2_member xxxxxx-yyyy / └─sda5 swap uuid [SWAP] └─ubuntu--vg-root ext4 uuid /如果输出里出现LVM2_member并且根分区是/dev/mapper/ubuntu--vg-root或者/dev/ubuntu-vg/ubuntu-lv说明你用的是 LVM。再辅助几条命令确认sudo pvs # 物理卷列表确认 PV 对应的实际磁盘分区 sudo vgs # 卷组列表 sudo lvs # 逻辑卷列表普通分区的情况则简单得多根分区直接就是/dev/sda1、/dev/nvme0n1p2这样的路径没有卷组这一层。为什么要这么较真因为 LVM 环境下文件系统大小和物理分区大小之间隔了两层抽象。你改了虚拟机的磁盘大小只是让物理磁盘有了更多空间要让它真正被系统用上需要依次“喂”给 PV、VG、LV、文件系统。普通分区则只涉及分区表扩展和文件系统扩展两步。顺序错了就会报各种“没有可用空间”的错误。2.2 第二问这台机器是虚拟机、物理机还是云主机扩容不是凭空变出空间先得有空间来源。虚拟机最简单大多数虚拟化平台都支持在线或离线扩容磁盘常见操作是在虚拟机设置里把磁盘容量从 40GB 调整到 60GB 或更大。物理机麻烦一点如果是单个硬盘且分区之间没有空隙单纯调分区表不行往往需要借助工具移动分区或更换更大硬盘。云主机一般是在云控制台的云硬盘管理里执行“扩容云硬盘”操作之后系统里能看到更大的块设备。判断方法很直接fdisk -l /dev/sda如果看到类似Disk /dev/sda: 80 GiB而这个数字比你刚开始安装系统时的容量大说明“物理层空间”已经到位了。接下来要做的就是把这部分新空间穿透到文件系统。2.3 第三问新空间到底应该加到哪里这儿有个常见误区以为只要磁盘变大就万事大吉。实际上对于普通分区布局新增的空间必须“紧紧挨着”你希望扩展的那个分区后面分区表工具才能把空间并进去。如果根分区后面还排着一个 swap 分区或者恢复分区你就得先把挡路的分区挪开。LVM 布局在这点上反而比较友好只要 PV 所在的物理分区能先吃到新空间卷组里就会多出一块自由空间然后你就能把空间分配给任意一个逻辑卷基本上不受分区排列顺序限制。这也是我在生产环境里更推荐 LVM 的一个重要原因。动手之前无论哪条路重要数据都建议先备份。分区和扩容操作一旦失误轻则文件系统损坏重则数据全丢这种代价不值得赌。3. 进不去桌面的实操三种启动路径的完整操作过程3.1 路径一GRUB 恢复模式 root shell最快但可能有坑开机后长按 Shift部分 UEFI 机器是连续点按 Esc进入 GRUB 菜单后选择“Advanced options for Ubuntu”再选带(recovery mode)的内核项。等待加载完成后你会进入一个英文菜单里面有一项叫root Drop to root shell prompt选中并回车。此时你已经是 root 用户但文件系统可能是只读挂载先执行mount -o remount,rw /然后用df -h看空间。如果已经是 100%先别急做一次“急救清理”把最占地方且不重要的文件删掉。具体清哪里我会在第 7 节统一讲。在恢复模式里我不建议执行 LVM 扩容操作因为进程环境不完整而且根分区处于挂载状态部分调整有风险。这个模式更适合“救火”——腾出空间重启后续真正扩容再去 Live USB 环境做。3.2 路径二TTY 控制台切换如果内核和 systemd 已经启动系统只是卡在图形界面起不来那么好消息来了你的系统大概率还活着只是没地方显示桌面。这时候同时按 CtrlAltF3 或 F4会切到一个纯文本终端输入用户名密码就能登录。登录后先跑df -h df -i第一个看容量第二个看 inode。inode 耗尽也会导致No space left on device哪怕df -h看着还有空间。如果 inode 满了常见场景是某些目录下堆积了几百万个小文件比如邮件队列、Docker 容器里的临时文件、或者系统切分太碎的日志。TTY 和恢复模式一样最好是做应急清理让系统能重启。如果你的目标是彻底扩容建议接下来直接做 Live USB 操作因为正常系统运行状态下对根分区做分区表调整会有更多限制。3.3 路径三Live USB 挂载 chroot扩容的“标准手术室”准备一个 Ubuntu 启动盘从 U 盘启动进入安装界面后选择“Try Ubuntu”。进入 Live 桌面后打开终端。先激活并识别 LVMsudo vgscan sudo vgchange -ay lsblk -f确认逻辑卷路径比如/dev/ubuntu-vg/ubuntu-lv。然后把它挂载到临时目录并做 chrootsudo mkdir -p /mnt/system sudo mount /dev/ubuntu-vg/ubuntu-lv /mnt/system sudo mount /dev/sda1 /mnt/system/boot/efi # 如果有 EFI 分区 for i in /dev /dev/pts /proc /sys /run; do sudo mount --bind $i /mnt/system$i done sudo chroot /mnt/system /bin/bashchroot 之后你就像是进入了原来的系统可以执行update-grub、清理缓存、修复配置等操作。不过要注意此时根目录仍然在 /mnt/system 上如果原来系统空间是满的chroot 进去后依然满所以应急清理和永久扩容都得在 chroot 或 Live 环境下完成。我实测下来Live USB 路径最麻烦的点是挂载顺序和 EFI 分区的处理其他都比想象中顺利。如果你完全不知道原来系统是什么布局先在 Live 环境里跑lsblk -f和pvs看清之后再进行下一步。4. 最典型的实操路径LVM 逻辑卷扩容完整命令序列4.1 第一步先在虚拟机或云平台侧把磁盘空间加出来这一步不是在 Linux 内部操作。比如你的虚拟机原来磁盘 40GB现在想扩到 80GB就去虚拟机设置里把磁盘大小改成 80GB。改完之后回到 Linux执行lsblk正常情况下你会看到/dev/sda的总容量变成了 80GB但/dev/sda2分区大小还是原来的 40GB根文件系统也还是 40GB。新空间目前处于“未分配”状态这正是我们要处理的。4.2 第二步扩展物理分区把新空间纳入分区确认使用lsblk -f看清 LVM 物理卷所在的分区编号。常见情况下 LVM PV 是/dev/sda2。用growpart扩展分区sudo growpart /dev/sda 2growpart后面跟的是磁盘路径和分区号中间是空格。如果没有这个命令可以安装cloud-guest-utils工具包或者用 partedsudo parted /dev/sda resizepart 2 100%执行完用partprobe /dev/sda刷新分区表有的环境可能需要重启一次才能识别新分区大小。再执行lsblk确认/dev/sda2已经变成 80GB 了再继续。4.3 第三步pvresize 让物理卷吸收新空间分区变了PV 还不一定自动认。执行sudo pvresize /dev/sda2然后看效果sudo pvs输出里PFree应该不再是 0而是有了几十 GB 的自由空间。这一步如果显示没有变化多半是上一步分区扩展没生效或者你扩展错分区分区号了。先停下回头检查lsblk。4.4 第四步lvextend 把根逻辑卷扩到卷组的全部可用空间确认卷组和逻辑卷名称之后执行sudo lvs sudo lvextend -l 100%FREE /dev/ubuntu-vg/ubuntu-lv-l 100%FREE的含义是把卷组里所有空余空间都分给这个逻辑卷。这是最省心也最不容易算错参数的方式。也可以指定大小比如-L 20G。但我个人更偏向用百分比因为后续如果你再次扩容磁盘同样的一条命令就能继续把新空间纳进来。执行完sudo lvs逻辑卷大小应该已经变成接近 80GB。4.5 第五步resize2fs 或 xfs_growfs 扩展文件系统到了这里逻辑卷已经变大但文件系统还停留在旧尺寸。ext4 文件系统用resize2fssudo resize2fs /dev/ubuntu-vg/ubuntu-lv如果文件系统类型是 XFS则需要挂在挂载点状态下执行sudo mount /dev/ubuntu-vg/ubuntu-lv /mnt/system sudo xfs_growfs /mnt/system完成后df -h应该能直接看到根分区容量已经变为 80GB。4.6 顺序不能乱常见报错和处理方式这个流程的顺序非常严格先物理磁盘再分区表再 PV再 LV最后文件系统。任何一步跳过去后续命令都会报错。报错现象原因处理pvresize后 PFree 仍是 0分区没有真正变大或 partprobe 没刷新执行lsblk核对分区大小必要时重启lvextend提示没有可分配空间PV 空间没纳进来返回第三步确认 PV 状态resize2fs报错或没反应文件系统和 LV 型号不匹配或文件系统脏先e2fsck -f再重新 resize扩完重启后还是旧容量文件系统扩展没执行成功回到 Live 环境重新走第四、五步分区操作别急每一步都看输出确认比印象中的几秒钟更重要。5. 非 LVM 分区与老式布局的保守处理法5.1 单块根分区直接安装的情况如果你安装 Ubuntu 时选择了“清除整个磁盘并使用 LVM”那是上面那种做法。但如果你是手动分区根分区直接是一个物理分区比如/dev/sda1那么扩容逻辑就简单不少。假设虚拟机磁盘已经扩大执行sudo growpart /dev/sda 1 sudo resize2fs /dev/sda1第一行扩展物理分区第二行扩展文件系统。XFS 的话挂载后执行xfs_growfs /挂载点。整体流程只有两步比 LVM 少整整三层。5.2 root 分区后面还挡着分区或 swap只能调整分区布局这是最让人头秃的情况。比如根分区/dev/sda1是 40GB后面紧跟着一个/dev/sda2的 swap 分区或/home分区那么你新增的 40GB 在磁盘末尾根分区没法直接“跳过”中间的分区去吃掉它。此时最稳妥的办法是用 GParted 图形工具在 Live 环境里操作。步骤通常是启动 GParted。先缩小或删除挡路的分区把未分配空间留出来。把未分配空间移动到根分区旁边或者直接扩大根分区。应用操作等待完成。移动分区不是闹着玩的数据量越大耗时越长中途断电基本等于灾难。所以如果数据重要我宁愿选择另一种更保守的思路备份数据重装系统从一开始就规划好布局。一次性的半小时迁移成本远低于随时可能爆炸的移动分区风险。5.3 老式 MBR 分区表与扩展分区的特别提醒早期 Ubuntu 安装常用 MBR 分区表主分区数量限制为 4 个多出来的分区是扩展分区和逻辑分区。这种布局下根分区如果恰好占用了最后一个逻辑分区的编号growpart可能因为分区完整性原因拒绝扩展。遇到这种问题要么转换成 GPT需要工具支持且有一定风险要么干脆重装一劳永逸。现在的 UEFI GPT 安装是主流遇到老式 MBR 的场景越来越少了但如果你手头正好有个老机器注意这个坑。6. 扩容之后别急着欢呼文件系统检查和启动验证6.1 先强制检查文件系统再重启扩容操作本身不会让文件系统损坏但如果之前黑屏是意外断电造成的非正常关机文件系统里可能有脏块。直接重启风险不大但稳妥起见我习惯在 Live 环境下先做一次强制检查sudo e2fsck -f /dev/ubuntu-vg/ubuntu-lv注意-f是强制检查不要省略。如果文件系统很大这一步可能要几分钟耐心等。检查完成后输出如果都是clean那后面重启就踏实了。6.2 更新 GRUB 和确认 fstab 的 UUID如果你只动了 LVM 卷组和文件系统通常不需要执行update-grub因为 LVM 的 UUID 不会变。但如果你在分区表层面改动过比如调整了 EFI 分区或根分区位置还是建议 chroot 到原系统后执行update-grub同时检查一下/etc/fstab确认里面用的是 UUID 或稳定的设备路径而不是临时的/dev/sdaX这种可能变化的命名。UUID 在扩容过程中一般不会变用 UUID 的配置是最稳的。6.3 重启后的验证清单重启进入系统后逐条核对df -h df -i sudo pvs sudo lvs systemctl --faileddf -h确认根分区容量变为新值Use%不再接近 100%。df -i确认 inode 充足。pvs、lvs确认物理卷和逻辑卷大小正常。systemctl --failed查看有没有失败的服务。如果图形桌面还是起不来但 shell 能进多半还有别的隐患比如某些服务一直尝试写空间不足的目录。回到 TTY查看journalctl -p 3 -b里最新的错误继续排查。7. 治本思路让根分区别再睡满才是关键7.1 给日志、缓存和旧内核上“紧箍咒”日志是头号杀手。systemd-journald 默认可能无限累积我见过一台常年不清理的服务器/var/log/journal 占了 30GB。手动限制sudo journalctl --vacuum-size100M永久限制则在/etc/systemd/journald.conf里设置SystemMaxUse500M改完重启 journald 或执行systemctl restart systemd-journald。apt 缓存也是容易被忽略的大空间消耗者sudo apt clean sudo apt autoremove --purge旧内核长期不清理也会在/boot下堆积。可以用dpkg --list | grep linux-image手动筛查或者在更新升级后定期执行apt autoremove。7.2 用一行命令找出最占空间的大文件平时维护系统的过程中我每周都会扫一次sudo du -xhd1 / 2/dev/null | sort -h | tail -30它会输出根目录下各个一级目录的大小从大到小排列一次看明白。如果发现某个目录异常膨胀再往下钻两级。Docker 用户特别注意/var/lib/docker会快速膨胀镜像、容器、卷、日志全部堆在一起。定期执行docker system prune -a清理无用镜像但注意这会删除所有未被容器使用的镜像执行前确认。7.3 用简单脚本做磁盘水位监控很多时候黑屏不是瞬间发生的空间是慢慢被蚕食的。写一个五分钟脚本每天跑一次给系统留下一份“体检报告”#!/bin/bash THRESHOLD80 USAGE$(df -h / | awk NR2 {print $5} | tr -d %) if [ $USAGE -gt $THRESHOLD ]; then echo 根分区使用率已达 ${USAGE}% | mail -s 磁盘空间预警 yourexample.com fi不需要复杂的监控平台cron 里加一行就行。预警永远比事故好处理。7.4 预留空间的心态Linux 根分区最好保留 15% 到 20% 的空余。空间不是给你日常用的那部分留的而是给系统“呼吸”用的临时文件、崩溃转储、日志突发增长、Docker 层、用户误操作这些都会在某个瞬间把磁盘打满。预留空间不是浪费是策略。如果条件允许再规划一块独立数据盘放/home、Docker、数据库等容易膨胀的目录这样即使数据盘满了也不影响系统盘的基本运行系统不会轻易走到黑屏那一步。这次之后我给自己定了个规矩每当安装新系统第一步就是检查分区布局该用 LVM 就用 LVM给根分区留足余量每周跑一次目录扫描看看有没有日志或缓存偷偷膨胀。数据无价与其被黑屏逼到连夜做手术不如平时多看两眼df -h的输出。这套流程救过我一次希望也能帮你把电脑从黑屏里捞回来。 
长河君 · 2026/10/17 8:35:54 · 阅读 1.2k Ubuntu开机黑屏？可能是磁盘满了：LVM根分区扩容实战指南
如果你也遇到过 Ubuntu 开机黑屏、屏幕上只有一个光标在闪甚至直接全黑没有任何反应先别急着怀疑显卡驱动坏了。我去年就因为这个判断折腾了大半天的驱动最后才发现真正的杀手是根分区被写满了——系统连临时文件都写不进去图形桌面自然起不来。所以标题里那句“磁盘容量扩展”才是解决问题的终点。这篇内容我按实际排查的顺序来写怎么确认是磁盘满了而不是别的故障、怎么在进不去桌面的情况下拿到一个 shell、怎么在尽量不丢数据的前提下把根分区扩大以及扩完之后的验证和防复发措施。无论你用的是 Ubuntu 桌面版还是服务器版只要先把卷组、分区这些概念理清楚这套流程基本都能用得上。1. 黑屏背后的真实原因空间不足为什么能把系统“憋死”1.1 容易被误判的现象类似显卡问题但细节不同显卡驱动导致的黑屏通常发生在切换分辨率、加载驱动模块、或者启动到桌面之前的某个瞬间表现出来的是“内核已经打印完了屏幕忽然黑掉”偶尔伴随光驱疯狂读盘或者风扇拉满。而磁盘空间不足的黑屏往往更“安静”开机过程走到某个用户态服务就卡住桌面登录界面始终弹不出来系统状态看起来像是启动到一半就离了。两者最大的区别在系统日志里但问题是现在屏幕是黑的你没法直接看日志。所以第一步不是拆显卡而是想尽一切办法拿到一个能敲命令的终端。如果开机时能看到 GRUB 菜单说明引导器、内核基本是完好的问题大概率出在用户态。如果你连 GRUB 都看不到那可能是另一套故障这篇文章先不展开。总之空间不足导致的黑屏通常是后面各阶段的服务在尝试创建临时文件或写日志时报错叠加之后把桌面会话直接压垮了。1.2 为什么会“黑”ext4 保留块、临时文件和 journald 的连环反应很多 Linux 老玩家都知道 ext4 默认给 root 用户保留了 5% 的块即便普通用户空间写满root 还是能进系统删东西。但实际上桌面进程不是用 root 跑的GNOME Shell、dbus、systemd 用户实例这些进程一旦遇到No space left on device行为会非常奇怪有的是静默崩溃有的是一直尝试重试最终表现就是画面黑屏、鼠标键盘没响应。还有一个常见的雪崩点是 systemd-journald。日志服务不会因为磁盘满了就停止写它会返回写入失败然后某些服务进入重启循环重启循环又产生更多日志形成了一个典型的“死锁”。如果根分区是独立分区/tmp 和 /var 也都没空间整个系统就像人被掐住了脖子。所以当你在黑屏面前无从下手时记住一个关键原则先把系统能用的空间“抠”出来一点让基本服务能启动再做进一步的持久化扩容。1.3 三条路径拿到终端恢复模式、TTY、Live USB我分别试过下面三种方式按上手难度排序方式适用情况优点局限GRUB 恢复模式 root shell能看到 GRUB能进入 recovery mode不需要外部介质最快有时根分区以只读挂载需要手动重挂CtrlAltF3 切换到 TTY内核起来了桌面起不来原生终端操作简单如果图形会话把资源占死TTY 可能也会卡Live USB 挂载 chroot完全进不去或者要执行分区扩容这种“大手术”最稳固扩容操作的首选需要准备启动盘耗时更长我自己的经历是先试 TTY结果图形会话虽然黑屏但没完全死TTY 能进去等我把日志清掉之后桌面反而自动恢复了。但如果你遇到的是“彻底进不去”直接走 Live USB 路径别在恢复模式里耗太久。2. 扩容动手前的三连问环境、分区布局、可用空间在哪里2.1 第一问你的 Ubuntu 用的是 LVM 还是普通分区这是整个扩容操作最关键的岔路口。LVM逻辑卷管理和普通分区采用的扩容流程完全不同命令和风险等级也差很多。用lsblk -f一看便知$ lsblk -f NAME FSTYPE LABEL UUID MOUNTPOINT sda ├─sda1 vfat ABCD-1234 /boot/efi ├─sda2 LVM2_member xxxxxx-yyyy / └─sda5 swap uuid [SWAP] └─ubuntu--vg-root ext4 uuid /如果输出里出现LVM2_member并且根分区是/dev/mapper/ubuntu--vg-root或者/dev/ubuntu-vg/ubuntu-lv说明你用的是 LVM。再辅助几条命令确认sudo pvs # 物理卷列表确认 PV 对应的实际磁盘分区 sudo vgs # 卷组列表 sudo lvs # 逻辑卷列表普通分区的情况则简单得多根分区直接就是/dev/sda1、/dev/nvme0n1p2这样的路径没有卷组这一层。为什么要这么较真因为 LVM 环境下文件系统大小和物理分区大小之间隔了两层抽象。你改了虚拟机的磁盘大小只是让物理磁盘有了更多空间要让它真正被系统用上需要依次“喂”给 PV、VG、LV、文件系统。普通分区则只涉及分区表扩展和文件系统扩展两步。顺序错了就会报各种“没有可用空间”的错误。2.2 第二问这台机器是虚拟机、物理机还是云主机扩容不是凭空变出空间先得有空间来源。虚拟机最简单大多数虚拟化平台都支持在线或离线扩容磁盘常见操作是在虚拟机设置里把磁盘容量从 40GB 调整到 60GB 或更大。物理机麻烦一点如果是单个硬盘且分区之间没有空隙单纯调分区表不行往往需要借助工具移动分区或更换更大硬盘。云主机一般是在云控制台的云硬盘管理里执行“扩容云硬盘”操作之后系统里能看到更大的块设备。判断方法很直接fdisk -l /dev/sda如果看到类似Disk /dev/sda: 80 GiB而这个数字比你刚开始安装系统时的容量大说明“物理层空间”已经到位了。接下来要做的就是把这部分新空间穿透到文件系统。2.3 第三问新空间到底应该加到哪里这儿有个常见误区以为只要磁盘变大就万事大吉。实际上对于普通分区布局新增的空间必须“紧紧挨着”你希望扩展的那个分区后面分区表工具才能把空间并进去。如果根分区后面还排着一个 swap 分区或者恢复分区你就得先把挡路的分区挪开。LVM 布局在这点上反而比较友好只要 PV 所在的物理分区能先吃到新空间卷组里就会多出一块自由空间然后你就能把空间分配给任意一个逻辑卷基本上不受分区排列顺序限制。这也是我在生产环境里更推荐 LVM 的一个重要原因。动手之前无论哪条路重要数据都建议先备份。分区和扩容操作一旦失误轻则文件系统损坏重则数据全丢这种代价不值得赌。3. 进不去桌面的实操三种启动路径的完整操作过程3.1 路径一GRUB 恢复模式 root shell最快但可能有坑开机后长按 Shift部分 UEFI 机器是连续点按 Esc进入 GRUB 菜单后选择“Advanced options for Ubuntu”再选带(recovery mode)的内核项。等待加载完成后你会进入一个英文菜单里面有一项叫root Drop to root shell prompt选中并回车。此时你已经是 root 用户但文件系统可能是只读挂载先执行mount -o remount,rw /然后用df -h看空间。如果已经是 100%先别急做一次“急救清理”把最占地方且不重要的文件删掉。具体清哪里我会在第 7 节统一讲。在恢复模式里我不建议执行 LVM 扩容操作因为进程环境不完整而且根分区处于挂载状态部分调整有风险。这个模式更适合“救火”——腾出空间重启后续真正扩容再去 Live USB 环境做。3.2 路径二TTY 控制台切换如果内核和 systemd 已经启动系统只是卡在图形界面起不来那么好消息来了你的系统大概率还活着只是没地方显示桌面。这时候同时按 CtrlAltF3 或 F4会切到一个纯文本终端输入用户名密码就能登录。登录后先跑df -h df -i第一个看容量第二个看 inode。inode 耗尽也会导致No space left on device哪怕df -h看着还有空间。如果 inode 满了常见场景是某些目录下堆积了几百万个小文件比如邮件队列、Docker 容器里的临时文件、或者系统切分太碎的日志。TTY 和恢复模式一样最好是做应急清理让系统能重启。如果你的目标是彻底扩容建议接下来直接做 Live USB 操作因为正常系统运行状态下对根分区做分区表调整会有更多限制。3.3 路径三Live USB 挂载 chroot扩容的“标准手术室”准备一个 Ubuntu 启动盘从 U 盘启动进入安装界面后选择“Try Ubuntu”。进入 Live 桌面后打开终端。先激活并识别 LVMsudo vgscan sudo vgchange -ay lsblk -f确认逻辑卷路径比如/dev/ubuntu-vg/ubuntu-lv。然后把它挂载到临时目录并做 chrootsudo mkdir -p /mnt/system sudo mount /dev/ubuntu-vg/ubuntu-lv /mnt/system sudo mount /dev/sda1 /mnt/system/boot/efi # 如果有 EFI 分区 for i in /dev /dev/pts /proc /sys /run; do sudo mount --bind $i /mnt/system$i done sudo chroot /mnt/system /bin/bashchroot 之后你就像是进入了原来的系统可以执行update-grub、清理缓存、修复配置等操作。不过要注意此时根目录仍然在 /mnt/system 上如果原来系统空间是满的chroot 进去后依然满所以应急清理和永久扩容都得在 chroot 或 Live 环境下完成。我实测下来Live USB 路径最麻烦的点是挂载顺序和 EFI 分区的处理其他都比想象中顺利。如果你完全不知道原来系统是什么布局先在 Live 环境里跑lsblk -f和pvs看清之后再进行下一步。4. 最典型的实操路径LVM 逻辑卷扩容完整命令序列4.1 第一步先在虚拟机或云平台侧把磁盘空间加出来这一步不是在 Linux 内部操作。比如你的虚拟机原来磁盘 40GB现在想扩到 80GB就去虚拟机设置里把磁盘大小改成 80GB。改完之后回到 Linux执行lsblk正常情况下你会看到/dev/sda的总容量变成了 80GB但/dev/sda2分区大小还是原来的 40GB根文件系统也还是 40GB。新空间目前处于“未分配”状态这正是我们要处理的。4.2 第二步扩展物理分区把新空间纳入分区确认使用lsblk -f看清 LVM 物理卷所在的分区编号。常见情况下 LVM PV 是/dev/sda2。用growpart扩展分区sudo growpart /dev/sda 2growpart后面跟的是磁盘路径和分区号中间是空格。如果没有这个命令可以安装cloud-guest-utils工具包或者用 partedsudo parted /dev/sda resizepart 2 100%执行完用partprobe /dev/sda刷新分区表有的环境可能需要重启一次才能识别新分区大小。再执行lsblk确认/dev/sda2已经变成 80GB 了再继续。4.3 第三步pvresize 让物理卷吸收新空间分区变了PV 还不一定自动认。执行sudo pvresize /dev/sda2然后看效果sudo pvs输出里PFree应该不再是 0而是有了几十 GB 的自由空间。这一步如果显示没有变化多半是上一步分区扩展没生效或者你扩展错分区分区号了。先停下回头检查lsblk。4.4 第四步lvextend 把根逻辑卷扩到卷组的全部可用空间确认卷组和逻辑卷名称之后执行sudo lvs sudo lvextend -l 100%FREE /dev/ubuntu-vg/ubuntu-lv-l 100%FREE的含义是把卷组里所有空余空间都分给这个逻辑卷。这是最省心也最不容易算错参数的方式。也可以指定大小比如-L 20G。但我个人更偏向用百分比因为后续如果你再次扩容磁盘同样的一条命令就能继续把新空间纳进来。执行完sudo lvs逻辑卷大小应该已经变成接近 80GB。4.5 第五步resize2fs 或 xfs_growfs 扩展文件系统到了这里逻辑卷已经变大但文件系统还停留在旧尺寸。ext4 文件系统用resize2fssudo resize2fs /dev/ubuntu-vg/ubuntu-lv如果文件系统类型是 XFS则需要挂在挂载点状态下执行sudo mount /dev/ubuntu-vg/ubuntu-lv /mnt/system sudo xfs_growfs /mnt/system完成后df -h应该能直接看到根分区容量已经变为 80GB。4.6 顺序不能乱常见报错和处理方式这个流程的顺序非常严格先物理磁盘再分区表再 PV再 LV最后文件系统。任何一步跳过去后续命令都会报错。报错现象原因处理pvresize后 PFree 仍是 0分区没有真正变大或 partprobe 没刷新执行lsblk核对分区大小必要时重启lvextend提示没有可分配空间PV 空间没纳进来返回第三步确认 PV 状态resize2fs报错或没反应文件系统和 LV 型号不匹配或文件系统脏先e2fsck -f再重新 resize扩完重启后还是旧容量文件系统扩展没执行成功回到 Live 环境重新走第四、五步分区操作别急每一步都看输出确认比印象中的几秒钟更重要。5. 非 LVM 分区与老式布局的保守处理法5.1 单块根分区直接安装的情况如果你安装 Ubuntu 时选择了“清除整个磁盘并使用 LVM”那是上面那种做法。但如果你是手动分区根分区直接是一个物理分区比如/dev/sda1那么扩容逻辑就简单不少。假设虚拟机磁盘已经扩大执行sudo growpart /dev/sda 1 sudo resize2fs /dev/sda1第一行扩展物理分区第二行扩展文件系统。XFS 的话挂载后执行xfs_growfs /挂载点。整体流程只有两步比 LVM 少整整三层。5.2 root 分区后面还挡着分区或 swap只能调整分区布局这是最让人头秃的情况。比如根分区/dev/sda1是 40GB后面紧跟着一个/dev/sda2的 swap 分区或/home分区那么你新增的 40GB 在磁盘末尾根分区没法直接“跳过”中间的分区去吃掉它。此时最稳妥的办法是用 GParted 图形工具在 Live 环境里操作。步骤通常是启动 GParted。先缩小或删除挡路的分区把未分配空间留出来。把未分配空间移动到根分区旁边或者直接扩大根分区。应用操作等待完成。移动分区不是闹着玩的数据量越大耗时越长中途断电基本等于灾难。所以如果数据重要我宁愿选择另一种更保守的思路备份数据重装系统从一开始就规划好布局。一次性的半小时迁移成本远低于随时可能爆炸的移动分区风险。5.3 老式 MBR 分区表与扩展分区的特别提醒早期 Ubuntu 安装常用 MBR 分区表主分区数量限制为 4 个多出来的分区是扩展分区和逻辑分区。这种布局下根分区如果恰好占用了最后一个逻辑分区的编号growpart可能因为分区完整性原因拒绝扩展。遇到这种问题要么转换成 GPT需要工具支持且有一定风险要么干脆重装一劳永逸。现在的 UEFI GPT 安装是主流遇到老式 MBR 的场景越来越少了但如果你手头正好有个老机器注意这个坑。6. 扩容之后别急着欢呼文件系统检查和启动验证6.1 先强制检查文件系统再重启扩容操作本身不会让文件系统损坏但如果之前黑屏是意外断电造成的非正常关机文件系统里可能有脏块。直接重启风险不大但稳妥起见我习惯在 Live 环境下先做一次强制检查sudo e2fsck -f /dev/ubuntu-vg/ubuntu-lv注意-f是强制检查不要省略。如果文件系统很大这一步可能要几分钟耐心等。检查完成后输出如果都是clean那后面重启就踏实了。6.2 更新 GRUB 和确认 fstab 的 UUID如果你只动了 LVM 卷组和文件系统通常不需要执行update-grub因为 LVM 的 UUID 不会变。但如果你在分区表层面改动过比如调整了 EFI 分区或根分区位置还是建议 chroot 到原系统后执行update-grub同时检查一下/etc/fstab确认里面用的是 UUID 或稳定的设备路径而不是临时的/dev/sdaX这种可能变化的命名。UUID 在扩容过程中一般不会变用 UUID 的配置是最稳的。6.3 重启后的验证清单重启进入系统后逐条核对df -h df -i sudo pvs sudo lvs systemctl --faileddf -h确认根分区容量变为新值Use%不再接近 100%。df -i确认 inode 充足。pvs、lvs确认物理卷和逻辑卷大小正常。systemctl --failed查看有没有失败的服务。如果图形桌面还是起不来但 shell 能进多半还有别的隐患比如某些服务一直尝试写空间不足的目录。回到 TTY查看journalctl -p 3 -b里最新的错误继续排查。7. 治本思路让根分区别再睡满才是关键7.1 给日志、缓存和旧内核上“紧箍咒”日志是头号杀手。systemd-journald 默认可能无限累积我见过一台常年不清理的服务器/var/log/journal 占了 30GB。手动限制sudo journalctl --vacuum-size100M永久限制则在/etc/systemd/journald.conf里设置SystemMaxUse500M改完重启 journald 或执行systemctl restart systemd-journald。apt 缓存也是容易被忽略的大空间消耗者sudo apt clean sudo apt autoremove --purge旧内核长期不清理也会在/boot下堆积。可以用dpkg --list | grep linux-image手动筛查或者在更新升级后定期执行apt autoremove。7.2 用一行命令找出最占空间的大文件平时维护系统的过程中我每周都会扫一次sudo du -xhd1 / 2/dev/null | sort -h | tail -30它会输出根目录下各个一级目录的大小从大到小排列一次看明白。如果发现某个目录异常膨胀再往下钻两级。Docker 用户特别注意/var/lib/docker会快速膨胀镜像、容器、卷、日志全部堆在一起。定期执行docker system prune -a清理无用镜像但注意这会删除所有未被容器使用的镜像执行前确认。7.3 用简单脚本做磁盘水位监控很多时候黑屏不是瞬间发生的空间是慢慢被蚕食的。写一个五分钟脚本每天跑一次给系统留下一份“体检报告”#!/bin/bash THRESHOLD80 USAGE$(df -h / | awk NR2 {print $5} | tr -d %) if [ $USAGE -gt $THRESHOLD ]; then echo 根分区使用率已达 ${USAGE}% | mail -s 磁盘空间预警 yourexample.com fi不需要复杂的监控平台cron 里加一行就行。预警永远比事故好处理。7.4 预留空间的心态Linux 根分区最好保留 15% 到 20% 的空余。空间不是给你日常用的那部分留的而是给系统“呼吸”用的临时文件、崩溃转储、日志突发增长、Docker 层、用户误操作这些都会在某个瞬间把磁盘打满。预留空间不是浪费是策略。如果条件允许再规划一块独立数据盘放/home、Docker、数据库等容易膨胀的目录这样即使数据盘满了也不影响系统盘的基本运行系统不会轻易走到黑屏那一步。这次之后我给自己定了个规矩每当安装新系统第一步就是检查分区布局该用 LVM 就用 LVM给根分区留足余量每周跑一次目录扫描看看有没有日志或缓存偷偷膨胀。数据无价与其被黑屏逼到连夜做手术不如平时多看两眼df -h的输出。这套流程救过我一次希望也能帮你把电脑从黑屏里捞回来。