Linux系统回滚方案规划_异常恢复方法说明【指导】_网络技术

回滚前必须确认/boot剩余空间≥200MB、grub.cfg未被覆盖、/lib/modules/中存在当前内核目录；使用grub2-reboot临时切换内核最安全；rpm回滚受依赖、冲突和脚本限制；快照失效优先chroot修复fstab UUID。

Linux 系统回滚不是“一键还原”，失败往往源于回滚前未验证关键前提。最常被跳过的检查是：/boot 分区剩余空间、grub.cfg 是否被覆盖、以及当前内核是否仍在 /lib/modules/ 中存在对应目录。

/boot 剩余空间不足 200MB 时，grub2-install 或内核重装会静默失败，错误日志里只显示 error: unknown filesystem —— 实际是写入失败后 GRUB 无法识别新生成的 initrd
运行 ls /lib/modules/$(uname -r)，若返回空，说明当前运行的内核模块已丢失，此时强制重启大概率进不了系统
执行 grub2-editenv list | grep saved_entry，确认 saved_entry 指向的是可启动的老版本（如 CentOS Linux (4.18.0-305.el8.x86_64) 8），而非 gnulinux-advanced-* 这类菜单项 ID

这是最安全的单次回滚方式：仅本次重启生效，不影响后续默认启动项，适合验证老内核是否仍可用。

grub2-set-default 'CentOS Linux (4.18.0-305.el8.x86_64) 8'
grub2-reboot 'CentOS Linux (4.18.0-305.el8.x86_64) 8'
reboot

注意：grub2-set-default 的参数必须与 grep menuentry /boot/grub2/grub.cfg 输出的完整字符串完全一致（包括括号和空格），大小写敏感；grub2-reboot 才真正触发下一次启动时的临时切换。

如果 grub.cfg 是由 dracut 生成的（如 RHEL/CentOS 8+），修改后需再运行 dracut --force 确保 initramfs 匹配目标内核
某些云平台（如阿里云 ECS）禁用 grub2-reboot，此时只能用 systemctl reboot --kexec 配合提前设好的 saved_entry

用 rpm 回滚单个软件包看似直接，但实际受三重约束：依赖版本锁、文件冲突、以及 %postun 脚本是否支持逆向操作。

执行 rpm -Uvh --oldpackage kernel-core-4.18.0-305.el8.x86_64.rpm 前，先查依赖：rpm -qpR kernel-core-4.18.0-305.el8.x86_64.rpm | grep -E "(kernel|kmod)"，确认无新增或降级依赖
--oldpackage 不会自动卸载高版本，必须手动 rpm -e kernel-core-5.14.0-284.el9.x86_64（否则触发文件冲突错误 file /lib/modules/... conflicts between...）
像 systemd、glibc 这类核心包禁止用 --oldpackage 回滚，rpm 会直接拒绝，报错 package systemd-252-17.el9.x86_64 is not older than systemd-252-18.el9.x86_64

LVM 快照或 btrfs snapshot 失效后，别急着重装系统。优先尝试从 initramfs 环境挂载旧根分区并 chroot 修复。

启动进 rescue mode 后，用 lsblk -f 找出旧逻辑卷（如 centos/root@pre-update）或 btrfs 子卷（btrfs subvolume list /mnt）
对 LVM 快照，直接 mount /dev/centos/root@pre-update /mnt；对 btrfs，先 btrfs subvolume set-default $(btrfs subvolume list / | grep pre-update | awk '{print $2}') / 再重启
若 /etc/fstab 里 UUID 已变更，进 rescue 后用 blkid 查新 UUID，并临时编辑 /mnt/etc/fstab 替换——这是 70% 的“快照能挂载但启动失败”问题的根源

回滚从来不是技术动作的堆砌，而是对变更链路每个环节的确定性验证。最危险的操作，永远发生在你确信“这步肯定没问题”的时候。