So the superblock on the member that got mis-opened appears to have been overwritten. Maybe by writing/using to the opened luks device that thought the full partition is used by luks, without respecting the room of the raid superblock at the end of the disk.
May be cryptsetup selects a raid member as source device, or the right luks UUID is identified but gets tested againsts the raid member and it incorrectly matches ("cryptsetup isLuks" does not recongnize it really is a raid member not a luks device).
Thank you for helping to track this down.
So the superblock on the member that got mis-opened appears to have been overwritten. Maybe by writing/using to the opened luks device that thought the full partition is used by luks, without respecting the room of the raid superblock at the end of the disk.
How can opening a member happen? The cryptsetup-hook tries to identify the luks dependencies of ther rootfs. bazaar. launchpad. net/~ubuntu- branches/ ubuntu/ lucid/cryptsetu p/lucid/ annotate/ head%3A/ debian/ initramfs/ cryptroot- hook
http://
May be cryptsetup selects a raid member as source device, or the right luks UUID is identified but gets tested againsts the raid member and it incorrectly matches ("cryptsetup isLuks" does not recongnize it really is a raid member not a luks device).