设备启动进入紧急模式故障排查指南

1 背景

用户在使用ED-CM4SEN和Raspbe Pi 4时，上电启动设备时，可能出现设备无法正常进入桌面的情况，连接HDMI发现屏幕上显示（以ED-CM4SEN为例）

image-20240905135214430
You are in emergency mode. After logging in, "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" or "exit" to boot into default mode.
Cannot open access to console ,the root accout is locked.
See sulogin(8) man page for more details.
Press Enter to continue.

您已进入紧急模式。登录后，使用 “journalctl -xb ”查看系统日志，使用 “systemctl reboot ”重新启动，使用 “systemctl default ”或 “exit ”启动到默认模式。
无法打开控制台访问权限，root 账号已锁定。
有关详细信息，请参阅 sulogin(8) 手册。
按 Enter 继续。

表明系统在启动时进入了紧急模式。紧急模式提供尽可能最小的环境，即使在系统无法进入救援模式的情况下，也可以尝试修复系统。

在紧急模式下，系统仅安装根文件系统进行读取，不尝试安装任何其他本地文件系统，不激活网络接口，只启动一些基本服务。

2 原因分析

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

  • 文件系统存在错误导致。

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

  • 外部存储设备损坏。

导致这些问题的操作可能包括暴力关机、直接断电或错误修改了 fstab 文件、外部存储设备磨损过度等。

本指南将排查并解决此问题。

3 故障排查

1 文件系统损坏

​ 设备启动进入紧急模式时，如果连接HDMI显示器并且没有显示任何 systemd 服务成功启动的信息，说明系统启动过程未能进入 systemd，可能的原因是文件 系统损坏。遇到这种情况时，请参考附录：fstab修复修复文件系统。

2 PARTUUID重复

以ED-CM4SEN为例，默认情况下系统只能从eMMc启动，并且系统启动路径中不包含从外部存储设备启动。如果用户使用可插拔设备(U盘、SD卡)等烧录了镜像，在文件系统中eMMc和外部存储设备会被识别为相同的PARTUUID，当系统从eMMc启动失败时，会根据PARTUUID寻找可插拔设备的/boot分区，当设备不支持从可插拔设备启动时，就会导致启动失败。

  1. 使用如下命令检查磁盘的PARTUUID

    lsblk -o NAME,PARTUUIDcat /etc/fstab

image-20240905140949972

​ 此时发现eMMc和外部存储设备分区的PARTUUID都相同，fstab以PARTUUID作为识别符，因此存在启动失败的风险。

  1. 给设备关机并断电，手动卸载外部存储设备，将外部存储设备格式化后重新安装后启动设备，确保设备仅从eMMc启动，如果仍然进入紧急模式，参考下面的指引。

  2. fstab的修复步骤请参考附录。附录：fstab修复

3 外部存储设备损坏

​ 当外部存储设备由于长期进行数据读写导致过度磨损时，可能会导致设备启动时进入紧急模式。

​ 卸载外部存储设备，对外部存储设备进行更换后，重新启动设备，观察是否在启动时进入紧急模式，判断原因是否为外部存储设备磨损。

4 问题预防

设备启动时进入紧急模式的主要原因是文件系统损坏和外部磁盘干扰。 为防止文件系统损坏，请遵循以下步骤：

  1. 正常关机：请始终使用系统提供的正常关机程序来关闭设备。避免直接断开电源，以减少文件系统损坏的风险。在Linux系统中，可以通过执行 sudo shutdown -h now 或 sudo poweroff 命令来安全关闭设备。
  2. 检查磁盘状态：定期检查文件系统的健康状态。可以使用 fsck 工具来检查和修复文件系统错误。例如，运行 sudo fsck /dev/sdX（将 /dev/sdX 替换为实际的设备名称）来扫描和修复文件系统错误。
  3. 使用UPS（不间断电源）：为设备配置不间断电源供应（UPS），以防止由于突然断电而导致的文件系统损坏。UPS 可以在电力故障时为设备提供临时电源，确保设备能够正常关机。
  4. 外部设备管理：在连接和断开外部磁盘时，务必使用系统的卸载或弹出功能，以确保所有数据都已正确写入磁盘并避免文件系统损坏。可以使用 umount 命令来安全卸载外部存储设备。
  5. 数据备份：定期备份重要数据，以便在文件系统损坏或其他故障发生时能够恢复数据。定期备份可以减轻数据丢失的影响。
  6. 固件和软件更新：确保设备的固件和操作系统保持最新。更新通常包含修复已知的漏洞和问题，这可以提高系统的稳定性和可靠性。

通过采取上述措施，可以有效降低文件系统损坏的风险，并提高设备的稳定性和可靠性。

附录：fstab修复

  1. 在紧急模式的界面按“Enter”确认，输入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修改相应的错误。

    nano /etc/fstab

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

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

    参数说明
    [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。根目录或当前获得最高的优先权，其他所有需要被检查的设备设为2，0表示 设备不会被fsck所检查。

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

​ mount -a 6. 执行以下命令，重启服务器。

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

​ dmesg |egrep "ext[2..4]|xfs" |grep -i error ​ 说明：

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

  1. 请执行以下命令，卸载文件系统出错的目录，

    umount 挂载点

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

    WARNING

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

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

    fsck -n /dev/vdb1

    WARNING

    如果出现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通常为超级块损坏，如图所示，请按照提示使用备份的超级块更新超级块。

​ image-20240905140310991

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

​ e2fsck -b 8193 设备名 ​ 如图所示表示超级快更新完成

​ image-20240905140357418

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

​ reboot