Ubuntu如何设置具体的系统更新失败后的回滚机制

Ubuntu无自动回滚机制，依赖Timeshift事前快照（Btrfs/Rsync）、apt预演与限制策略、内核保护及日志诊断等人工防护手段实现失败恢复。

Ubuntu 本身没有内置的“自动失败回滚”机制——apt 执行失败时不会自动还原已更改的包状态，也不会撤回部分完成的升级。所谓“更新失败后的回滚”，实际依赖的是**人工干预 + 预置防护手段**，不是开箱即用的开关。

Timeshift 必须在更新前启用，否则更新失败后无法回滚

这是最常被忽略的前提：Timeshift 不是“事后补救工具”，而是“事前快照工具”。它不能从 apt upgrade 崩溃日志里重建系统，只能恢复你手动或定时创建过的快照。

• 必须在执行任何重大更新（如 sudo apt full-upgrade 或内核升级）前，确保 Timeshift 已安装、配置并成功创建过至少一个有效快照
• 快照类型建议选 Btrfs（若根分区是 Btrfs）或 Rsync（Ext4 兼容性更好，但耗时略长）
• 检查快照是否真实可用：sudo timeshift --list，确认输出中包含 Status: completed 的条目
• 如果只依赖默认的“每日自动快照”，而上次成功运行是 3 天前，那这 3 天内的配置变更和新装软件就无法还原

APT 自身不支持原子化事务，但可限制破坏范围

apt 没有像 dnf 那样的 --best --allowerasing 回滚选项，也不记录完整事务日志。但它提供几个关键控制点来降低失败影响：

• 用 sudo apt install --dry-run = 预演安装，查看将移除/降级哪些包，避免意外依赖断裂
• 禁用自动内核升级防止引导失败：在 /etc/apt/apt.conf.d/50unattended-upgrades 中注释掉 Unattended-Upgrade::Allowed-Origins 里含 kernel 的行
• 对关键服务（如数据库、Web 服务器），更新前先停用：sudo systemctl stop nginx，避免升级中服务异常写入损坏数据
• 更新后立即验证：sudo systemctl status + ls /boot/vmlinuz-* 确认新内核存在且旧内核未被误删

更新失败时，apt 会留下可诊断线索，别直接重试

当 sudo apt upgrade 卡住或报错（如 E: Unmet dependencies、dpkg was interrupted），系统处于中间态，此时盲目 apt install -f 可能掩盖根本问题。

• 先看错误源头：cat /var/log/apt/term.log | tail -30，重点关注最后一段 failed 行
• 检查 dpkg 状态：sudo dpkg --configure -a 只修复未完成配置；若提示冲突，用 sudo apt install -f 尝试修复，但**不要加 -y**
• 若涉及内核更新失败，检查 /boot 是否满：df -h /boot，空间不足会导致 linux-image 安装中断，需手动清理旧内核（sudo apt autoremove --purge）
• 切勿运行 sudo apt dist-upgrade 来“强行解决”，它可能引入更多不兼容包

真正靠谱的回滚，始终是以“已知良好状态”的备份为基础的——并非依赖某条命令临时触发，而是依靠 Timeshift 快照、/boot 多内核共存，以及更新前执行 dpkg --get-selections > pkg-list.txt 这类简单却有效的状态锚点。这里面的复杂之处在于：快照策略得与你的更新节奏相匹配，可别等出了事才想起来安装Timeshift。