Live 修复适合什么情况
系统盘上的根文件系统损坏、关键软件包被误删、配置写错导致进不了系统时，可以用同版本安装介质选 Live 模式启动，把原系统分区挂到 /mnt 下，再用 chroot 切进去当作正常运行的系统来修包和改配置。相比单用户模式，它不依赖故障系统自身能否启动，操作空间更大，也能直接备份数据。
与救援模式的分工
救援模式仍然要经过故障系统自身的引导与初始化，配置或软件包层面的问题往往正好卡在这一步；Live 模式下运行的是一套独立的内存系统，原系统盘只作为数据挂载上来，因此引导损坏、fstab 写错、基础库被换掉这类故障都更适合用 Live 处理。代价是需要现场能接入安装介质或带外挂载镜像。
基本信息
| 启动入口 | 安装介质引导菜单中选 Live 或试用模式 |
|---|---|
| 核心步骤 | 识别分区、挂载根、绑定 /dev /proc /sys、chroot、修复 |
| 常用修复 | 重装损坏软件包、恢复误改的 /etc 配置、重建引导 |
| 风险等级 | 写操作直接作用于生产系统盘，动手前先备份数据 |
典型使用场景
- 关键服务包被卸载或损坏，系统能挂载但服务起不来
- fstab 或网络配置写错导致系统卡在启动阶段
- root 口令遗忘，需要在离线环境下重新设置
- 引导加载程序损坏，系统盘数据完好但无法进入
- 怀疑根分区文件系统不一致，需要离线做检查与修复
chroot 修复流程
chroot 修复流程
lsblk -f # 先认清根分区、引导分区与文件系统类型
mount /dev/vg0/root /mnt # LVM 需先 vgchange -ay 激活卷组
mount /dev/sda2 /mnt/boot # 独立引导分区才需要这一步
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt # 进入原系统的根环境
dnf reinstall -y openssh-server # 示例：重装受损的软件包
exit # 修完逐层退出上手前的检查项
| 检查项 | 目的 | 命令 |
|---|---|---|
| 分区与文件系统 | 确认根分区位置与类型，避免挂错盘 | lsblk -f |
| 逻辑卷或加密卷 | 未激活或未解锁的卷无法挂载 | vgchange -ay、cryptsetup luksOpen |
| 介质版本 | 修复用仓库应与系统版本一致 | cat /mnt/etc/os-release |
| 数据备份 | 修复过程存在写盘风险 | 先复制关键数据到外置盘 |
| 引导分区 | 重装内核或引导前确认其位置 | findmnt /boot、ls /mnt/boot/efi |
修复完成后按 umount /mnt/sys、/mnt/proc、/mnt/dev、/mnt/boot、/mnt 的顺序逐层卸载再重启，直接拔盘会让缓存中的写入来不及落盘。
动手之前先把业务数据复制到外置介质：chroot 下的包重装会改动系统盘，方向错了回退成本远高于提前拷一份。系统盘已有硬件故障迹象时，优先做整盘镜像再修复。