Score:2

Can't repair ext4 partition after power outage, e2fsck keeps crashing, can't find out what is wrong?

ar flag

After power outage, Ubuntu couldn't repair ext4 and throws the same error as below with e2fsck:

So I use the latest SystemRescue LiveCd and try to manually do fsck.

e2fsck /dev/sda2 :

/dev/sda2: recovering journal
Signal (11) SIGSEGV si_code=SEGV_MAPERR fault addr=0x561377ff7000
e2fsck: malloc.c:2539: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed.
Signal (6) SIGABRT si_code=SI_TKILL 

tune2fs -l /dev/sda2 :

tune2fs 1.46.4 (18-Aug-2021)
Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          787f0a6f-7d49-409d-80b7-5e4416d5a2bb
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index fast_commit filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean with errors
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              30236672
Block count:              120925696
Reserved block count:     6046284
Free blocks:              16403757
Free inodes:              29241790
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      995
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Mon Apr  2 12:16:18 2018
Last mount time:          Mon Nov  8 10:55:03 2021
Last write time:          Mon Nov  8 14:02:43 2021
Mount count:              2
Maximum mount count:      -1
Last checked:             Mon Nov  8 10:51:38 2021
Check interval:           0 (<none>)
Lifetime writes:          13 TB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
First orphan inode:       27918882
Default directory hash:   half_md4
Directory Hash Seed:      efb4ad95-8a43-42bc-a03b-0849ccae2ef7
Journal backup:           inode blocks

mount /dev/sda2 /mnt :

mount: /mnt: can't read superblock on /dev/sda2.

mke2fs -n /dev/sda2 :

mke2fs 1.46.4 (18-Aug-2021)
/dev/sda2 contains a ext4 file system
    last mounted on / on Mon Nov  8 10:55:03 2021
Proceed anyway? (y,N) y
Creating filesystem with 120925696 4k blocks and 30236672 inodes
Filesystem UUID: 331dfa9a-1bae-44bf-b4a2-4c75d7a8aab2
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
    102400000

e2fsck -b 32768 /dev/sda2 :

e2fsck 1.46.4 (18-Aug-2021)
Superblock needs_recovery flag is clear, but journal has data.
Recovery flag not set in backup superblock, so running journal anyway.
/dev/sda2: recovering journal
Signal (11) SIGSEGV si_code=SEGV_MAPERR fault addr=0x55657e320000
e2fsck(+0x35133)[0x55657d929133]
/usr/lib/libpthread.so.0(+0x13870)[0x7fb669365870]
e2fsck(+0x27c10)[0x55657d91bc10]
e2fsck(+0x28480)[0x55657d91c480]
e2fsck(+0x309c4)[0x55657d9249c4]
e2fsck(jbd2_journal_recover+0xd7)[0x55657d9251a7]
e2fsck(e2fsck_run_ext3_journal+0x2d1)[0x55657d91e871]
e2fsck(main+0x1d75)[0x55657d903de5]
/usr/lib/libc.so.6(__libc_start_main+0xd5)[0x7fb6691adb25]
e2fsck(_start+0x2e)[0x55657d90591e]

e2fsck -b 98304 /dev/sda2:

e2fsck 1.46.4 (18-Aug-2021)
Superblock needs_recovery flag is clear, but journal has data.
Recovery flag not set in backup superblock, so running journal anyway.
/dev/sda2: recovering journal
Signal (11) SIGSEGV si_code=SEGV_MAPERR fault addr=0x563839a50000
e2fsck(+0x35133)[0x563838e06133]
/usr/lib/libpthread.so.0(+0x13870)[0x7f671f521870]
e2fsck(+0x27c10)[0x563838df8c10]
e2fsck(+0x28480)[0x563838df9480]
e2fsck(+0x309c4)[0x563838e019c4]
e2fsck(jbd2_journal_recover+0xd7)[0x563838e021a7]
e2fsck(e2fsck_run_ext3_journal+0x2d1)[0x563838dfb871]
e2fsck(main+0x1d75)[0x563838de0de5]
/usr/lib/libc.so.6(__libc_start_main+0xd5)[0x7f671f369b25]
e2fsck(_start+0x2e)[0x563838de291e]

e2fsck -C0 -p -f -v /dev/sda2 :

/dev/sda2: recovering journal
Signal (11) SIGSEGV si_code=SEGV_MAPERR fault addr=0x555ae23f5000
e2fsck(+0x35133)[0x555ae03cd133]
/usr/lib/libpthread.so.0(+0x13870)[0x7efe927b8870]
e2fsck(+0x27c10)[0x555ae03bfc10]
e2fsck(+0x28480)[0x555ae03c0480]
e2fsck(+0x309c4)[0x555ae03c89c4]
e2fsck(jbd2_journal_recover+0xd7)[0x555ae03c91a7]
e2fsck(e2fsck_run_ext3_journal+0x2d1)[0x555ae03c2871]
e2fsck(main+0x1d75)[0x555ae03a7de5]
/usr/lib/libc.so.6(__libc_start_main+0xd5)[0x7efe92600b25]
e2fsck(_start+0x2e)[0x555ae03a991e]

smartctl -H /dev/sda2:

smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.10.70-1-lts] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
sudodus avatar
jp flag
Are there important unique data on the drive, that you must recover? Or would you be happy, if you can blank the partition table, create a new one, create partitions and file systems and restore data from backup?
ar flag
Yes, I have some important data. But I'm just interested, what is wrong and why fsck/e2fsck keeps crashing.
sudodus avatar
jp flag
I can't tell what's wrong, but there are tools from https://cgsecurity.org, that might work, when fsck/e2fsck keeps crashing. If very important data, clone the whole drive to another drive of at least the same size and do recovery work on the cloned copy. Try first `testdisk`, and if it does not work, `photorec`, that can recover data without any file system, as long as the file data is still there. But it is a lot of work, and file names and directory strucure are lost..
ar flag
Files seems "intact" on partition, using testdisk, so maybe I try to copy from there.
sudodus avatar
jp flag
Let us know the result. Good luck :-)
Score:1
ar flag

I created an issue on github, and some nice guy (harshadjs) helped me to fix this issue, writing patch for the app. It looks like, it was something wrong with e2fsprogs and fast_commit feature in ext4. One can track it here.

Bottom line is, don't mess with filesystem features, when your power supply is unstable and you don't know how to fix it on your own.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.