On Tue, Mar 09, 2010 at 10:53:29PM -0000, Scott James Remnant wrote:
> Steve: why is this a bug in blkid? You yourself proposed the patch that
> whenever LUKS metadata is detected, it *always* returns LUKS.
Scott, AIUI this is a case where a given partition has both LUKS and RAID
signatures, and the LUKS signature is given precedence. I believe this is a
specific corner case that we overlooked in the previous patch, and that RAID
signatures need to be given precedence over LUKS.
For the general case of filesystem types, it still holds that LUKS should
take precedence; this particular bug only arises because both RAID and LUKS
are treated specially in blkid (on the grounds that both require manual
configuration to be activated) but the order of precedence is wrong.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>
On Tue, Mar 09, 2010 at 10:53:29PM -0000, Scott James Remnant wrote:
> Steve: why is this a bug in blkid? You yourself proposed the patch that
> whenever LUKS metadata is detected, it *always* returns LUKS.
Scott, AIUI this is a case where a given partition has both LUKS and RAID
signatures, and the LUKS signature is given precedence. I believe this is a
specific corner case that we overlooked in the previous patch, and that RAID
signatures need to be given precedence over LUKS.
For the general case of filesystem types, it still holds that LUKS should
take precedence; this particular bug only arises because both RAID and LUKS
are treated specially in blkid (on the grounds that both require manual
configuration to be activated) but the order of precedence is wrong.
-- www.debian. org/
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://
<email address hidden> <email address hidden>