> blkid currently, deliberately, returns only the first detected RAID or LUKS > container > for a filesystem - with the checking order being raid first.
Did someone change it already? The issue I reported is actually the other way around. A RAID member device partition (version 0.90 metadata, located at the end of the device) where the assembled raid contained LUKS was identified as being LUKS. Leading to a random raid member being opened and mounted instead of the then degraded raid device (corrupting of the raid integrity). AFAIK: blkid was patched more lately to give LUKS priority over fs signatures, because cryptsetup missed to wipe existing metadata at least in the past. (In addition to giving RAID priority over FSs.) But with this change, LUKS was also (errornously) given priority over RAID, leading to the issue at hand. I think RAID must have priority not only over FSs but also over LUKS. Because RAID should regularly be able to contain LUKS and in this case both metadata will be there, but if LUKS really contains RAID, the RAID metadata would regularly be encrypted. Now, if the device really is LUKS and there is leftover RAID metadata present (Is cryptsetups actually wiping the end of devices, or only filesystem metadata at the beginning?) there is the following risk: If different luks partitions are created on raid1 partitions marked clean and consistent, they would get assembled into an inconsistent array. If it may be possible for cryptsetup to open such a device (if chunksize larger than metadata?) cryptsetup would have to safeguard against opening this. Two things to check with cryptsetup: Wiping end? Opening inconsisten raid? -- breaking raid: root raid_member opened as luks https://bugs.launchpad.net/bugs/531240 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
