Re: Brocken Raid & LUKS

[Stone <stone@heisl.org>]

Am 21.02.2013 19:00, schrieb Phil Turmel:
> On 02/21/2013 12:47 PM, Stone wrote:
>> Am 21.02.2013 18:36, schrieb Phil Turmel:
>>> But it does give you the locations of the backup superblocks.  Use these
>>> numbers, starting with 32768, as "xxxx" in:
>>>
>>> fsck.ext4 -n -b xxxx /dev
>>>
>>> Once you give it a superblock that hasn't been corrupted, it should be
>>> able to check the rest of the filesystem.  There will be damage near the
>>> beginning, and probably more damage where you had to put zeros.
>>>
>>> If it looks like that, do it again without "-n" to actually fix it.
>>>
>>> Phil
>>>
>> ok. i think i dont understand you not complete.
>> i restore now the superblock with --> fsck.ext4 -bv 4096000
>> /dev/mapper/md2_nas
> No!  You must keep using "-n" until you have seen a mostly-clean report!
>   We don't know yet that the chunk size is right.
>
> Leaving off "-n" will simultaneously fix the superblock (and all other
> backup copies) and continue to fix the rest of the filesystem.  You
> mustn't do that with a wrong chunk size--it will damage much more.
ok
>> when this is done i make full filesystemcheck --> fsck.ext4 /dev/md2_nas
>> and answer the quest questions.
>> right?
> No.
>
> Just do the "fsck -n -b xxxx" combinations until you find a good
> superblock.  That report will also show if there are many other errors.
>   Expect scattered damage in the region < 384MB due to the wrong data
> offset.  After that, there should only be errors where the new zeros
> are, and maybe a few scattered errors from the original crash.  If there
> many more errors, you have the wrong chunk size.
>
> Phil
ok i have checked all superblocks but i get always the same message.
here one sample:
fsck.ext4 -n -b 644972544 /dev/mapper/md2_nas
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Invalid argument while trying to open /dev/mapper/md2_nas

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>