curious corruption 2-byte shift of all data

Stephen Samuel darkonc at gmail.com
Mon Dec 22 04:18:59 UTC 2008


It may be that only *part* of the filesystem has been shigted by 2 bytes.
Look through the partition and see if you can find blocks that look kike
proper files/signatures.

If that's a case later on in the filesystem, then do a binary search to see
if you can figure out where the boundry is between the shifted and unshifted
parts.


On Wed, Dec 17, 2008 at 2:28 PM, Paul Raines <raines at nmr.mgh.harvard.edu>wrote:

> On Wed, 17 Dec 2008, Jon Burgess wrote:
>
>  On Wed, 2008-12-17 at 15:35 -0500, Paul Raines wrote:
>>
>>> Any
>>> fancy Linux device tricks I can do to make /dev/sdc1 shift everything
>>> by two bytes?
>>>
>>
>> losetup -o 2
>>
>> e.g.
>>
>> [root at shark ~]# od -t x1 /dev/sda | head -n 1
>> 0000000 eb 48 90 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0
>> [root at shark ~]# losetup -o 2 /dev/loop0 /dev/sda
>> [root at shark ~]# od -t x1 /dev/loop0 | head -n 1
>> 0000000 90 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0 fb be
>>
>>        Jon
>>
>
>
> Perfect! THanks.
>
> Unfortunately it appears the filesystem is toast though and it was
> not as simple as everything being shifted by 2 bytes.  So I will
> chalk it up as a loss.
>
>
>
> [root at shadowfax ~]# losetup -o 2 /dev/loop7 /dev/sdc1
> [root at shadowfax ~]# dumpe2fs -h /dev/loop7
> dumpe2fs 1.39 (29-May-2006)
> Filesystem volume name:   ASALAZAR_USB1
> Last mounted on:          <not available>
> Filesystem UUID:          549ade87-064b-46e8-8280-10c8a6f474b4
> Filesystem magic number:  0xEF53
> Filesystem revision #:    1 (dynamic)
> Filesystem features:      resize_inode filetype sparse_super large_file
> Default mount options:    (none)
> Filesystem state:         not clean with errors
> Errors behavior:          Continue
> Filesystem OS type:       Linux
> Inode count:              61063168
> Block count:              122096000
> Reserved block count:     6104800
> Free blocks:              46076684
> Free inodes:              60915913
> First block:              0
> Block size:               4096
> Fragment size:            4096
> Reserved GDT blocks:      994
> Blocks per group:         32768
> Fragments per group:      32768
> Inodes per group:         16384
> Inode blocks per group:   512
> Filesystem created:       Thu Jun 26 13:03:39 2008
> Last mount time:          Tue Dec 16 15:31:21 2008
> Last write time:          Tue Dec 16 19:28:13 2008
> Mount count:              35
> Maximum mount count:      38
> Last checked:             Thu Jun 26 13:03:39 2008
> Check interval:           15552000 (6 months)
> Next check after:         Tue Dec 23 12:03:39 2008
> Reserved blocks uid:      0 (user root)
> Reserved blocks gid:      0 (group root)
> First inode:              11
> Inode size:               128
> Default directory hash:   tea
> Directory Hash Seed:      e41ec746-def1-4d33-9a44-8aff8caef73b
> ext2fs_read_bb_inode: A block group is missing an inode table
> [root at shadowfax ~]# e2fsck -f -n /dev/loop7
> e2fsck 1.39 (29-May-2006)
> Group descriptors look bad... trying backup blocks...
> e2fsck: Bad magic number in super-block while trying to open /dev/loop7
>
> The superblock could not be read or does not describe a correct ext2
> filesystem.  If the device is valid and it really contains an ext2
> filesystem (and not swap or ufs or something else), then the superblock
> is corrupt, and you might try running e2fsck with an alternate superblock:
>    e2fsck -b 8193 <device>
>
>
> _______________________________________________
> Ext3-users mailing list
> Ext3-users at redhat.com
> https://www.redhat.com/mailman/listinfo/ext3-users
>



-- 
Stephen Samuel http://www.bcgreen.com
778-861-7641
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/ext3-users/attachments/20081221/6cb79b90/attachment.htm>


More information about the Ext3-users mailing list