linux-ext4 - Re: corrupt filesystem, superblock/journal

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e2338865-fe27-5b06-4342-d357c47f1d5c@uls.co.za>
Date:   Wed, 23 May 2018 15:16:07 +0200
From:   Jaco Kroon <jaco@....co.za>
To:     Jan Kara <jack@...e.cz>
Cc:     linux-ext4 <linux-ext4@...r.kernel.org>,
        Pieter Kruger <pieter@....co.za>
Subject: Re: corrupt filesystem, superblock/journal - fsck

Hi Jan,

On 23/05/2018 13:37, Jan Kara wrote:
> Hi,
> OK, so the Inode count is obviously wrong and the remaining errors are due
> to that. Apparently the resize process has overflown the inode count to 0
> (which is not that surprising since the number of inodes in your filesystem
> would be 1<<32) - that needs fixing but let's first get your fs up and
> running. I'm actually surprised that e2fsck did anything with the
> filesystem because for me both 1.44.2 and 1.42.11 versions just exit after
> printing the error about the corrupted superblock. Anyway what *could* fix
> your problem is:
>
> debugfs -w -R 'ssv inodes_count 4294967295' /dev/lvm/home
>
> and then check with dumpe2fs that inode count indeed got fixed. Hope it
> helps.
I started to investigate the superblocks as well.  Using hexdump and dd
... scary.  Came to the same conclusion, tried to fix it by replacing it
in the superblock using dd but that caused other issues so reverted it
back to all zero.

Also tried with debugfs but could not figure out how to use it so the
above helped a lot thank you so much!  Unfortunately it doesn't help:

crowsnest ~ # dumpe2fs /dev/lvm/home
dumpe2fs 1.44.2 (14-May-2018)
dumpe2fs: The ext2 superblock is corrupt while trying to open /dev/lvm/home
Couldn't find valid filesystem superblock.

fsck and debugfs also now fails, managed to revert that using:

crowsnest ~ # echo -ne "\x00\x00\x00\x00" | dd of=/dev/lvm/home bs=4
count=1 seek=256 conv=notrunc
1+0 records in
1+0 records out
4 bytes copied, 0.0213468 s, 0.2 kB/s

And now we're back to where we started.  So I'm contemplating if 2^32-1
is not perhaps an explicitly invalid value, but I've tried 2^32-2
(4294967294) as well, same result.

 Busy trying to check the e2fsck source files.  There are quite a few
things that can go wrong during ext2fs_open2() and it's unclear what
exactly is going wrong here.  Looks like I may have to modify the code
to get the error value ...

Since it happened during (directly after?) resize2fs we are actually
thinking potential kernel bug.  Original FS size was 61TB and upsized to
exactly 64TB.  In terms of 4096KB blocks that's EXACTLY 2^34 blocks, so
I also aim to look at the kernel sources there, but as you say - first
we need to get the filesystem up.

Kind Regards,
Jaco