can't open luks device after raid 5 rebuild
Hi guys,
after my encrypted RAID 5 was degraded and rebuilt, I can't open it anymore.
cryptsetup luksOpen /dev/md127 archiv
Geben Sie den Passsatz für /dev/md127 ein:
Kein Schlüssel mit diesem Passsatz verfügbar.
It says that the provided password doesn't match any of the stored keys.
Here's the output of luksDump:
cryptsetup luksDump /dev/md127
LUKS header information for /dev/md127
Version: 1
Cipher name: aes
Cipher mode: xts-plain
Hash spec: sha1
Payload offset: 4040
MK bits: 512
MK digest: 53 24 e5 1d 68 3e f1 5f 96 56 06 23 85 4a b6 89 07 de 52 1d
MK salt: 5b 2e 4b 48 d8 2f 91 52 90 79 3b 6e 73 13 52 f1
8f 9e 35 50 8e 25 9e 92 22 52 48 26 44 d7 bd 6c
MK iterations: 10
UUID: 3fbd3c47-8dc3-4541-8960-00c0a80c8ae9Key Slot 0: ENABLED
Iterations: 363564
Salt: 32 db 41 40 56 fe 6f a9 c7 e4 c4 5f a0 4c 52 db
8e df 07 8c 9b 32 86 e6 ac 0c 8a e6 c4 69 31 0f
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
Can anyone help me?
Regards
artificial
Hi,
a RAID degradation and successful rebuild does not have this effect. Did you do something else? Or did you do a manual (forced) rebuild? What exactly did happen to the RAID and what did you do to fix it?
The symptoms you see are typical for a damaged key-slot. The header resides in a single sector and is not affected. If so, a header backup is possibly the only thing that will help you, see the FAQ for details.
Arno
Quoted 53 lines · On Sun, Apr 08, 2012 at 03:04:47PM +0200, artificial11000 wrote:
Hi guys,
after my encrypted RAID 5 was degraded and rebuilt, I can't open it anymore.
cryptsetup luksOpen
/dev/md127archiv
Geben Sie den Passsatz f?r/dev/md127ein:
Kein Schl?ssel mit diesem Passsatz verf?gbar.It says that the provided password doesn't match any of the stored keys.
Here's the output of luksDump:
cryptsetup luksDump
/dev/md127
LUKS header information for/dev/md127Version: 1 Cipher name: aes Cipher mode: xts-plain Hash spec: sha1 Payload offset: 4040 MK bits: 512 MK digest: 53 24 e5 1d 68 3e f1 5f 96 56 06 23 85 4a b6 89 07 de 52 1d MK salt: 5b 2e 4b 48 d8 2f 91 52 90 79 3b 6e 73 13 52 f1 8f 9e 35 50 8e 25 9e 92 22 52 48 26 44 d7 bd 6c MK iterations: 10 UUID: 3fbd3c47-8dc3-4541-8960-00c0a80c8ae9Key Slot 0: ENABLED
Iterations: 363564 Salt: 32 db 41 40 56 fe 6f a9 c7 e4 c4 5f a0 4c 52 db 8e df 07 8c 9b 32 86 e6 ac 0c 8a e6 c469 31 0f
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLEDCan anyone help me?
Regards
artificial
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Signature · 6 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision. -- Bertrand Russell
Hi,
as I noticed that I can't access the device, I recreated the raid manually.
mdadm --create --level=5 -n 3 /dev/md127 /dev/sdb /dev/sdc /dev/sdd
Could this damage the key-slot?
Are the metadata of the RAID relevant to this?
I read that old versions of mdadm created RAIDs with metadata=0.90 and the newer versions with metadata=1.20.
artificial
Quoted 69 lines · Arno Wagner
Hi,
a RAID degradation and successful rebuild does not have this effect. Did you do something else? Or did you do a manual (forced) rebuild? What exactly did happen to the RAID and what did you do to fix it?
The symptoms you see are typical for a damaged key-slot. The header resides in a single sector and is not affected. If so, a header backup is possibly the only thing that will help you, see the FAQ for details.
Arno
Quoted 53 lines · On Sun, Apr 08, 2012 at 03:04:47PM +0200, artificial11000 wrote:
Hi guys,
after my encrypted RAID 5 was degraded and rebuilt, I can't open it anymore.
cryptsetup luksOpen
/dev/md127archiv
Geben Sie den Passsatz f?r/dev/md127ein:
Kein Schl?ssel mit diesem Passsatz verf?gbar.It says that the provided password doesn't match any of the stored keys.
Here's the output of luksDump:
cryptsetup luksDump
/dev/md127
LUKS header information for/dev/md127Version: 1 Cipher name: aes Cipher mode: xts-plain Hash spec: sha1 Payload offset: 4040 MK bits: 512 MK digest: 53 24 e5 1d 68 3e f1 5f 96 56 06 23 85 4a b6 89 07 de 52 1d MK salt: 5b 2e 4b 48 d8 2f 91 52 90 79 3b 6e 73 13 52 f1 8f 9e 35 50 8e 25 9e 92 22 52 48 26 44 d7 bd 6c MK iterations: 10 UUID: 3fbd3c47-8dc3-4541-8960-00c0a80c8ae9Key Slot 0: ENABLED
Iterations: 363564 Salt: 32 db 41 40 56 fe 6f a9 c7 e4 c4 5f a0 4c 52 db 8e df 07 8c 9b 32 86 e6 ac 0c 8a e6 c469 31 0f
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLEDCan anyone help me?
Regards
artificial
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Hi Artificial,
Quoted 2 lines · On 04/08/12 18:23, artificial11000 wrote:
as I noticed that I can't access the device, I recreated the raid manually.
mdadm --create --level=5 -n 3/dev/md127/dev/sdb/dev/sdc/dev/sdd
You created a new raid that way.
Quoted 1 line
Could this damage the key-slot?
Yes and all the data on the drives too.
Quoted 82 lines
Are the metadata of the RAID relevant to this?
I read that old versions of mdadm created RAIDs with metadata=0.90 and the newer versions with metadata=1.20.artificial
Quoted 7 lines · Arno Wagner
Hi,
a RAID degradation and successful rebuild does not have this effect. Did you do something else? Or did you do a manual (forced) rebuild? What exactly did happen to the RAID and what did you do to fix it?
Quoted 64 lines
The symptoms you see are typical for a damaged key-slot. The header resides in a single sector and is not affected. If so, a header backup is possibly the only thing that will help you, see the FAQ for details.
Arno
Quoted 55 lines · On Sun, Apr 08, 2012 at 03:04:47PM +0200, artificial11000 wrote:
Hi guys,
after my encrypted RAID 5 was degraded and rebuilt, I can't open it anymore.
cryptsetup luksOpen
/dev/md127archiv
Geben Sie den Passsatz f?r/dev/md127ein:
Kein Schl?ssel mit diesem Passsatz verf?gbar.It says that the provided password doesn't match any of the stored keys.
Here's the output of luksDump:
cryptsetup luksDump
/dev/md127
LUKS header information for/dev/md127Version: 1 Cipher name: aes Cipher mode: xts-plain Hash spec: sha1 Payload offset: 4040 MK bits: 512 MK digest: 53 24 e5 1d 68 3e f1 5f 96 56 06 23 85 4a b6 89 07 de 52 1d MK salt: 5b 2e 4b 48 d8 2f 91 52 90 79 3b 6e 73 13 52 f1 8f 9e 35 50 8e 25 9e 92 22 52 48 26 44 d7 bd 6c MK iterations: 10 UUID: 3fbd3c47-8dc3-4541-8960-00c0a80c8ae9Key Slot 0: ENABLED
Iterations: 363564 Salt: 32 db 41 40 56 fe 6f a9 c7 e4 c4 5f a0 4c 52 db 8e df 07 8c 9b 32 86 e6 ac 0c 8a e6 c469 31 0f
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLEDCan anyone help me?
Regards
artificial
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Quoted 1 line · On 08.04.2012, artificial11000 wrote:
mdadm --create --level=5 -n 3
/dev/md127/dev/sdb/dev/sdc/dev/sdd
---------
Seems your data is gone, forever. You created a new raid manually, which means that you deleted all your previous data.
You have a backup, do you?
Quoted 8 lines · Heinz Diehl
Quoted 1 line · On 08.04.2012, artificial11000 wrote:
mdadm --create --level=5 -n 3
/dev/md127/dev/sdb/dev/sdc/dev/sdd---------
Seems your data is gone, forever. You created a new raid manually, which means that you deleted all your previous data.
Quoted 6 lines
You have a backup, do you?
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
I disagree. I got some missing superblock sometime in the past while assembling the array. Recreated it using mdadm -C with the same parameters for the raid-level and raid-devices and it did not touch my encrypted data. I was able to mount just fine after that. I always thought that mdadm would touch only their own superblock when creating. Though at that time i had a degraded array and my array is built on partitions , not the whole disk.
[]'s
Salatiel
Quoted 7 lines · Heinz Diehl
Quoted 1 line · On 08.04.2012, artificial11000 wrote:
mdadm --create --level=5 -n 3
/dev/md127/dev/sdb/dev/sdc/dev/sdd---------Seems your data is gone, forever. You created a new raid manually, which means that you deleted all your previous data.
Not quite. The LUKS header is still there, obviously. What happens when you create a RAID5 array out of components of another RAID5 array is the following: They get put into some order and, in a fashion rotating by stripe-size, one drive gets overwritten with the parity of the others. If everything, includiong the drive order is the same as in the original artray, everything will be fine.
Otherwise, if the stripe size is correct, you will not actually lose any data, as only one drive was overwritten per stripe and the original RAID5 data is tolerant against one device loss (or loss of one stripe per stripe-set). The array still assembles incorrectly and you will _not_ be able to re-create the original data without major effort. It should be possible though, but it involves figuring out the current and the old stripe order and then manually rebuilding the old array out of the old stripes still there. This is made trickier because the old RAID superblocks are also gone.
I think could do this, but I would expect several days of coding and I would need the password (otherwise it is impossible to verify correct stripe order and size) and complete drive images of all drives. (And, sorry, my rates are likely way above what the data is worth to you...) Some RAID recovery software may also be able to help, but as the data is encrypted, I doubt it, as with encrypted data, it is not possible to detect whether the assembly order is right. This would require a specialized LUKS-aware RAID recovery tool.
Quoted 1 line
You have a backup, do you?
That would be the next question. The proble is not (only) that you hosed the LUKS header, but the complete data area.
Arno
Signature · 6 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision. -- Bertrand Russell
Quoted 16 lines · Salatiel Filho
Quoted 8 lines · Heinz Diehl
Quoted 1 line · On 08.04.2012, artificial11000 wrote:
?mdadm --create --level=5 -n 3
/dev/md127/dev/sdb/dev/sdc/dev/sdd? ? ? ? ---------
Seems your data is gone, forever. You created a new raid manually, which means that you deleted all your previous data.
Quoted 6 lines
You have a backup, do you?
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Quoted 6 lines
I disagree. I got some missing superblock sometime in the past while assembling the array. Recreated it using mdadm -C with the same parameters for the raid-level and raid-devices and it did not touch my encrypted data. I was able to mount just fine after that. I always thought that mdadm would touch only their own superblock when creating.
No, it recreates the parity stripes. It has to, otherwise RAID consistency checks would fail. If, for any reason, drive/device
order or stripe size is diferent, this will scramble your data. The data is still there unless you write to the array, see my other answer. It also overwrites the RAID superblocks.
If everything is the same, the original data will be there though, because the new parity stripes are exactly at the same positions on the same disks as the old ones and created from the same non-parity stripes.
Quoted 2 lines
Though at that time i had a degraded array and my array is built on partitions , not the whole disk.
On a degraded array, you should always only (re-)add the missing device or a replacement.
Arno
Signature · 6 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision. -- Bertrand Russell
Quoted 9 lines · On Sun, Apr 08, 2012 at 06:23:22PM +0200, artificial11000 wrote:
Hi,
as I noticed that I can't access the device, I recreated the raid manually.
mdadm --create --level=5 -n 3/dev/md127/dev/sdb/dev/sdc/dev/sddCould this damage the key-slot?
Are the metadata of the RAID relevant to this?
I read that old versions of mdadm created RAIDs with metadata=0.90 and the newer versions with metadata=1.20.
This may be an additional problem or the only problem. Metadata 0.90 is at the end of the device. Metadata 1.20 is 4k from the start of the device. The other versions are in still other places. (I have no idea what messed up process created these thorougly insane changes.)
So, yes, 4k offset is right in the first key-stripe. If so, then your data is pemanently gone unless you have a header-backup. In this case it is also possible that the array actually assembled right and the problem is _only_ the new raid metadata block.
Arno
Signature · 6 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision. -- Bertrand Russell
Hi guys,
thanks for your effort.
Meanwhile I had to start over and format the whole device.
I have a backup. Allthough it is not really up to date, I can work with it.
Thanks again
artificial
Quoted 24 lines · Arno Wagner
Quoted 9 lines · On Sun, Apr 08, 2012 at 06:23:22PM +0200, artificial11000 wrote:
Hi,
as I noticed that I can't access the device, I recreated the raid manually.
mdadm --create --level=5 -n 3/dev/md127/dev/sdb/dev/sdc/dev/sddCould this damage the key-slot?
Are the metadata of the RAID relevant to this?
I read that old versions of mdadm created RAIDs with metadata=0.90 and the newer versions with metadata=1.20.This may be an additional problem or the only problem. Metadata 0.90 is at the end of the device. Metadata 1.20 is 4k from the start of the device. The other versions are in still other places. (I have no idea what messed up process created these thorougly insane changes.)
So, yes, 4k offset is right in the first key-stripe. If so, then your data is pemanently gone unless you have a header-backup. In this case it is also possible that the array actually assembled right and the problem is _only_ the new raid metadata block.
Arno
Quoted 3 lines · On Sun, Apr 08, 2012 at 10:43:34PM +0200, artificial11000 wrote:
Hi guys,
thanks for your effort.
No problem.
Quoted 2 lines
Meanwhile I had to start over and format the whole device.
I have a backup. Allthough it is not really up to date, I can work with it.
Good. So you already did something very right.
Arno
Quoted 34 lines
Thanks again
artificial
Quoted 17 lines · Arno Wagner
Quoted 9 lines · On Sun, Apr 08, 2012 at 06:23:22PM +0200, artificial11000 wrote:
Hi,
as I noticed that I can't access the device, I recreated the raid manually.
mdadm --create --level=5 -n 3/dev/md127/dev/sdb/dev/sdc/dev/sddCould this damage the key-slot?
Are the metadata of the RAID relevant to this?
I read that old versions of mdadm created RAIDs with metadata=0.90 and the newer versions with metadata=1.20.This may be an additional problem or the only problem. Metadata 0.90 is at the end of the device. Metadata 1.20 is 4k from the start of the device. The other versions are in still other places. (I have no idea what messed up process created these thorougly insane changes.)
Quoted 7 lines
So, yes, 4k offset is right in the first key-stripe. If so, then your data is pemanently gone unless you have a header-backup. In this case it is also possible that the array actually assembled right and the problem is _only_ the new raid metadata block.
Arno
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Signature · 6 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision. -- Bertrand Russell