[转]解决journal block not found错误

最新推荐文章于 2024-06-05 16:44:14 发布
转载 最新推荐文章于 2024-06-05 16:44:14 发布 · 2.4k 阅读 · 0
文章标签：

#ext #磁盘 #tags

本文介绍了解决Linux系统中因journalblocknotfound错误导致的根分区只读问题的方法。通过转换文件系统、修复并重建日志，成功使根分区恢复正常。

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

原贴:http://www.linuxfly.org/read.php/255.htm

[转]解决journal block not found错误 雨
linuxing , 22:47 , 基础知识 » 故障处理 , 评论(0) , 引用(0) , 阅读(179) , Via 本站原创 大 | 中 | 小
   某机器，系统运行一段时间之后根分区都会变成只读。当使用光盘进入拯救模式后，用

# dumpe2fs -h /dev/sda1

可以看到文件系统的状态是 “clean with errors”。
用fsck进行系统检查时，报如下错误：
引用
journal_bmap_Rsmp_6199acb1: journal block not found at offset 5132 on md(9,0)
Aborting journal on device md(9,0).
ext3_abort called.
EXT3-fs abort (device md(9,0)): ext3_journal_start: Detected aborted journal
Remounting filesystem read-only

该错误表明ext3文件系统有一部分的日志丢失了。由于fsck并不能恢复日志，需要手动重建磁盘日志。

重建ext3的日志：
进入rescue模式
1）将sda1转换为ext2，即去掉ext3的日志：

# tune2fs -O ^has_journal /dev/sda1

2）对sda1进行fsck

# e2fsck -yf /dev/sda1

3）将sda1从ext2转换为ext3,重建日志

# tune2fs -j /dev/sda1

完成后，重启系统，根分区恢复正常。

※ 以上内容来自赵超 zhaochao#redflag-linux.com
Tags: ext3
mkfs -t ext3 错误/dev/sdxx is apparently in use by the system; 解决方法
技术联盟
01-24 6519
在存储上共享了一个500G的空间，映射到Linux系统提供上，环境由2个节点组成。 一． 测试一： 直接mount用fdisk 格式化之后如下：[root@rac1 u01]# fdisk -l……Disk /dev/sdk: 536.8 GB, 536870912000 bytes255 heads, 63 sectors/track, 65270cylindersUnits = cylin
vmware: vmkerrcode -l
mzhan017的博客
12-30 2048
vmware的error代码的简单描述。其实还是不知道具体发生了什么？
当文件系统变因为Detected aborted journal时filesystem read-only的解决方法
iteye_16035的博客
07-26 1675
真麻烦,一个机器有4个7T的存储中有二个存储有问题，用fsck修复了三次，都没有反应。使用使用着就提示下面的出错 #dmesg EXT3-fs error (device sdh1): ext3_journal_start_sb: Detected aborted journalRemounting filesystem read-onlyEXT3-fs error (device sdh1)...
解决挂载盘柜出现“EXT3-fs error filesystem read-only”
Fangrn的专栏
03-02 1553
昨天发现盘柜上的逻辑卷只能读，不能写！，查看盘柜管理页面，无错误提示，盘柜上面的硬盘指示灯也是正常的，查看前端的挂载机器的系统日志信息/var/log/messages，错误信息如下： EXT3-fs error (device sdc1): ext3_journal_start_sb: Detected aborted journal Remounting filesystem read-o...
【已解决】硬盘文件系统检查和修复
Sensorymagicia的博客
01-26 1167
fsck默认针对ext2文件系统。比如硬盘为ext4文件系统，使用fsck.ext4。检查：sudo dumpe2fs -h <需要检查的分区，如/dev/sdb1>文件系统错误可能的表现：硬盘变为只读；应用程序->磁盘（或者叫“磁盘管理”）->找到出问题的硬盘->再次检查：sudo dumpe2fs -h /dev/sdb1。检查文件系统结束后，点击齿轮状图标，选择“修复文件系统”修复：sudo fsck.ext4 /dev/sdb1。修复完毕后问题解决；，点击齿轮状图标，选择“检查文件系统”
SuperBlock损坏修复
swrd
02-19 3393
什么是superblock？ 可以参考下这个网站：http://homepage.smc.edu/morgan_david/cs40/analyze-ext2.htm 详细的介绍superblock组成 构成   大家可能遇到过这样的情况： [root@dhcp-0-142 ~]# mount /dev/sdb1 /mnt/sdb1 mount: wrong f
解决 make_ext4fs is not find, it is recommanded to install android-tools-fsutils
duapple的博客
06-05 1526
编译cluster linux时，遇到make_ext4fs命令无法找到。这个工具是被软件包 android-tools-futils 包含的。这个软件包只支持18.04的系统，在ubuntu20.04和ubuntu22.04上，无法被正确的安装。会报依赖问题，报错的信息是依赖python相关的，但是又没有指定一个版本。这个命令是被构建系统依赖的，因此没办法使用其它更新的版本。虽然可以直接安装deb包，但是每次使用apt install 时，都会报这个相关的错误。使用。
Lvm 折腾小记
CRPER
04-21 2380
LVM简述(引用百度百科):       LVM是逻辑盘卷管理（Logical Volume Manager）的简称，它是Linux环境下对磁盘分区进行管理的一种机制，LVM是建立在硬盘和分区之上的一个逻辑层，来提高磁盘分 LVM      LVM区管理的灵活性。前面谈到，LVM是在磁盘分区和文件系统之间添加的一个逻辑层，来为文件系统屏蔽下层磁盘分区布局，提供一个抽象的盘卷，在盘卷上建立文件
Spring Boot入门教程(四):配置文件
人不风流枉少年
03-20 4704
配置方式 每个starter都有自己默认的配置，如果需要改变默认值，可以在其他地方配置来覆盖掉默认的值，覆盖默认的配置有多种方式，每种方式的优先级也不同，如果在多个地方配置则优先使用优先级高的值，其中命令行参数优先级最高, 其中大部分参数一般都配置在属性文件application.properties中，属性文件即可以覆盖starter中默认的值，也可以自定义值 在命令行行输入的参数 SPR...
Aborted journal and volume remounted read-only
宁静致远
08-14 714
Aborted journal and volume remounted read-only
ext3文件系统超级块损坏修复
liushi558
08-10 3088
ext3文件系统超级块损坏修复2013-05-28 10:58:04 分类： LINUX 超级块：从磁盘上读出来的第一块信息就是超级块(superblock),它记录了磁盘的几何尺寸，可用空间容量最重要的是记录了第一个inode位置，就是"/ "，ext2/3文件存取都是通过inode定位的，比如使用/home/blue/test这个文件，首先先找到/的inode,然后找到
文件系统挂载选项journal
程序猿Ricky的日常干货
08-19 4891
什么是journal日志 作为日志文件系统，ext4使用journal来对文件系统操作进行记录，它和文件系统数据是分开进行管理的，当我们写入文件系统时，会先把最新的数据保存在journal区域中，然后再写入到真正文件系统中，当多次写入时会不停的更新journal中的数据内容，以保持最新的写入数据。这样做保证了文件系统的可靠性，并且当文件系统出现问题时，利于分析问题。 journal block的创...
挂载硬盘报错无法挂载、分区只读的解决方法
weixin_34090562的博客
06-06 1851
执行 dumpe2fs /dev/sda5 -h | head 查看文件系统状态。（dumpe2fs命令用于打印“ext2/ext3”文件系统的超级块和块组信息。） dumpe2fs 1.39 (29-May-2006)Filesystem volume name: /dataLast mounted on: <not available>Filesyste...
linux损坏硬件,linux – ext4文件系统损坏 – 可能是硬件错误？
weixin_42647395的博客
05-13 2004
我打开电脑约半小时后,我在dmesg中收到这些错误：[ 1355.677957] EXT4-fs error (device sda2): htree_dirblock_to_tree: inode #1318420: (comm updatedb.mlocat) bad entry in directory: directory entry across blocks - block=52517...
遇到的问题集
时间(实践)是检验真理的唯一标准
01-11 4356
问题1:streaming提交任务产生了堆积 原因 消费偏移量产生了大量的堆积查看sparkUI界面可以得知 由于偏移量由服务端掌握,所以2天堆积的数据达到了5000万条spark任务处理不过来 对策:重置消费偏移量,增大运行存储(需要增加的特别大,因为堆积的数据量太多,需要想办法处理) spark.streaming.unpersist()设置为true，可以自动回收 ...
docker容器根目录为只读的解决办法
weixin_34390996的博客
01-13 5257
问题描述 今天在启动docker容器的时候发现一段时间后宿主机上所有的容器的根目录全部变成了只读，并且宿主机message日志报磁盘相关的错 容器内mount结果如下 [root@zk-1 ~]# mount /dev/mapper/docker-253:0-4298664622-7830c39693a73c13e80cf2a22a465...
理论：深入理解Linux文件系统与日志分析
Lfwthotpt的博客
11-16 716
前言： inode（文件节点）与block（数据块） 硬链接与软连接 恢复误删除的文件 （即rm-rf 的操作，可以先进行备份的操作，然后可以进行恢复ext4和xfs文件系统皆可） 日志文件的分类 用户日志与程序日志 文章目录前言：一 ：inode和block概述1.1 概述1.2 inode的内容1.3 文件存储小结1.4 inode的大小1.5 inode的特殊作用1.6 链接文件二、文件...
[11:27:24:071] [ 6.037791][T1300001] init: init 5: [libfs_mgr] [chengqian_fs_mgr_do_mount_one] Mounting /metadata from /dev/block/by-name/metadata␍␊ [11:27:24:073] [ 6.038112][T1300001] init: init 5: [libfs_mgr] [chengqian_prepare_fs_for_mount] Preparing mount: blk_device=/dev/block/by-name/metadata, mount_point=/metadata, fs_type=ext4␍␊ [11:27:24:138] [ 6.083160][T1100001] init: init 6: [libfs_mgr] superblock s_max_mnt_count:65535,/dev/block/by-name/metadata␍␊ [11:27:24:140] [ 6.089918][T1100001] init: init 5: [libfs_mgr] [chengqian_prepare_fs_for_mount] Read ext4 superblock successfully␍␊ [11:27:24:144] [ 6.094671][T1100001] init: init 5: [libfs_mgr] [chengqian_prepare_fs_for_mount] Device size=33554432 bytes, block_size=4096, device_block_count=8192␍␊ [11:27:24:146] [ 6.100414][T1100001] init: init 5: [libfs_mgr] Filesystem on /dev/block/by-name/metadata was not cleanly shutdown; state flags: 0x1, incompat feature flags: 0x46␍␊--正常开机没有这个log [11:27:24:153] [ 6.110464][T1100001] init: init 5: [libfs_mgr] [chengqian_prepare_fs_for_mount] Filesystem unclean shutdown detected, flags: 1␍␊--正常开机没有这个log [11:27:24:155] [ 6.113342][T1100001] init: init 5: [libfs_mgr] [chengqian_prepare_fs_for_mount] Running fsck on /dev/block/by-name/metadata␍␊--正常开机没有这个log [11:27:24:157] [ 6.116445][T1100001] init: EXT4-fs: Ignoring removed nomblk_io_submit option␍␊ [11:27:24:163] [ 6.130915][T1000001] init: EXT4-fs (mmcblk0p9): recovery complete␍␊ [11:27:24:163] [ 6.133074][T1000001] init: EXT4-fs (mmcblk0p9): mounted filesystem 9094c4c6-c49b-41dd-82d9-24bdf6ae5fcd r/w with ordered data mode. Quota mode: none.␍␊ [11:27:24:167] [ 6.135344][T1000001] init: init 5: [libfs_mgr] check_fs(): mount(/dev/block/by-name/metadata,/metadata,ext4)=0: Success␍␊ [11:27:24:169] [ 6.137425][T1100001] init: EXT4-fs (mmcblk0p9): unmounting filesystem 9094c4c6-c49b-41dd-82d9-24bdf6ae5fcd.␍␊ [11:27:24:173] [ 6.141556][T1000001] init: init 5: [libfs_mgr] umount_retry(
最新发布
03-08
<think>嗯，用户问的是为什么Android设备在启动时会出现EXT4文件系统未干净关闭的日志，而正常开机时没有。首先，我需要回忆一下EXT4文件系统的特性。EXT4作为日志式文件系统，会在系统异常关机或崩溃时记录日志，以便在下次启动时进行恢复。那正常关机的话，系统应该会正确卸载文件系统，所以不会有这样的日志。 接下来，用户提到的是启动时出现这些日志，而正常开机没有。可能的原因包括异常断电、系统崩溃、或者强制重启。比如用户可能在关机时直接拔掉电池或者长按电源键，导致文件系统没有正确卸载。还有可能是硬件问题，比如电源管理模块故障，导致突然断电。软件方面，可能有内核崩溃或守护进程无法正常结束，导致系统无法完成关机流程。 另外，Android设备在启动过程中会检查文件系统状态，如果检测到上次是异常关机，就会触发fsck进行修复，这时候就会记录unclean shutdown的日志。正常开机的话，因为文件系统是干净关闭的，所以不会有这个检查。 然后，解决方法方面，首先要确保正常关机流程，比如避免强制重启。其次，检查硬件问题，尤其是电源相关的部件。还有调整文件系统的挂载选项，比如使用auto_da_alloc来减少数据损坏风险，或者增加日志提交频率。如果问题持续，可能需要深入分析内核日志或者进行硬件诊断。 用户提供的引用中提到了存储空间保护和FUSE文件系统，可能和SD卡保护机制有关，比如在空间不足时系统异常处理可能导致关机问题。需要检查这些保护机制是否影响了正常关机流程，或者在空间满的情况下导致文件系统无法正确卸载。此外，wifi启动过程中的问题可能间接影响系统稳定性，但具体关联需要进一步分析日志。 最后，用户可能需要具体的排查步骤，比如如何查看内核日志，如何调整挂载选项，以及如何测试硬件稳定性。可能需要指导用户使用dmesg或logcat来捕获启动日志，检查是否有相关的错误信息，或者建议进行硬件诊断测试。</think>### 分析Android设备EXT4文件系统未干净关闭的原因及解决方法 #### 1. **根本原因分析** EXT4文件系统通过日志（Journaling）机制保证数据一致性。当系统异常断电或强制重启时，文件系统未完成日志提交和元数据同步，会触发以下现象： - 设备启动时内核检测到文件系统状态标记为"unclean"，触发自动修复（通过`e2fsck`工具），并打印日志如： ``` EXT4-fs (mmcblk0p1): recovery complete EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts: (null) ``` [^2] - 正常开机时系统会执行正常卸载流程，更新超级块中的`clean`标记，因此不会出现该日志。 #### 2. **具体触发场景** | 场景类型 | 典型表现 | |----------------|--------------------------------------------------------------------------| | **硬件问题** | 突然断电、电池接触不良、电源管理芯片故障 | | **软件问题** | 内核崩溃（Oops/Panic）、关键守护进程（如vold）异常退出、强制重启操作 | | **存储保护** | SD卡保护机制触发异常卸载（如存储空间满导致卸载失败） | #### 3. **排查与解决方法** **步骤1：定位问题分区** ```shell # 查看内核日志 dmesg | grep "EXT4-fs.*unclean" # 示例输出：EXT4-fs (mmcblk0p28): VFS: Found ext4 filesystem with errors ``` **步骤2：分析关机流程** - 检查最后一次关机状态： ```shell cat /proc/last_kmsg | grep "Power down" ``` - 验证正常关机流程是否完整（如`system_server`的`shutdown`广播是否完成） **步骤3：硬件诊断** - 使用`mmc-utils`检测eMMC健康状态： ```shell mmc extcsd read /dev/mmcblk0 ``` - 检查电源管理芯片输出电压稳定性 **步骤4：文件系统加固** ```xml <!-- 修改fstab文件系统挂载选项 --> /dev/block/mmcblk0p28 /data ext4 noatime,nosuid,nodev,auto_da_alloc,errors=panic 0 0 ``` *注：`auto_da_alloc`选项可在异常断电时增强数据一致性[^1]* #### 4. **进阶优化方案** - **日志模式调整**：将默认的`ordered`模式改为`journal`模式（全日志记录） ```shell tune2fs -O has_journal /dev/mmcblk0p28 ``` - **增加日志提交频率**： ```shell echo 50 > /proc/sys/vm/dirty_expire_centisecs ``` #### 5. **特殊场景处理** 对于采用FUSE实现的SD卡存储方案[^1]，需额外检查： ```python # 检查FUSE守护进程状态 if ps | grep sdcard; then echo "FUSE daemon running" else echo "FUSE daemon crashed" fi ```
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值