Dale R. Worley wrote: > This raises the related question of whether there should be codes to > identify the partition type inside the LUKS partition. (Dropping Debian bug from Cc for this.) I don't think that really matches up with the way disklabel types work any more than, say, identifying the type of data stored in a filesystem would. There actually _are_ GPT types in fdisk for "Linux root (x86)", "Linux home" etc. but I consider these to be anomalous and never use them as there's an infinite number of possible nestings there. If users want to mint their own GPT types for those purposes, they can, of course. My usual stance is that type identifiers should be shallow at each level (one reason piercing through LUKS to get a type code is semantically bad) and present at as many levels as necessary. I might support an extension proposal to allow (but not require) a type for the underlying volume to be added as part of the _LUKS_ header, therefore (probably using a GPT type just for convenience). However, I also think the argument that it's unnecessary because Linux wouldn't interpret it is much more valid there, because LUKS is more or less defined by its use in Linux, whereas GPT and MBR disklabels are not and have more stringent interop requirements with other tools and OSes. Either way, I don't think that's nearly as important. ---> Drake Wilson -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
