一次断电引发的血案：Ubuntu 26.04 升级中断后的完整救援实录

前言

终于等来了国庆长假！宅在家折腾自己的 HomeLab、 K8s、 NAS 服务器集群的感觉真爽！这次长假真的是折腾了好多东西，感兴趣的读者请期待后续的爆更，等不及的话也可以直接看我的 repo - east4ming/homelab2 的 PR 和 Commits。

国庆长假，别人在景区人挤人，我在家给 HomeLab 集群做系统升级——把几个节点从 Ubuntu 24.04 升到 26.04.1。

说实话，前几台升得异常顺利，do-release-upgrade 一路回车，重启，SSH 秒连，干净利落。连着成功几台之后，人就飘了。😆

飘的代价是：升级 n100-cheshi-0 的时候，我点了确认就出门了。结果回来后发现升级出现问题，卡住了。🧠一热+一急直接断电，直接 GG😭，一躺就是好几个小时。

接下来的画面就很熟悉了：反复重启，卡在 GRUB、黑屏、或者掉进 initramfs 的 (initramfs) 提示符，SSH 更是想都别想。一台本来只是"升个级"的机器，硬生生变砖。😑

好在最后还是修复了。

为什么"升级中断"比"正常崩溃"更棘手

Ubuntu 的大版本升级本质上是一个多阶段事务，大致要经过：下载包 → 解包 → 配置 → 重建 initramfs → 更新 GRUB 引导。断电发生在哪一步，坏法完全不一样：

麻烦的地方在于：这几层很可能是同时坏的。你先修好文件系统，它又卡在包没配完；包配完了，GRUB 又是坏的。一环扣一环，让人遭不住。

📝Notes: 好消息是：这些绝大多数都是可修复的，不像硬盘物理损坏那样直接宣判死刑。核心思路只有一个：用 Ubuntu Live USB 启动一个临时的"救援系统"，再 chroot 进原系统去修。

救援实录：Live USB + chroot 六步法

第 0 步：准备一个 Live USB

在另一台电脑上下载 Ubuntu 26.04 桌面版 ISO，用 Rufus 或 balenaEtcher 写入一个 ≥4GB 的 U 盘，然后在 BIOS/UEFI 里把 USB 设为第一启动项。

📝Notes: 用桌面版而不是 Server 版，因为我们需要 Try Ubuntu 那个临时图形环境，操作起来方便很多。

第 1 步：从 U 盘启动，选 "Try Ubuntu"

开机按 F12/F11/Del 进启动菜单，选 U 盘。进安装界面后，不要点安装，选 Try Ubuntu，进入临时桌面。后面所有操作都在这个环境里完成。

第 2 步：认盘 + 修文件系统

先确认分区布局：

lsblk -f

看清楚哪个是根分区（通常是 ext4，比如 /dev/sda2），哪个是 EFI 分区（通常是 vfat，比如 /dev/sda1）。

意外断电极易损坏文件系统，这是无法启动的最常见原因。先修它：

sudo fsck -y /dev/sda2

📝Notes: 如果提示 "device is mounted"，说明它已被自动挂载，先 sudo umount /dev/sda2 再执行。EFI 分区一般不用 fsck。

第 3 步：搭建 chroot 环境

sudo mount /dev/sda2 /mnt
sudo mount /dev/sda1 /mnt/boot/efi

for i in /dev /dev/pts /proc /sys /run; do
  sudo mount --bind $i /mnt$i
done

sudo chroot /mnt

这一步的意义是：让原系统"借"当前 Live 环境的内核跑起来，/dev、/proc、/sys 这些虚拟文件系统必须 bind 进去，否则 apt/dpkg 会因为缺少设备节点而报错。

第 4 步：修包

进 chroot 后，先把断电中断的软件包事务收尾：

apt --fix-broken install
dpkg --configure -a

这两条命令能解决 80% 的 "half-configured" 问题。

第 5 步：重装 GRUB + 重建 initramfs

UEFI 系统：

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu
update-grub
update-initramfs -u -k all

如果 grub-install 因为包损坏失败，强制重装一遍：

apt install --reinstall grub-efi-amd64 grub-efi-amd64-signed shim-signed

第 6 步：退出、卸载、重启

exit
sudo umount -R /mnt
sudo reboot

拔掉 U 盘，见证奇迹的时刻。🎉

救援方案分层：五种手段怎么选

同一台机器，其实有不止一种救法。按"侵入性从低到高"排一下：

init=/bin/bash 的玩法：在 GRUB 菜单里按 e 编辑启动项，在 linux 那行末尾加上 init=/bin/bash，按 F10 启动，直接掉进 root shell。适合"文件系统没坏，就是服务起不来"的情况。

📝Notes: boot-repair 可以在 Live 环境里装：sudo add-apt-repository ppa:yannubuntu/boot-repair && sudo apt install boot-repair。我个人的偏好是：能手动 chroot 修就手动修，把每一步都看清楚，比一键工具更让人安心。

事后纪律：升级不翻车的几条铁律

这次翻车，技术上没什么新鲜的，真正的问题出在流程上：

1. 升级期间，机器必须有人看着。这不是"跑个命令就行"的操作，它是一个可能失败的事务。
2. 升级前先确认供电稳定。UPS 不是奢侈品，是 HomeLab 的必需品。
3. 升级前先备份。至少 etckeeper 或关键配置的 tar 包。
4. 不要因为前几台顺利就放松警惕。说实话，连续成功几次之后产生的"蜜汁自信"，才是这次事故的真正元凶。

📝Notes: 第 4 条才是核心。千里之堤，溃于蚁穴。升级本身不难，难的是连续成功之后还保持第一次的谨慎。

总结

这次救援的完整链路是：Live USB 启动 → lsblk -f 认盘 → fsck 修文件系统 → 挂载 + bind 虚拟文件系统 → chroot → apt/dpkg 修包 → 重装 GRUB + update-initramfs → umount -R → reboot。

关键认知有两条：

• 升级中断导致的"变砖"，绝大多数是可修复的，别急着格盘重装；
• 救援手段要分层使用：能从 GRUB 进去就别上 Live USB，能用 chroot 手动修就别急着 boot-repair，重装系统永远放最后。

至于那台 n100-cheshi-0，最后是满血复活了。代价是国庆少玩了一天，换来一篇博客，倒也不算亏。😆

慎终如始，则无败事。

以上。

📚️参考文档

• Ubuntu 官方文档 - 系统安装与引导
• Ubuntu Community Help Wiki - Grub2
• boot-repair 工具
• fsck 手册
• chroot 手册