Re: dm-crypt over raid6 unreadable after crash

[Stan Hoeppner <stan@hardwarefreak.com>]

On 7/10/2011 7:28 AM, Phil Turmel wrote:
> On 07/10/2011 08:03 AM, Louis-David Mitterrand wrote:
>> On Fri, Jul 08, 2011 at 07:40:45AM +0200, Luca Berra wrote:
>>>> This is important.  When I computed the sector count for the linear mapping, I just took 2048 off the end.  You may want to select a sector count that aligns the endpoint.
>>> but the xfs sb should be at sector 0
>>
>> So what should I change to the dmsetup command to make it work?
> 
> He means (not to put words in Luca's mouth...) that the precise endpoint of the mapped volume shouldn't matter to fsck.xfs.  Changing device order in the raid is probably your only hope of recovery.  The dmsetup exercise was a blind alley.
> 
> Luca also pointed out that the problem array is named "grml" which means that it was created with grml, not your original system (zenon).  That suggests that "mdadm --create" was used under grml, and the member devices were specified in an order differing from the original install.  If that "mdadm --create" didn't include the "--assume-clean" option, then the parity blocks are almost certainly recomputed, and your data destroyed.  Otherwise, you can try "mdadm --create --assume-clean" with other combinations of device order to try to find the "right" one.
> 
> I recommend trying "mdadm --create --assume-clean" with the devices in the same order as shown by lsdrv for the zenon array.

Moral of this story:  Using live CDs to troubleshoot Linux RAID arrays,
LVM volumes, dmcrypt, etc, is tricky at best, fraught with disaster at
worst.  Always have a "system rescue" CD/DVD built from the particular
machine in question at the ready.  Most distros have a facility for
building such a per machine boot/rescue CD.  Such media will have the
same kernel and module versions, the system's mdadm configuration, and
all other system specific stuff needed to properly troubleshoot and repair.

If such rescue media had been used the OP would have likely experienced
far less grief, and might already had this problem fixed.

-- 
Stan