emergency mode（紧急模式）问题处理方法

问题现象

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

图1 紧急模式

根因分析

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

进入紧急模式的原因通常是：

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

约束与限制

本节操作适用于Linux操作系统emergency mode（紧急模式）问题处理。操作步骤涉及修复文件系统操作，修复文件系统存在丢失数据风险，请先备份数据后进行修复操作。

处理方法

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]

   表1 /etc/fstab参数说明

   参数	说明
   [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所检查。

1. 修改完成后，确认修改是否正确，再次执行以下命令首先检查fstab文件。

   # mount -a

2. 执行以下命令，重启服务器。

   # reboot

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

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

说明：

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

     # umount 挂载点

  2. 检查并修复已损坏的文件系统。
     须知：

     修复文件系统可能会导致数据丢失请先进行数据备份。

     • ext文件系统，执行以下命令，检查文件系统是否存在错误。

       # fsck -n /dev/vdb1

       说明：

       如果出现The super block Cloud no be read or does not describe a correct ext2 filesystem的提示请跳转至10。

       如果需要修复，执行以下命令，修复文件系统。

       # fsck /dev/vdb1

     • xfs文件系统，执行以下命令，检查文件系统是否存在错误。

       # xfs_repair -n /dev/vdb1

       如果需要修复，执行以下命令，修复文件系统。

       # xfs_repair /dev/vdb1

  3. （可选）出现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。

    <设备名>为磁盘名称而非分区。

    修复完成后执行以下命令，重启服务器。

    # reboot