2

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
5
  • 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?
    – sudodus
    Nov 8, 2021 at 16:23
  • Yes, I have some important data. But I'm just interested, what is wrong and why fsck/e2fsck keeps crashing.
    – Andy Leu
    Nov 8, 2021 at 16:42
  • 1
    I can't tell what's wrong, but there are tools from 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..
    – sudodus
    Nov 8, 2021 at 16:51
  • 1
    Files seems "intact" on partition, using testdisk, so maybe I try to copy from there.
    – Andy Leu
    Nov 8, 2021 at 17:15
  • Let us know the result. Good luck :-)
    – sudodus
    Nov 8, 2021 at 18:26

1 Answer 1

1

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .