linux 系统进入紧急模式（emergency mode）处理_linux系统开机进入emergency

问题表现：

centos7 系统，启动报错进入紧急模式（emergency mode）

出现原因：

强制关机造成。

问题处理流程：

一、根据提示，使用 journalctl 命令查看系统日志

但是此处无法查看 Corruption warning 详细信息

二、查看报错详细信息

/run/initramfs/rdsosreport.txt

关键内容：

        ①挂载 /sysroot 失败：根系统挂载失败

        ②Corrutption warning: Metadata has LSM(26:63956) ahead of current LSN(26:62980). Please unmount and run xfs_repair (>= v4.3) to resolve. XFS 文件系统的元数据日志和实际文件系统状态不一致，LSM(26:63956) 序列号大于当前 LSN(26:62980)。

关于“元数据日志”说明：

        XFS 是一种日志文件系统，使用日志来记录对元数据（如 inode、目录结构、空闲空间信息等）的更改（包括文件的创建、删除、重命名，以及文件系统结构的调整等）（类似于 Oracle 的 redo log），当元数据发生更改时，变更先被写入日志，然后才会被实际写入磁盘。当系统崩溃或者意外关机时，那些还未写入磁盘的变更会丢失，但是由于日志中保存的有记录，因此可以在重启进行磁盘挂载时，可以使用日志中的记录，对元数据进行 replay（相当于 Oracle 的 redo 重做），这样崩溃时未及时写入磁盘的变更会根据日志记录重新写。以此恢复文件系统的一致性。

        LSN（Log Sequence Number）：日志序列号，用于记录日志的顺序，每个日志都有唯一的 LSN。

        LSM（Log Sequence Number in Metadata）：元数据中记录的 LSN。

        当前 LSN（Current LSN）：日志中最新的 LSN。

        当元数据中的 LSN（LSM）大于当前日志中的 LSN 时，说明日志和元数据不一致，此时就需要进行 replay，以恢复数据一致性（即 LSM 和 LSN 保持一致）。

分析可知错误产生根本原因及处理方案：

        错误产生的原因在于 current LSN 和 LSM 不一致，需要重新执行 mount（如果系统已经处于挂载状态，需要进行 unmount 进行重新挂载），以便在挂载过程中自动进行 replay，恢复数据一致性。

三、根据提示，对根文件系统执行 xfs_repair 进行修复

报错内容分析：

        元数据日志中存在需要进行 replay 的日志记录，需要 mount 之后 replay 这些记录，如果 mount 失败，需要添加 -L 参数清空日志记录，然后再次尝试 repair。（注意：-L 清空日志记录可能因此数据损坏，因此，在清空之前，一定要先尝试 mount，mount 失败再尝试清空。）

四、查看当前系统所有已挂载文件系统

mount 执行结果分析：

        在这个挂载清单中，可以看出，根文件系统已经挂载（rootfs on / type rootfs），但是文件系统类型为 rootfs，这个 rootfs 是 Linux 内核创建的一个临时文件系统，用于在系统启动的早期阶段挂载根文件系统。在正常启动过程中，它会被实际的根文件系统（如 /dev/mapper/centos-root，在 /dev/mapper 目录下查看实际名称）替换。如果你看到 rootfs 挂载在 /，这通常意味着系统可能处于紧急模式或救援模式。

查看当前根目录下内容：

可以看出：

        此时根文件系统并非我们的根文件系统，我们实际的文件系统 /dev/mapper/centos-root 并未挂载。

处理方案：

        先尝试挂载 /dev/mapper/centos-root 至一个新建的目录 /mnt，如果挂载失败，再清空元数据日志执行修复，再次挂载。

五、挂载 /dev/mapper/centos-root 至 /mnt（/mnt 不存在就 mkdir 新建一个）

报错内容分析：

        列出了一堆可能出现的错误原因，总结来说，就是挂载失败！

处理方案：

        使用 xfs_repair -L 参数清空元数据日志

六、xfs_repair -L 清空元数据日志进行修复

七、重新挂载根文件系统至 /mnt，并查看内容

可以看出：挂载成功。

可以看出：确实为我们实际的文件系统，且内容完整可用。

处理方案：

        文件系统内容正常可用，但是系统无法启动，说明引导加载程序可能存在问题，需要重新安装引导加载程序。

八、重新安装引导加载程序

1.挂载 / 根文件系统和 /boot 分区

# mount /dev/mapper/centos-root /mnt# mount /dev/sda1 /mnt/boot

作用：相当于把系统启动时候使用的 / 根文件系统和 /boot 系统给挂载到对应的 /mnt 和 /mnt/boot下，使用 chroot 就可以把 /mnt 当做系统的 / 来处理。

原因：/dev/mapper/centos-root 是系统启动使用的 / 分区设备，/dev/sda1 是系统启动使用的 /boot 分区设备。

2.使用 chroot 进入挂载在 /mnt 的根文件系统

        # chroot /mnt

3.重新安装 grub2

        ①在 chroot 环境中，重新安装 GRUB2 到系统主引导记录（MBR）

                # gurb2-install /dev/sda

        报错分析：没有发现设备（/dev 没有挂载）。也就是我们的根文件系统，没有挂载设备。

        错误处理：挂载 /dev 至 /mnt/dev 

                # exit                                                //退出 chroot

                # mount --bind /dev /mnt/dev           //挂载 /dev 到 chroot 的根文件系统中

                # chroot                                            //重新进入 chroot 根文件系统中

                # ls /dev                                            //在 chroot 的根文件系统中查看设备是否已挂载  

        ②错误排除后，再次安装 grub2

4.生成新的 grub2 配置文件，并保存至 /boot/grub2/grub.cfg

5.退出 chroot 环境

        # exit

6.按顺序卸载分区，并重启

        # umount /mnt/dev

        # umount /mnt/boot

        # umount /mnt

        # reboot