fixing a corrupt /dev/hdar .. debugfs assistance...

[Chris Worley]

Thanks for the clarification, I obviously didn't read the man page as
thoroughly as I should have.

I was able to zero-out the 2nd inode (but, I could not dump it to a
file... the resulting file was 0 bytes), and e2fsck got beyond that
point, but is no segfaulting in the 4th pass.

The disk I'm DD'ing to is firewire/USB, so I can move it to different
systems pretty easily.  The USB/Firewire disk has more blocks than the
MD1 device I'm trying to resurrect: I couldn't create a partition of
the exact same size, so I just use the whole device (so there will be
trailing garbage at the end of the device/partition that's not part of
the file system).

On one system, fsck segfaults after the 4th pass, on another system,
it nicely reports the segfault and exits:

   Warning... fsck.ext2 for device /dev/sdc exited with signal 11.
fsck.ext2 /dev/sdc failed (status 0x8). Run manually!

The last message before the segfault, on either the faulty md1 or the
backup system is:

i_fsize for inode 7663554 (...) is 150, should be zero.
Clear<y>? yes

Why always the same errors?  Doesn't e2fsck commit the change when you
respond "Y"?

The same event occurs if I use a different superblock.

Note that in using dd or dd_rescue, there are no errors reading from
the bad disk device (md1).

Off topic: It's also strange that my system w/ a 2.6.11 kernel won't
mount or fsck the USB/Firewire drive, even after making a file system
from scratch.


On 3/21/06, Theodore Ts'o wrote:
> On Tue, Mar 21, 2006 at 01:51:20PM -0700, Chris Worley wrote:
> > Thanks for the help.
> >
> > Does <2> refer to a superblock?
>
> No, <2> refers to inode #2.  See the debugfs man page:
>
> SPECIFYING FILES
>       Many debugfs commands take a filespec as  an  argument  to  specify  an
>       inode  (as  opposed to a pathname) in the filesystem which is currently
>       opened by debugfs.  The filespec  argument  may  be  specified  in  two
>       forms.  The first form is an inode number surrounded by angle brackets,
>       e.g., <2>.  The second form is a pathname; if the pathname is  prefixed
>       by  a  forward slash ('/'), then it is interpreted relative to the root
>       of the filesystem which is currently opened by debugfs.   If  not,  the
>       pathname  is  interpreted  relative to the current working directory as
>       maintained by debugfs.  This may be modified by using the debugfs  com-
>       mand cd.
>
>                                                - Ted
>