一次断电引发的血案：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 引导。断电发生在哪一步，坏法完全不一样：

断在哪一步	典型症状
包已解包、未配置	dpkg 数据库处于 half-configured 状态，apt 各种报错
initramfs 生成到一半	内核找不到根文件系统，掉进 `(initramfs)`
GRUB 写入中途	引导记录损坏，开机直接进 BIOS 或黑屏
ext4 journal 未落盘	文件系统损坏，只读挂载甚至无法挂载

麻烦的地方在于：这几层很可能是同时坏的。你先修好文件系统，它又卡在包没配完；包配完了，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 步：认盘 + 修文件系统

先确认分区布局：

bash 复制代码

lsblk -f

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

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

bash 复制代码

sudo fsck -y /dev/sda2

📝Notes :

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

第 3 步：搭建 chroot 环境

bash 复制代码

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 后，先把断电中断的软件包事务收尾：

bash 复制代码

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

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

第 5 步：重装 GRUB + 重建 initramfs

UEFI 系统：

bash 复制代码

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

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

bash 复制代码

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

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

bash 复制代码

exit
sudo umount -R /mnt
sudo reboot

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

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

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

方案	适用场景	优点	缺点
`init=/bin/bash`	GRUB 能进，只是系统起不来	最快，10 秒进 root shell	只有最小环境，网络/服务都没有
Recovery Mode	GRUB 菜单还能显示	图形菜单，fsck/dpkg 一键点	修不了 GRUB 本身
Live USB + chroot	引导/包/文件系统同时坏	能力最全，基本都能修	步骤多，要 U 盘
boot-repair	GRUB 问题复杂、不想手动折腾	自动化程度高	有时"聪明反被聪明误"
备份 + 重装	所有方法都失败	一了百了	配置全丢，最后兜底

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 修就手动修，把每一步都看清楚，比一键工具更让人安心。

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

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

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

📝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 26.04 升级中断后的完整救援实录

前言

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

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

第 0 步：准备一个 Live USB

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

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

第 3 步：搭建 chroot 环境

第 4 步：修包

第 5 步：重装 GRUB + 重建 initramfs

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

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

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

总结

📚️参考文档