Re: LUKS GPT GUID

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2014-01-27 Karel Zak <kzak@xxxxxxxxxx>:
> On Mon, Jan 27, 2014 at 11:05:29AM +0100, Pali Rohár wrote:
>> 2014-01-27 Karel Zak <kzak@xxxxxxxxxx>:
>> > 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 [1] and other sites (e.g. [2]) MBR partition ID
>> >> > for LUKS is E8. I tried to find GPT partition GUID for LUKS, but there
>> >> > is nothing on wikipedia [3] 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).
>>
>> Why?
>
> because it duplicates information and result is fragile...
>
> It's always more robust to  check /dev/sda3 then rely on partition type in
> partition table.
>
>>
>> > 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, ...
>

Yes, by default it is better to not depend. But why force other
users/admins to not use it (if they know what are they doing)?

>> >> > preferred/assigned GUID for GPT partition table? There is already GPT
>> >> > GUID for linux data, raid, swap, lvm and home partitions (see [3]), so
>> >> > 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 [2].
>> >
>> > 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, ..).
>
>> 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.
>

Ok. So why not to define partition id/guid for users/admins who want
to use it? Sure by default nobody forcing to use it, but if partition
table support to store this kind of information, why to not define id
also for luks and allow users to use it if they want?

>     Karel
>
>
> --
>  Karel Zak  <kzak@xxxxxxxxxx>
>  http://karelzak.blogspot.com

-- 
Pali Rohár
pali.rohar@xxxxxxxxx
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt





[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux