[dm-crypt] LUKS GPT GUID
Christoph Anton Mitterer
calestyo at scientia.net
Mon Jan 27 16:25:31 CET 2014
On Mon, 2014-01-27 at 10:53 +0100, Karel Zak wrote:
> Frankly, who cares about partition types?
> It's bad idea to use partition types for something else
... but,.. GPT part types are there and won't go away just because
they're mostly unused...
An I think it's actually much worse to have people set *some value*
(which may actually be used by something else in some way - since people
will not just set a random UUID, but something that their part manager
provides them from its list) than a well defined value (even if that is
never used by dm-crypt or its tools.
Moreover,... it may actually make sense for the plain dm-crypt type
(which would of course need another ID than the LUKS type), where we
have no other way to see that this is dmcrypt.
On the other hand one could argue, that this is much like the issue with
MIME types and stuff like .gz or .bz2.
The MIME-type of a gzipped PNG, e.g. image.png.gz should still be
image/gz and not something like application/x-gzip.
GZIP in that case is not a type, but an encoding.
With tar or zip it would be different, since both are not just encodings
of a file.
Now coming back to GPT UUIDs and plain dm-crypt/LUKS:
1) IMHO for LUKS it's clear - it's not like an encoding, but contains
additional stuff (all the header parts) => own GPT type
2) With plain dm-crypt one could argue that this is just an "encoding"
of something below it like "Linux FS" or "MD containter".
So one could do three things:
a) either the GPT type of encrypted partition would apply (if one
follows the principles of MIME)
b) One makes a new GPT type for each <whatever>-on-top-of<plain dmcrypt>
e.g. plainly-dmcrypted-Linux-FS, plainly-dmcrypted-MD-container, and so
c) One goes the pragmatic way and makes just one single type for any
plain dm-crypt partition.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5165 bytes
Desc: not available
More information about the dm-crypt