[dm-crypt] LUKS GPT GUID
sven at whgl.uni-frankfurt.de
Mon Jan 27 12:47:49 CET 2014
On Mon, January 27, 2014 11:40, Karel Zak wrote:
> On Mon, Jan 27, 2014 at 11:05:29AM +0100, Pali Rohár wrote:
>> 2014-01-27 Karel Zak <kzak at redhat.com>:
>> > On Sun, Jan 26, 2014 at 10:24:39AM +0100, Milan Broz wrote:
>> >> On 01/26/2014 02:40 AM, Pali Rohár wrote:
>> >> > Hello,
>> >> >
>> >> > according to wikipedia  and other sites (e.g. ) MBR partition
>> >> > for LUKS is E8. I tried to find GPT partition GUID for LUKS, but
>> >> > is nothing on wikipedia  nor google... So has LUKS already
>> > Frankly, who cares about partition types?
>> > IMHO partition types make sense in firmwares like UEFI to detect boot
>> > partition (e.g. GPT system partition) or in special cases when you
>> > want to mark a partition for a special purpose (e.g. /home).
>> > It's bad idea to use partition types for something else, especially
>> > add to the partition table info about partition format (e.g. E8 for
>> > LUKS).
> because it duplicates information and result is fragile...
Partition IDs can be very useful in hinting though. If I want to pull a
component of a raid and move it, a list of partition IDs(or names) might
ease my administration effort. In any case it would not harm to have
> It's always more robust to check /dev/sda3 then rely on partition type in
> partition table.
And slow. Checking all partitions for signatures can take quite some time,
if we don't talk about a handfull of them. Hinting to look in these places
first can increase the speed. And imagine there's not only say lvm and
mdadm but other raid/lvm metadata tools with own signatures and on disk
structure. A common indicator on partition level is meaningfull, as it is
independent of a concrete implementation.
>> > It's nightmare to maintain something like this and I'm sure
>> > that we don't want to maintain mkfs-like programs that modify
>> > partition tables.
>> Of course, mkfs program should not modify partition table! Editing
>> parittion table then it is up to system admin (if he using mkfs) or
>> some high level partition program.
> but we want to have robust system and minimize complexity and
> dependence on humans. So it's better to no depend on partition type by
> default and use everywhere generic "data partition" than force people
> to use special types for LUKS, LVM, swap, ...
While it is more complex during setup/maintanance it eases (and possibly
speeds up) operation. But that's just my POV.
>> >> > preferred/assigned GUID for GPT partition table? There is already
>> >> > GUID for linux data, raid, swap, lvm and home partitions (see ),
>> >> > I think that LUKS should have GUID too.
>> > All these are historical mistakes, I have doubts we want to contribute
>> > to this nonsense.
>> > BTW, do you know what is the "official" list of the partition types
>> > for MBR according to UEFI standard? It's Brouwer's (~aeb) web page
>> > IMHO it's pretty absurd situation when official standards have to link
>> > random hobby web pages on Internet, because there is no official
>> > authority that main such list... I think it obvious proof that
>> > partition types for things like LIKS, swap, ... is unofficial junk.
>> In my opinion, if partition table (e.g GPT) support specifing
>> partition label, uuid or partition type, why user/admin cannot use it
>> (at least for his own usage)?
> Yes, for example partition UUID is excellent thing. I have nothing
> against it.
> .. but we are talking about partition types for LUKS (swap, LVM, ..).
There are good reasons though. Encrypted swap has no signature, thus you'd
need a swap GUID, or use explicit PART UUID (not portable). So setting up
encrypted swaps via GUID is straight forward, while all other means need a
specific hard coding.
I assume there's more good examples ...
>> I think its up to admin, if he want to
>> use it or not. He can write own udev rules to export these information
>> to system /dev/ or not.
> We already export information from PT to udev db and it's already used
> in system (for example mount PARTUUID=).
> All my negative notes are about partition types only.
> Karel Zak <kzak at redhat.com>
> dm-crypt mailing list
> dm-crypt at saout.de
More information about the dm-crypt