紧急模式问题处理 - 图 1 紧急模式根本原因分析应急模式提供了尽可能小的环境，即使无法进入应急模式，也可以在其中修复系统。在应急模式下，系统只安装根文件系统供读取，不尝试安装任何其他本地文件系统，不激活网络接口，只启动一些基本服务。进入应急模式的原因通常是 /etc/fstab 文件中存在错误，导致文件系统挂载失败。文件系统中存在错误，导致。约束和限制本节适用于 Linux 操作系统紧急模式。程序涉及修复文件系统。修复文件系统有丢失数据的风险，因此请先备份数据，然后再执行修复操作。处理方法输入根密码，然后进入修复模式。在应急模式下，根分区以只读模式挂载。要修改根目录中的文件，需要执行以下命令以读写模式重新挂载根分区。# mount -o rw,remount / 请执行以下命令首先检查 fstab 文件是否有误，然后尝试挂载所有未挂载的文件系统。# mount -a 如果挂载点不存在，请创建一个挂载点。如果不存在此类设备，请注释或删除挂载行。如果指定了不正确

最编程 2024-03-28 13:43:43

...

[dump]

dump工具通过它决定何时作备份。 dump会检查其内容，并用数字来决定是否对这个文件系统进行备份。

取值为0和1 。0表示忽略，1则进行备份。大部分的用户是没有安装dump的，[dump]应设为0。

[fsck]

fsck读取[fsck]的数值来决定需要检查的文件系统的检查顺序。

取值为0，1，和2。根目录应当获得最高的优先权1, 其它所有需要被检查的设备设置为2，0表示设备不会被fsck所检查。

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

执行以下命令，重启服务器。# reboot

如果步骤3中没有任何错误，则可能为文件系统错误导致，执行：# dmesg |egrep "ext[2..4]|xfs" |grep -i error

emergency mode（紧急模式）问题处理方法_文件系统_02

说明：

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

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

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

-b 8193选项用于显示使用存放在文件系统中的8193块的超级块的备份数据。通常在主超级块已损坏时使用。备份超级块的位置是依赖的在文件系统的blocksize上。对于具有1k块大小的文件系统，可以在块处找到备份超级块8193。
对于具有2k块大小的文件系统，在块16384;对于4k块，在块32768。

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

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