| Hello out there, sunny greetings from good old germany, For a real long time i had two running RAID5's with LUKS encrypted data on them. I had to change the system, so i setup a new machine, with two new raid5's also encrypted with LUKS, of course with some more data space. I sent the data over network. Anything worked fine for some days. Now my system disk crashed. So i took another system disk from another raid system and started up. One of the data raids was found immediately and i could luksOpen it with my passphrase, the other one could not be assembled. I tried some assembles with --force and --scan. Did not work. Now I had a real bad idea, late at night and lot's of other things to do asides. I zeroed the superblocks of the devices belonging to the raid that could not be assembled. I rebuilt the raid with the same parameters as before and it was rebuilt. The raid was then found immediately. No problems until there, but when i was trying to luksOpen the raid, my passphrase did not work. So i checked the sourcecode of cryptsetup-1.0.7 and saw that in function LUKS_generate_phdr the UUID of the underlying Raid or Device is used in some way. But, by recreating the RAID, the UUID of the RAID has changed. So far so bad. is this UUID used in any way for decryption? Question 2: Would it be a reasonable and walkable way to set back the UUID to the older one (thanks God or whomever, it was noticed in the old mdadm.conf) to get the decryption running again? Question 3: Do you know how to set back the UUID? -- Wolfgang Schindler |
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
