Possible bug in mkfs.ext3
jd1008 at gmail.com
Sat Sep 20 01:56:37 UTC 2014
I am reporting this on the advice of the Fedora Users Mailing List Member.
This the mailing list exchange outlining the problem with specifying -S
and it's subsequent consequences when fsck is run.
I am reporting this per suggestions made to me on the Fedora Users
The following is the mailing list exchange:
On 09/18/2014 07:01 PM, Robert Nichols wrote:
> On 09/18/2014 12:37 PM, jd1008 wrote:
>> Is there any other tool that can extract files from a partition that
>> seems to have corrupted superblocks?
>> I tried dumpe2fs, and fsck -b <blockNumber>
>> to no avail. Tried all available block numbers that are listed
>> when original mkfs was done, and it's output was saved.
>> None of the blocks seem to work - all of them have invalid magic.
> Verify that the partition table still appears to be correct. If it
> is pointing to the wrong starting location, none of the super blocks
> will appear in the expected places. You might see if /testdisk/can
> find any intact super blocks.
> Consider using a hex editor to look at some of the super blocks.
> They should contain the same data. The data that actually appears
> there might give some clue as to what happened.
> As a last ditch recovery effort, run mke2fs/mke3fs with the "-S"
> option to initialize the super blocks and group descriptors only.
> Do this only with (or on) a backup copy of the partition, since
> it is potentially destructive. Then see if /debugfs/can make
> sense of the filesystem, and if so, run /fsck/with the "-f"
> option to repair the metadata.
On 09/19/2014 07:16 PM, Chris Murphy wrote:
> On Sep 19, 2014, at 11:49 AM, jd1008 <jd1008 at gmail.com> wrote:
>> On 09/19/2014 08:39 AM, Robert Nichols wrote:
>>> On 09/18/2014 10:57 PM, jd1008 wrote:
>>>> I ran mkfs.ext3 -S /dev/sdc7
>>>> then ran fsck.ext3 -y /dev/sdc7
>>>> it blew away EVERYTHING :)
>>>> Back to square one and re-dd original to test drive
>>>> and start over.
>>> Ouch! That _used_ to work. Trying it just now, "mke3fs -S" seems
>>> to clear a substantial portion of the inodes, which the manpage
>>> specifically says it should _not_ do, and then /fsck/ completes the
>>> destruction by moving all of the remaining inodes to lost+found.
>>> Sorry about that.
>> Can raise a bug against it?
> Chances are this is an upstream bug, or a misunderstanding. You should post your reproduce steps to the ext4 list, what you expect to happen based on man page, and what actually happens.
> Chris Murphy
More information about the Ext3-users