升级失败排障

本页只处理一件事：升级已经失败之后怎么办。升级本身怎么做、哪些做法不受支持，见版本间升级流程；这里讲的是「卡住或起不来时怎么定位与恢复」，与那篇互补而不重复。

常见失败点

排障的第一个动作不是重跑命令，而是回答两个问题：走的是哪条路径、卡在哪一段。

官方升级文档把升级分成两条路径：DNF system upgrade（推荐用于 Workstation 与 KDE 之外的其它安装）与「用包管理器升级」。两条路径的失败点不同，排障的第一步是确认自己走的是哪一条。

失败之后再用这套做法「抢救」，会把问题从「一次失败的升级」变成「不受支持的混合状态」—— 后续任何官方路径都会更难走通。

dnf system-upgrade 分三段工作：在系统正常运行时下载包，重启进入一个特殊环境（实现为一个 systemd target）执行安装，完成后再次重启进入新版本。

理解这三段是排障的关键：下载段失败时系统仍在正常运行，你可以读完报错再决定重试；安装段失败时你已经不在原来的运行环境里，能用的手段变成启动项与救援入口。

所谓「离线事务」，指的就是重启后那段过渡环境里的安装过程。它不是当前系统里的一个进程，所以不存在「再执行一次就接上」这回事。实践上按阶段分开处理：

升级后最常见的「看起来像升级失败」，其实是启动链没跟上：新内核装上了，但默认启动项、initramfs 或救援入口还是旧的。

救援内核可能过期：rescue kernel 与它的 initramfs 由 Anaconda 在安装时生成，initramfs 会随内核更新，rescue kernel 不一定。官方给出的做法是删除旧的救援文件后用 kernel-install 重新加入当前内核。

sudo rm /boot/*rescue*
sudo kernel-install add "$(uname -r)" "/lib/modules/$(uname -r)/vmlinuz"

官方还说明，安装 dracut-config-rescue 可以让救援内核在 dracut 作为 initrd 生成器时自动维护。

需要回到旧内核启动时，用 grubby 指定默认启动项。

sudo ls /boot | grep vmlinuz
sudo grubby --set-default /boot/vmlinuz-<version>.<release>.<arch>

官方文档把相关内容收在 Kernel and booting 分类下，包含 Booting、Troubleshooting 与自定义内核指南等页面。

遇到内核或启动层面的失败，先按这个分类逐页对照，比在社区里拼凑零散说法更快 —— 你要找的往往不是「答案」，而是可复现的最小现象。

整理证据时按这四项来，缺一项都会让别人多问一轮：