问题记录:开机提示emergency mode(紧急模式)如何处理

本文涉及的产品
应用实时监控服务-可观测链路OpenTelemetry版,每月50GB免费额度
注册配置 MSE Nacos/ZooKeeper,118元/月
Serverless 应用引擎免费试用套餐包,4320000 CU,有效期3个月
简介: 在依赖Linux作为核心操作系统的环境中,系统的稳定和可靠性通常是我们理所当然的期待。然而,即使是最稳定的系统,有时也会在启动时出现异常,突然推到紧急模式的怀抱。这种模式,通常有被称为“Emergency Mode”,在Linux系统面临关键错误时作为一种安全网,但对于那些不熟悉如何应对此类问题的小伙伴来说,它可能带来困惑甚至恐慌。

怎么办.jpg

问题记录:开机提示emergency mode(紧急模式)如何处理

引言

在依赖Linux作为核心操作系统的环境中,系统的稳定和可靠性通常是我们理所当然的期待。然而,即使是最稳定的系统,有时也会在启动时出现异常,突然推到紧急模式的怀抱。这种模式,通常有被称为“Emergency Mode”,在Linux系统面临关键错误时作为一种安全网,但对于那些不熟悉如何应对此类问题的小伙伴来说,它可能带来困惑甚至恐慌。

想象一下,重启你的服务器后,不是欢迎你的是熟悉的登录提示,而是一条紧急模式的提示,要求你处理某些未知的错误。这篇文章将详细记录这一模式,并提供实用的步骤来帮助你解决这类突发事件。

问题现象

开机后,Linux系统启动时不是通常的登录界面,而是进入紧急模式,提示:Welcome to emergency mode,并提示输入root密码进入维护。表明系统无法正常启动。

解决思路

紧急模式是Linux内核提供的一种特殊状态,用于在遇到严重错误时仍能尝试让系统管理员进行有限的操作。在此模式下,系统通常只加载根文件系统为只读模式,并不启动其他非必需服务,以最大限度地减少潜在的损害。

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

  • /etc/fstab文件配置存在错误导致挂载文件系统时失败。
  • 文件系统存在错误导致。
  • 或系统更新后的脚本错误。

操作步骤

这类操作适用于Linux操作系统下出现emergency mode(紧急模式)。操作步骤涉及修复文件系统操作。

并且提示一下:修复文件系统确确实实存在丢失数据风险的概率!

开始操作

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

mount -o rw,remount /

  1. 请执行以下命令首先检查fstab文件是否存在错误,尝试挂载所有文件系统。

mount -a

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

vi /etc/fstab

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

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

/etc/fstab参数补充说明

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

mount -a

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

reboot

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

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

说明:

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

umount 挂载点

  1. 检查并修复已损坏的文件系统。
  • 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

  1. (可选)出现The super block Cloud no be read or does not describe a correct ext2 filesystem通常为超级块损坏,请按照提示使用备份的超级块更新超级块。

执行以下命令,使用备份的超级块信息更新超级块。

e2fsck -b 8193 设备名

如下所示表示更新超级块完成:

说明:

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

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

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

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

reboot

结果与验证

通过上述步骤,应能成功将系统从紧急模式中恢复出来。验证系统是否正常运行,可以通过检查系统日志和监控一段时间的系统表现来进行。

总结与建议

遵循本指南,希望遇到该情况的小伙伴已成功将Linux系统从紧急模式中恢复,并使其回到正常运作状态。为防止未来出现类似问题,建议定期进行系统审计,检查文件系统的健康状态,保持系统更新,并实施有效的数据备份计划。维持对系统日志的定期审查也有助于及早发现潜在问题。






最后~欢迎关注我! @Linux学习的那些事儿

我的个人资源整理,满满都是干货: 无任何套路,有需要可以访问领取

200T免费资源专区,持续发布中...

如果本文对你有帮助,欢迎点赞、收藏、转发给朋友,让我有持续创作的动力!

相关文章
|
Linux 开发工具
9.2.4 vim 的暂存盘、救援回复与打开时的警告讯息
9.2.4 vim 的暂存盘、救援回复与打开时的警告讯息
68 0
Debian 系统 重启后iptables规则无法保存或者丢失
Debian 系统 重启后iptables规则无法保存或者丢失
1460 0
|
Shell Linux
linux配置超时不操作自动退出登录TMOUT
linux配置超时不操作自动退出登录TMOUT
1517 0
|
Linux
系统修复模式(Recovery mode) 的体验
一次系统崩溃经历,偶遇Recovery mode的故事。
3404 0