linux-ext4 - Re: Recovering from a damaged root inode

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] [day] [month] [year] [list]

Message-ID: <CAPE0SYw+5OLTVG-tq4rGgEh_2HRkANNsP4mqZF_UOK_76HEfAQ@mail.gmail.com>
Date:	Fri, 29 Aug 2014 06:53:24 +0800
From:	Liwei <xieliwei@...il.com>
To:	"Theodore Ts'o" <tytso@....edu>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: Recovering from a damaged root inode

On 29 August 2014 01:19, Liwei <xieliwei@...il.com> wrote:
> Hi Ted,
>     Thanks for the response! Responses in-line.
>
====SNIP====
>> Finally, this error is one was caused by your using fsck -n:
>>
>>> Illegal triple indirect block (3637063325) in inode 1065.  IGNORED.
>>> Error while iterating over blocks in inode 1065: Illegal triply
>>> indirect block found
>>
>> There was an illegal indirect bock in inode 1065, which wasn't fixed
>> because of e2fsck -n.  Unfortunately, this caused the scan to get
>> aborted, because the unfixed error caused the inode iterator to fail.
>> We could try to fix things up to make e2fsck -n recover more cleanly
>> in the face of errors caused by not fixing previously found errors,
>> but that hasn't been something that's been high priority.  (If someone
>> would like to improve e2fsck in this regard, please send patches.)
>
====SNIP====
>> More generally, it looks like part of your inode table got smashed.
>
> That sounds bad. From my limited understanding of ext4's structure,
> each block group has its own inode table, right? Or is the inode table
> global? What are my chances of recovering from this?
>

I decided to make a snapshot and tried running fsck.ext4 -y.

Currently, this just flew by my screen:
Inode 117911, i_size is 10327091671466843186, should be 0.  Fix? yes

Inode 117911, i_blocks is 123836699223379, should be 0.  Fix? yes

Inode 117841 has a bad extended attribute block 3239803245.  Clear? yes

Inode 117841 has illegal block(s).  Clear? yes

Every single inode before that was erroneous. That means they're data
somehow mistaken as inodes, aren't they?

Liwei
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html