解决:UBIFS error (ubi0:0 pid 684): ubifs_iget: failed to read inode 11731, error -2

这篇博客详细介绍了在开发环境中遇到的UBIFS文件系统错误问题。由于systemd-coredump功能在断电后生成的核心转储文件导致孤儿节点,引发了该问题。解决方案包括禁用coredump功能和修改内核代码。同时,文中提供了挂载UBI文件系统的相关指令和参考资料。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

开发环境 :

处理器: AM335x 
SDK:06_03_00_106

一、问题日

[   31.256321] UBIFS error (ubi0:0 pid 684): ubifs_iget: failed to read inode 11731, error -2
[   31.265311] UBIFS error (ubi0:0 pid 684): ubifs_lookup: dead directory entry 'core.test.0.d8ab38090e5b49faa8f42f345372ca25.610.1587262394000000.xz', error -2
[   31.281906] UBIFS warning (ubi0:0 pid 684): ubifs_ro_mode.part.0: switched to read-only mode, error -2
[   31.292427] CPU: 0 PID: 684 Comm: systemd-coredum Not tainted 4.19.94-00002-gce0d638862-dirty #510
[   31.302503] Hardware name: Generic AM33XX (Flattened Device Tree)
[   31.309567] Backtrace: 
[   31.312218] [<c010cb64>] (dump_backtrace) from [<c010ced4>] (show_stack+0x18/0x1c)
[   31.321217]  r7:ceab6528 r6:cec80330 r5:c0d03048 r4:00000040
[   31.327735] [<c010cebc>] (show_stack) from [<c086ef4c>] (dump_stack+0x24/0x28)
[   31.335352] [<c086ef28>] (dump_stack) from [<c039fd0c>] (ubifs_ro_mode.part.0+0x48/0x4c)
[   31.344856] [<c039fcc4>] (ubifs_ro_mode.part.0) from [<c039fe0c>] (ubifs_ro_mode+0x1c/0x20)
[   31.354252]  r5:c0d03048 r4:c9e6be00
[   31.358543] [<c039fdf0>] (ubifs_ro_mode) from [<c0399538>] (ubifs_lookup+0x278/0x308)
[   31.367307] [<c03992c0>] (ubifs_lookup) from [<c025a3e8>] (__lookup_slow+0x90/0x184)
[   31.375451]  r10:ce397dd0 r9:00000000 r8:ceada5d8 r7:ceab6528 r6:ce397cdc r5:c0d03048
[   31.384688]  r4:cec80330
[   31.387907] [<c025a358>] (__lookup_slow) from [<c025a514>] (lookup_slow+0x38/0x4c)
[   31.395883]  r10:00000147 r9:ce397ebc r8:00000040 r7:00000000 r6:ce397dd0 r5:ceada5d8
[   31.405103]  r4:ceab65a4
[   31.408333] [<c025a4dc>] (lookup_slow) from [<c025ad2c>] (walk_component+0x1dc/0x308)
[   31.417203]  r7:00000000 r6:00000000 r5:c0d03048 r4:ce397dc8
[   31.423182] [<c025ab50>] (walk_component) from [<c025d51c>] (path_lookupat+0x78/0x204)
[   31.432423]  r10:00000147 r9:ce397ebc r8:00000040 r7:ce397ebc r6:c0d03048 r5:00000000
[   31.441178]  r4:ce397dc8
[   31.443861] [<c025d4a4>] (path_lookupat) from [<c025f4f8>] (filename_lookup.part.13+0x9c/0x10c)
[   31.453914]  r8:00000000 r7:cf084000 r6:ce397dc8 r5:00000006 r4:c0d03048
[   31.461550] [<c025f45c>] (filename_lookup.part.13) from [<c025f67c>] (user_path_at_empty+0x54/0x5c)
[   31.471582]  r9:ce397f00 r8:00000000 r7:00440503 r6:ce397ebc r5:00000006 r4:00000000
[   31.480239] [<c025f628>] (user_path_at_empty) from [<c0253e28>] (vfs_statx+0x74/0xe0)
[   31.489296]  r6:00000006 r5:00000900 r4:00000000
[   31.494184] [<c0253db4>] (vfs_statx) from [<c02547f0>] (sys_fstatat64+0x3c/0x6c)
[   31.502891]  r10:00000147 r9:ce396000 r8:c0101204 r7:00000147 r6:00440503 r5:be9b9900
[   31.511691]  r4:c0d03048
[   31.514373] [<c02547b4>] (sys_fstatat64) from [<c0101000>] (ret_fast_syscall+0x0/0x54)
[   31.523635] Exception stack(0xce397fa8 to 0xce397ff0)
[   31.529473] 7fa0:                   00000000 0005a39b 00000006 00440503 be9b9900 00000900
[   31.538816] 7fc0: 00000000 0005a39b 00440503 00000147 0043d400 b6f6b1f4 0043d400 00440440
[   31.548103] 7fe0: 00439fa0 be9b984c 00427467 b6cff88c
[   31.553461]  r5:0005a39b r4:00000000
[   32.053698] UBIFS error (ubi0:0 pid 690): ubifs_iget: failed to read inode 11731, error -2
[   32.062694] UBIFS error (ubi0:0 pid 690): ubifs_lookup: dead directory entry 'core.test.0.d8ab38090e5b49faa8f42f345372ca25.610.1587262394000000.xz', error -2

二、产生问题原因

主要是文件系统开始了systemd-coredump 功能,当系统断电后,会在 /var/lib/systemd/coredump 目录下生成核心转储文件( core.test.0.d8ab38090e5b49faa8f42f345372ca25.610.1587262394000000.xz ),由于该文件的一个inode节点还未提交到TNC子系统,导致该节点变成一个孤儿节点,系统再次上电后会检查孤儿节点并删除,从而导致这个问题的产生。

三、解决方法

1、禁用文件系统coredump功能(治标不治本)
 修改 /etc/systemd/coredum.conf 文件,添加字段 [Storage=none]

2、修改内核文件系统代码
(1)代码patch

 @@ -691,8 +691,21 @@ static int do_kill_orphans(struct ubifs_info *c, struct ubifs_scan_leb *sleb,
 		n = (le32_to_cpu(orph->ch.len) - UBIFS_ORPH_NODE_SZ) >> 3;
 		for (i = 0; i < n; i++) {
 			union ubifs_key key1, key2;
+			struct ubifs_ino_node *ino;
+
+			ino = kmalloc(UBIFS_MAX_INO_NODE_SZ, GFP_NOFS);
+			if (!ino)
+				return -ENOMEM;
 
 			inum = le64_to_cpu(orph->inos[i]);
+			ino_key_init(c, &key1, inum);
+			err = ubifs_tnc_lookup(c, &key1, ino);
+			if (!err && ino->nlink) {
+				kfree(ino);
+				continue;
+			}
+			kfree(ino);
+
 			dbg_rcvry("deleting orphaned inode %lu",
 				  (unsigned long)inum);

参考链接:
1、https://www.spinics.net/lists/linux-mtd/msg06319.html
2、https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/fs/ubifs/orphan.c?id=ee1438ce5dc4d67dd8dd1ff51583122a61f5bd9e

(2) 程序流程调用

ubifs_mount_orphans-->
  kill_orphans-->
    do_kill_orphans
int ubifs_mount_orphans(struct ubifs_info *c, int unclean, int read_only):
此函数在挂载时被调用,用于擦除前一个会话中的孤儿。如果没有干净地卸载UBIFS,
那么作为孤儿记录的索引节点将被删除

int kill_orphans(struct ubifs_info *c):
如果需要进行恢复,则必须从索引中删除前一个会话期间记录的孤儿索引节点(该会话以不干净的卸载结束)。
这是通过更新TNC来完成的,但是由于索引直到下一次提交才会更新,
所以记录孤儿信息的leb直到下一次提交才会被擦除。

int do_kill_orphans(struct ubifs_info *c, struct ubifs_scan_leb *sleb,
unsigned long long *last_cmt_no, int *outofdate, int *last_flagged):
它遍历LEB中的每个孤儿节点,对于记录的每个inode编号,从TNC中删除该inode的所有键。

四、涉及到ubif文件挂载的指令

1、挂载ubi文件系统

(1)ubiattach /dev/ubi_ctrl –m 10 –O 2048 
   UBI控制设备默认为/dev/ubi_ctrl(如果没有提供)。
   ubiattach: 将MTD设备(描述原始flash)连接到UBI并创建相应的UBI设备
   -m: 要附加的MTD设备号(替代方法,如字符设备节点不存在)
   -O: VID头偏移量(除非你真的知道你在做什么,否则不要指定这个,默认应该是最优的)
   
 (2) mount -t ubifs ubi0_0 /mnt/
     将ubi文件系统挂载到 /mnt 目录下

2、挂载ubi文件系统开启文件系统检测功能

echo 1 > /sys/kernel/debug/ubifs/chk_fs

更多ubi功能介绍请参考链接:http://www.linux-mtd.infradead.org/faq/ubifs.html

<think>首先,用户的问题是关于UBIFS错误的:"UBIFS error ubi3:0 pid 3262 ubifs_scan LEB 11 scanning failed fix"。用户想查找解决方法。 根据系统指令: - 所有行内数学表达式必须使用$...$格式,但这里没有数学表达式,所以可能不需要。 - 独立公式必须使用$$...$$格式并单独成段,但同样,这里可能不涉及数学公式。 - LaTeX语法正确:确保在需要时正确使用。 - 使用中文回答:整个响应必须用中文。 - 生成相关问题:在回答末尾,生成相关问题。 - 回答中引用的段落末尾自然地添加引用标识:例如[^1],根据提供的引用。 - 回答结构清晰:帮助用户逐步解决问题,保证回答真实可靠。 用户提供的引用: - 引用[1]:关于Zynq-Linux移植、UBIFS错误解决等。 - 引用[2]:显示了一些文件和目录列表,似乎与ubi-utils工具相关。 - 引用[3]:关于解压ubi文件和挂载根文件系统。 这些引用可能来自之前的上下文或站内文档,我需要参考它们来提供解决方案。 关键错误:"UBIFS error ubi3:0 pid 3262 ubifs_scan LEB 11 scanning failed"。这表示在扫描LEB(Logical Erase Block)11时失败。 UBIFSUBI File System)是基于UBI(Unsorted Block Images)的文件系统,常用于嵌入式系统。错误可能涉及文件系统损坏、UBI配置问题或硬件问题。 步骤解决: 1. **理解错误**:错误发生在扫描LEB时,可能意味着该块损坏或无效。LEB是UBI的逻辑块。 2. **常见解决方法**: - **检查硬件**:确保存储设备(如NAND flash)没有物理损坏。 - **使用ubi-utils工具**:如ubiformat、ubidetach、ubiattach等,来修复文件系统。 - **重新格式化UBI卷**:如果文件系统损坏,可能需要重新格式化。 - **检查内核日志**:获取更多错误细节。 - **参考文档**:如UBI文档或社区讨论。 从引用中: - 引用[1]提到解决CRC错误,可能相关。 - 引用[2]显示ubi-utils工具,可以用来操作UBI卷。 - 引用[3]涉及挂载ubi根文件系统,可能提供挂载步骤。 基于此,构建响应: - 逐步指导解决错误。 - 在适当位置添加引用标识。 - 最后生成相关问题。 响应结构: 1. **介绍问题**:解释错误含义。 2. **逐步解决方法**: - 检查日志。 - 使用ubi-utils工具修复。 - 重新格式化或重新创建卷。 - 其他建议。 3. **添加引用**:在相关段落末尾添加[^1]、[^2]等。 4. **生成相关问题**:在末尾。 相关问题生成: 1. 如何预防UBIFS错误? 2. UBI文件系统的最佳实践是什么? 3. 如何调试UBIFS扫描失败? 确保回答真实可靠:基于标准UBI/UBIFS知识。</think>### UBIFS错误“ubifs_scan LEB 11 scanning failed解决方法 您遇到的错误“UBIFS error ubi3:0 pid 3262 ubifs_scan LEB 11 scanning failed”表示在扫描逻辑擦除块(LEB)11时发生了故障。UBIFSUBI File System)是基于UBI(Unsorted Block Images)的文件系统,常用于嵌入式Linux设备(如使用NAND flash存储的系统)。这种错误通常由文件系统损坏、UBI配置不当、硬件问题(如坏块)或内核模块问题引起。下面我将逐步指导您解决此问题,确保方法真实可靠,基于UBI/UBIFS的标准文档和社区实践。参考了您提供的引用内容,我会在相关步骤末尾添加引用标识。 #### 步骤1: 确认错误细节和日志 首先,检查系统日志以获取更多错误上下文。这有助于判断是偶发错误还是持续性问题。 - 运行命令查看内核日志: ```bash dmesg | grep -i "ubifs\|ubi" ``` - 查找类似输出: ``` UBIFS error (pid 3262): ubifs_scan: LEB 11 scanning failed ``` 如果日志显示CRC校验错误或坏块信息,可能指向硬件问题或文件系统损坏[^1]。 - **建议**:如果日志中出现“CRC error”或“bad block”,优先检查存储设备(如NAND flash)的健康状况。您可以使用工具如`mtdinfo`(来自mtd-utils包)来检测坏块: ```bash mtdinfo /dev/mtdX # 替换X为您的MTD设备号 ``` 引用[2]中提到了`mtdinfo`工具,它可以提供MTD分区信息[^2]。 #### 步骤2: 使用ubi-utils工具修复文件系统 UBI提供了一套实用工具(ubi-utils),用于修复或重新初始化文件系统。以下是关键步骤: - **卸载并分离UBI卷**: ```bash umount /mnt/ubi # 替换为您的挂载点 ubidetach -d 3 # -d 3 对应错误中的ubi3,表示UBI设备号 ``` 这会分离UBI设备,防止进一步写入。 - **检查和修复文件系统**: 使用`ubiformat`工具重新格式化UBI卷。这可以修复扫描失败错误,但会清除数据(确保备份重要数据)。 ```bash ubiformat /dev/mtdX # 替换X为MTD设备号,例如mtd3 ``` 然后重新附加UBI卷: ```bash ubiattach -d 3 -m X # -d 3 指定设备号,-m X指定MTD号 ``` 引用[2]中列出了`ubiformat`和`ubiattach`工具,这些是ubi-utils的核心组件[^2]。如果工具缺失,请安装mtd-utils包(如`sudo apt-get install mtd-utils`)。 - **重新创建UBIFS文件系统**: 格式化后,重新创建文件系统: ```bash ubimkvol /dev/ubi3 -N rootfs -m # -N 指定卷名,-m 表示最大大小 mkfs.ubifs -r /path/to/rootfs -m 2048 -e 126976 -c 2048 -o ubifs.img # 根据您的系统参数调整 ubiupdatevol /dev/ubi3_0 ubifs.img # 写入镜像 ``` 最后,重新挂载: ```bash mount -t ubifs ubi3:rootfs /mnt/ubi ``` 引用[3]涉及挂载UBI根文件系统,类似步骤可应用于此[^3]。 #### 步骤3: 检查硬件和内核配置 如果上述步骤无效,问题可能源于硬件或内核: - **硬件检查**:使用NAND flash检测工具(如`nandtest`)扫描坏块: ```bash nandtest /dev/mtdX ``` 如果发现坏块,在UBI配置中启用坏块处理(内核配置中启用`CONFIG_MTD_UBI_BEB_LIMIT`)。 - **内核模块加载**:确保UBIUBIFS内核模块已加载: ```bash modprobe ubi modprobe ubifs ``` 检查内核日志是否有模块加载错误。 - **UBI配置优化**:在`/etc/fstab`或内核启动参数中,添加`ubi.mtd=X`指定MTD设备,避免设备号冲突。例如: ``` ubi.mtd=3 root=ubi3:rootfs rootfstype=ubifs ``` 引用[1]讨论了UBI启动参数配置,可参考解决类似错误[^1]。 #### 其他建议 - **备份和恢复**:定期备份UBIFS镜像,使用`ubiupdatevol`恢复。 - **性能监控**:在运行中监控UBI状态: ```bash ubinfo -d 3 # 查看UBI设备3的详细信息 ``` - **社区资源**:参考UBI官方文档或论坛(如Linux MTD邮件列表),许多类似错误已通过工具修复[^1][^2]。 如果问题持续,提供更多日志细节(如完整dmesg输出)可进一步诊断。 ### 相关问题 1. 如何预防UBIFS扫描失败错误的发生? 2. UBI文件系统在嵌入式系统中的最佳实践有哪些? 3. 如何调试UBIFS挂载失败或CRC错误?
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值