☰

嵌入式 Linux (A20 Olimex Lime 2) 上的 EXT4 文件系统损坏且干净断电

tag-icon • tag-icon filesystems ext4 embedded corruption
嵌入式 Linux (A20 Olimex Lime 2) 上的 EXT4 文件系统损坏且干净断电

语境

我来这里是想和大家讨论一个我不明白的 EXT4 文件系统问题。在我的公司，我们正在研究嵌入式Linux系统。我们用的是板子奥利梅克斯石灰 2。

T2-OLinuXino-LIME2-e16Gs16M-IND

我们使用基于Olinux镜像的镜像（A20-OLinuXino-bullseye-minimal-20230515-130040.img.)

实际上，我们正在尝试测试文件系统的抵抗力。

我们如何做到这一点？

一个自动驱动板交流电源。它定期打开和关闭交流电源。

当 Olimex Lime 2 启动时，它会切换连接到自动化设备的引脚输出，以显示它处于活动状态并且系统已正常启动。

如果上电2分钟后系统还没有启动，我们检测到错误并停止测试。

当自动关闭开发板电源时，开发板中的脚本会运行命令poweroff来关闭系统（这就是为什么有电池）。

2 分钟后，电路板自动通电，我们重复这个循环。

我们使用 RaspberryPi 来保存主板日志。该树莓派通过串行通信连接。

使用的Linux镜像

我们的镜像由三个分区组成（全部在 ext4 中）：

  • boot：包含内核及其资产
  • root: 主文件系统
  • data：存储数据（例如：日志）

前两个处于只读模式。只有第三个允许读写。

我们主要使用 Docker 来部署和执行我们的应用程序。

问题 ：（

半天后，分区data似乎已损坏，系统以紧急模式启动。

[FAILED] Failed to start File Systeâ¦ck on /dev/disk/by-label/data.
See 'systemctl status "systemd-fsck@devâ¦y\\x2dlabel-data.service"' for details.
[DEPEND] Dependency failed for /mnt/data.
[DEPEND] Dependency failed for Local File Systems.
         Starting Load AppArmor profiles...
         Starting Set console font and keymap...
         Starting Create Volatile Files and Directories...
[  OK  ] Finished Set console font and keymap.
[  OK  ] Finished Create Volatile Files and Directories.
         Starting Update UTMP about System Boot/Shutdown...
[  OK  ] Finished Update UTMP about System Boot/Shutdown.
         Starting Update UTMP about System Runlevel Changes...
[  OK  ] Finished Update UTMP about System Runlevel Changes.
[FAILED] Failed to start Load AppArmor profiles.
See 'systemctl status apparmor.service' for details.
[  OK  ] Started ifup for eth0.
         Starting Raise network interfaces...
[  OK  ] Finished Raise network interfaces.
[  OK  ] Reached target Network.
[  OK  ] Reached target Network is Online.
You are in emergency mode. After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" or "exit"
to boot into default mode.
Give root password for maintenance

完整日志在这里

FSCK

fsck from util-linux 2.34                                                 
e2fsck 1.45.5 (07-Jan-2020)                                               
Pass 1: Checking inodes, blocks, and sizes                                
Pass 2: Checking directory structure                                      
Directory inode 170220, block #0, offset 0: directory has no checksum.    
Fix? no                                                                   
                                                                          
Directory inode 170220, block #0, offset 0: directory corrupted           
Salvage? no                                                               
                                                                          
e2fsck: aborted                                                           
                                                                          
data: ********** WARNING: Filesystem still has errors **********

调试文件系统

#> sudo debugfs -R 'ncheck 170220' /dev/sdk3                                                   
                                                                                                 
debugfs 1.45.5 (07-Jan-2020)                                                                                                 
Inode   Pathname                                                                                                             
170220  /system/var/lib/docker/image/overlay2/layerdb/sha256/b5fe77bd4ece5a7f9ed642c1efc878aaddf4e9c9b49514e1ab0e9799505be38d

其他详情

  • 我们是测试中的两个板，他们使用了相同的图像，一个我们使用SD卡，另一个我们使用嵌入式emmc。出现问题仅有的在SD卡板上。

  • 在最后一次断电之前（在主板无法正确启动之前），我们有一个关于 ext4 fs 错误的内核日志：

a20-olinuxino login: [   34.961248] EXT4-fs error (device mmcblk0p3): __ext4_find_entry:1547: inode #170220: comm0

我不明白这个错误，你能帮我吗？

祝你有美好的一天 ！

相关内容