文档首页 > > 故障排除> Linux操作系统> emergency mode(紧急模式)问题处理方法

emergency mode(紧急模式)问题处理方法

分享
更新时间: 2019/08/16 11:20

操作场景

该文档使用于Linux系统emergency mode(紧急模式)问题处理。

约束与限制

该文档中涉及修复文件系统操作,修复文件系统存在丢失数据风险,请先备份数据后进行修复操作。

问题现象

Linux系统启动时进入紧急模式,提示:Welcome to emergency mode,如图1所示,并提示输入root密码进入维护。

图1 紧急模式

根因分析

紧急模式提供尽可能最小的环境,即使在系统无法进入救援模式的情况下,您也可以修复系统。在紧急模式下,系统仅安装根文件系统进行读取,不尝试安装任何其他本地文件系统,不激活网络接口,只启动一些基本服务。

进入紧急模式的原因通常的原因为:

  • /etc/fstab文件存在错误导致挂载文件系统时失败。
  • 文件系统存在错误导致。

处理方法:

  1. 输入root密码后回车,进入修复模式。
  2. 在紧急模式下根分区是以只读方式挂载,要修改根目录下的文件需要以读写方式重新挂载根分区。

    # mount -o rw,remount /

  3. 首先检查fstab文件是否存在错误,尝试挂载所有未挂载的文件系统。请执行:

    # mount -a

    • 如果出现mount point does not exist则为挂载点不存在,则创建对应的挂载点。
    • 如果出现no such device则为不存在该文件系统设备,请则注释或者删除该挂载行。
    • 如果出现an incorrect mount option was specified则为挂载参数错误,请修改为正确的参数。
    • 如果没有出现任何错误且提示UNEXPECTED INCONSISTENCY;RUN fsck MANUALLY,则通常为文件系统错误导致,请跳至步骤7
  4. 执行以下命令,打开/etc/fstab修改相应的错误。
    # vi /etc/fstab

    /etc/fstab 文件包含了如下字段,通过空格分隔:

    [file system] [dir] [type] [options] [dump] [fsck]

    • [file systems] - 要挂载的分区或存储设备。

      [file system]列建议使用UUID的方式书写,blkid命令查询设备文件系统UUID。参考格式如下:

      # <device> <dir> <type> <options> <dump> <fsck>

      UUID=b411dc99-f0a0-4c87-9e05-184977be8539 /home ext4 defaults 0 2

      使用UUID的好处在于它们与磁盘顺序无关。如果你在 BIOS 中改变了你的存储设备顺序,或是重新拔插了存储设备,或是因为一些 BIOS 可能会随机地改变存储设备的顺序,那么用 UUID 来表示将更有效。

    • [dir] - [file systems]的挂载位置。
    • [type] - 要挂载设备或是分区的文件系统类型,支持许多种不同的文件系统:ext2, ext3, ext4, reiserfs, xfs, jfs, smbfs, iso9660, vfat, ntfs, swap 及 auto。 设置成auto类型,mount 命令会猜测使用的文件系统类型,对 CDROM 和 DVD 等移动设备是非常有用的。
    • [options] - 挂载时使用的参数,注意有些参数是特定文件系统才有的。例如:defaults 参数使用文件系统的默认挂载参数,ext4 的默认参数为:rw, suid, dev, exec, auto, nouser, async。更多参数请执行以下命令查看man手册:# man mount
    • [dump] dump 工具通过它决定何时作备份. dump 会检查其内容,并用数字来决定是否对这个文件系统进行备份。 允许的数字是 0 和 1 。0 表示忽略,1 则进行备份。大部分的用户是没有安装 dump 的 ,对他们而言 [dump] 应设为 0。
    • [fsck] fsck 读取 [fsck] 的数值来决定需要检查的文件系统的检查顺序。允许的数字是0,1,和2。 根目录应当获得最高的优先权 1, 其它所有需要被检查的设备设置为 2,0 表示设备不会被 fsck 所检查。
  5. 修改完成后,确认修改是否正确,再次执行:

    # mount –a

  6. 执行以下命令,重启服务器。

    # reboot

  7. 如果步骤3中没有任何错误,则可能为文件系统错误导致,执行:

    # dmesg |egrep "ext[2..4]|xfs" |grep –i error

    说明:
    1. 输出结果中如果有I/O error ... inode 的错误信息则根因为文件系统系统错误导致。
    2. 如果上述命令没有发现日志记录文件系统文件错误则通常为超级快损坏。超级块是文件系统的“头部”。它包含文件系统的状态、尺寸和空闲磁盘块等信息。
    3. 如果损坏了一个文件系统的超级块(例如不小心直接将数据写到了文件系统的超级块分区中),那么系统可能会完全不识别该文件系统,系统启动时没有识别到文件系统导致进入紧急模式。ext2fs类型的文件系统将超级块的内容进行了备份,并存放于驱动程序的块组(blockgroup)边界。
  8. 卸载文件系统出错的目录,请执行

    # umount 挂载点

  9. 检查并修复已损坏的文件系统(修复文件系统可能会导致数据丢失请先进行数据备份)。
    1. ext系列文件系统,只检查不修复文件(以/dev/vdb1为例),请执行:

      # fsck -N /dev/vdb1

      说明
      如果出现The super block Cloud no be read or does not describe a correct ext2 filesystem 的提示请跳转至步骤10。
    2. 修复文件系统:

      # fsck /dev/vdb1

    3. xfs文件系统,只检查不修复文件

      # xfs_repair -n /dev/vdb1

    4. 修复文件系统

      # xfs_repair /dev/vdb1

      出现The super block Cloud no be read or does not describe a correct ext2 filesystem通常为为超级块损坏,如图2所示,请按照提示使用备份的超级块更新超级块。

      图2 超级块损坏

      使用备份的超级块信息更新超级块,执行:

      # e2fsck -b 8193 设备名

      图3所示更新超级块完成:

      图3 更新超级块
      说明:
      • -b 8193选项用于显示使用存放在文件系统中的8193块的超级块的备份数据。通常在主超级块已损坏时使用。备份超级块的位置是依赖的在文件系统的blocksize上。

        对于具有1k块大小的文件系统,可以在块处找到备份超级块8193;

        对于具有2k块大小的文件系统,在块16384;对于4k块,在块32768。

      • <设备名>为磁盘名称而非分区。
  10. 再次执行9
  11. 修复完成后执行以下命令,重启服务器。

    # reboot

分享:

    相关文档

    相关产品

文档是否有解决您的问题?

提交成功!

非常感谢您的反馈,我们会继续努力做到更好!

反馈提交失败,请稍后再试!

*必选

请至少选择或填写一项反馈信息

字符长度不能超过200

提交反馈 取消

如您有其它疑问,您也可以通过华为云社区问答频道来与我们联系探讨

跳转到云社区