* [dm-crypt] LUKS GPT GUID
@ 2014-01-26 1:40 Pali Rohár
2014-01-26 9:24 ` Milan Broz
` (2 more replies)
0 siblings, 3 replies; 19+ messages in thread
From: Pali Rohár @ 2014-01-26 1:40 UTC (permalink / raw)
To: dm-crypt
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
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.
[1] - http://en.wikipedia.org/wiki/Partition_type
[2] - http://www.win.tue.nl/~aeb/partitions/partition_types-1.html
[3] - http://en.wikipedia.org/wiki/GUID_Partition_Table
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [dm-crypt] LUKS GPT GUID 2014-01-26 1:40 [dm-crypt] LUKS GPT GUID Pali Rohár @ 2014-01-26 9:24 ` Milan Broz 2014-01-26 10:17 ` Pali Rohár ` (2 more replies) 2014-01-26 13:18 ` Arno Wagner 2014-01-31 20:56 ` Pali Rohár 2 siblings, 3 replies; 19+ messages in thread From: Milan Broz @ 2014-01-26 9:24 UTC (permalink / raw) To: Pali Rohár, dm-crypt; +Cc: Karel Zak 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 > 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. Hi, this is wonderful... who assigned E8 type? I thought LUKS has no assigned partition type and also I doubt LVM2 type is properly assigned too (it is probably form the LVM1 age when it was implemented in-kernel directly and partition type was important to detect it.) But not sure about this. Anyway, today partition type is ignored (both in LVM and LUKS), so it is really just for convenience for other applications. (Anyway, code should always use (lib)blkid to detect what's really on the device, not trust partition id.) For GPT GUID, I would like to know how these GUID codes appeared in libfdisk and how this was standardized for LVM. LUKS should have GUID too then... (cc to Karel as util-linux/libfdisk maintainer ;-) If this is really used, both should be documented in LUKS specification. Thanks, Milan > > [1] - http://en.wikipedia.org/wiki/Partition_type > [2] - http://www.win.tue.nl/~aeb/partitions/partition_types-1.html > [3] - http://en.wikipedia.org/wiki/GUID_Partition_Table ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dm-crypt] LUKS GPT GUID 2014-01-26 9:24 ` Milan Broz @ 2014-01-26 10:17 ` Pali Rohár 2014-01-26 16:02 ` Rod Smith 2014-01-26 15:55 ` Christoph Anton Mitterer 2014-01-27 9:53 ` Karel Zak 2 siblings, 1 reply; 19+ messages in thread From: Pali Rohár @ 2014-01-26 10:17 UTC (permalink / raw) To: Milan Broz; +Cc: dm-crypt, Karel Zak, rodsmith 2014-01-26 Milan Broz <gmazyland@gmail.com>: > 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 >> 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. > > Hi, > > this is wonderful... who assigned E8 type? I thought LUKS has no assigned > partition type and also I doubt LVM2 type is properly assigned too > (it is probably form the LVM1 age when it was implemented in-kernel directly > and partition type was important to detect it.) But not sure about this. > > Anyway, today partition type is ignored (both in LVM and LUKS), so it is really > just for convenience for other applications. > (Anyway, code should always use (lib)blkid to detect what's really on the device, > not trust partition id.) > > For GPT GUID, I would like to know how these GUID codes appeared in libfdisk > and how this was standardized for LVM. LUKS should have GUID too then... > (cc to Karel as util-linux/libfdisk maintainer ;-) > > If this is really used, both should be documented in LUKS specification. > > Thanks, > Milan > >> >> [1] - http://en.wikipedia.org/wiki/Partition_type >> [2] - http://www.win.tue.nl/~aeb/partitions/partition_types-1.html >> [3] - http://en.wikipedia.org/wiki/GUID_Partition_Table > I know that linux ignoring MBR partition ID and also GPT GUID. Filesystems are detected by magic headers... But other systems (like windows) are still using MBR partition ID and also GPT partition GUID. So it is still good to store these information. Also if you want, you can create udev rule to map some MBR ID/GPT GUID partition to some name (maybe together with other information). And who assigned E8 for LUKS? I really do not know. I thought that if wikipedia and also other sources on internet specifing it is standard and it is using by some applications... Also I do not know who assigning GPT GUID for partitions. For me it looks like application developer is choosing one GUID randomly... CCing Roderick W. Smith, who maintaing gdisk utility. Roderick, who and how assinged GPT GUIDs which you added to gdisk program? What do you know about GPT GUID for LUKS? -- Pali Rohár pali.rohar@gmail.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dm-crypt] LUKS GPT GUID 2014-01-26 10:17 ` Pali Rohár @ 2014-01-26 16:02 ` Rod Smith 0 siblings, 0 replies; 19+ messages in thread From: Rod Smith @ 2014-01-26 16:02 UTC (permalink / raw) To: Pali Rohár, Milan Broz; +Cc: dm-crypt, Karel Zak On 01/26/2014 05:17 AM, Pali Rohár wrote: > CCing Roderick W. Smith, who maintaing gdisk utility. Roderick, who > and how assinged GPT GUIDs which you added to gdisk program? What do > you know about GPT GUID for LUKS? There is no central authority or registry for GPT type code GUIDs. The closest thing to that is probably the Wikipedia page on GPT. A properly-constructed GUID should be unique -- at least, the statistical probability of a collision is EXTREMELY small. Thus, anybody who wants to can generate a GUID for a new partition type, and in fact there's been a fair amount of that going on over the past few years. Many computer manufacturers have manufacturer-specific GUIDs for ESP-like partitions, for instance. As OSes adopt GPT, they also tend to add new codes for their own use. In the Linux world, it's really up to the parted developers and me to implement such codes, since it's libparted and gdisk that set them. If somebody else needs a new code, they'll need to submit patches or propose a change to me and/or the libparted developers. (The latter is more important, really, since most Linux installation tools rely on libparted.) I don't know who generated most of the Linux GPT GUIDs, but I generated the one for Linux filesystem data (0FC63DAF-8483-4772-8E79-3D69D8477DE4). See the following mailing list thread to get an idea of how I and the libparted developers discussed the issue and decided to implement it: http://lists.gnu.org/archive/html/bug-parted/2011-06/msg00026.html The Linux /home partition type code was created by the Freedesktop.org developers (see http://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html), but I wasn't privy to whatever discussions led to its creation. I added it to gdisk when I heard about it, but I haven't heard of libparted patches to support it, so I don't know if it's really going anywhere. In terms of gdisk, I began with the list of codes from Wikipedia's GPT page at the time I wrote gdisk. The list on Wikipedia has expanded over time, and I've tried to keep up. I've also added codes to gdisk from other sources, such as when I run into a new code "in the wild" or in source code for another project. (In most such cases, I've also added the code to the Wikipedia page, if it's not already there.) The gdisk parttypes.cc source code file holds all the codes that gdisk supports, and some of those have comments with URLs to the pages that describe the type code. You can therefore check that source code page and/or the Wikipedia page if you have questions about specific type codes. Doing a Web search on the code can also be informative. As far as LUKS goes, I don't know of a Linux GPT GUID for it. If you think it's important to implement such a code, feel free to post to the parted mailing list. I don't think it's really important, though; Linux ignores partition type codes for most purposes, and so long as a partition is flagged with one of the existing Linux-specific type codes, other OSes should ignore it. -- Rod Smith rodsmith@rodsbooks.com http://www.rodsbooks.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dm-crypt] LUKS GPT GUID 2014-01-26 9:24 ` Milan Broz 2014-01-26 10:17 ` Pali Rohár @ 2014-01-26 15:55 ` Christoph Anton Mitterer 2014-01-27 9:53 ` Karel Zak 2 siblings, 0 replies; 19+ messages in thread From: Christoph Anton Mitterer @ 2014-01-26 15:55 UTC (permalink / raw) To: dm-crypt [-- Attachment #1: Type: text/plain, Size: 752 bytes --] On Sun, 2014-01-26 at 10:24 +0100, Milan Broz wrote: > For GPT GUID, I would like to know how these GUID codes appeared in libfdisk > and how this was standardized for LVM. LUKS should have GUID too then... > (cc to Karel as util-linux/libfdisk maintainer ;-) I think it would make sense to just pick one, even though it is not used. At least it may be helpful in partition table managers which can then show the type as a readable name. So just pick one... like my /proc/sys/kernel/random/uuid suggests that we use: ca7d7ccb-63ed-4c53-861c-1742536059cc ;-) We should just forward it to the developers of all known GPT partition managers (gdisk, I guess parted,...) which makes any choice a de facto standard. Cheers, Chris. [-- Attachment #2: smime.p7s --] [-- Type: application/x-pkcs7-signature, Size: 5165 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dm-crypt] LUKS GPT GUID 2014-01-26 9:24 ` Milan Broz 2014-01-26 10:17 ` Pali Rohár 2014-01-26 15:55 ` Christoph Anton Mitterer @ 2014-01-27 9:53 ` Karel Zak 2014-01-27 10:05 ` Pali Rohár 2014-01-27 15:25 ` Christoph Anton Mitterer 2 siblings, 2 replies; 19+ messages in thread From: Karel Zak @ 2014-01-27 9:53 UTC (permalink / raw) To: Milan Broz; +Cc: dm-crypt, Pali Rohár 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). 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. > > 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. > this is wonderful... who assigned E8 type? I thought LUKS has no assigned > partition type and also I doubt LVM2 type is properly assigned too > (it is probably form the LVM1 age when it was implemented in-kernel directly > and partition type was important to detect it.) But not sure about this. > > Anyway, today partition type is ignored (both in LVM and LUKS), so it is really > just for convenience for other applications. > (Anyway, code should always use (lib)blkid to detect what's really on the device, > not trust partition id.) > > For GPT GUID, I would like to know how these GUID codes appeared in libfdisk > and how this was standardized for LVM. LUKS should have GUID too then... > (cc to Karel as util-linux/libfdisk maintainer ;-) As Rod for gfdisk, wikipedia is the first source, and then random requests from community. > > [2] - http://www.win.tue.nl/~aeb/partitions/partition_types-1.html Karel -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dm-crypt] LUKS GPT GUID 2014-01-27 9:53 ` Karel Zak @ 2014-01-27 10:05 ` Pali Rohár 2014-01-27 10:40 ` Karel Zak 2014-01-27 15:25 ` Christoph Anton Mitterer 1 sibling, 1 reply; 19+ messages in thread From: Pali Rohár @ 2014-01-27 10:05 UTC (permalink / raw) To: Karel Zak; +Cc: dm-crypt, Milan Broz 2014-01-27 Karel Zak <kzak@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 [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? > 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. >> > 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)? 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. >> this is wonderful... who assigned E8 type? I thought LUKS has no assigned >> partition type and also I doubt LVM2 type is properly assigned too >> (it is probably form the LVM1 age when it was implemented in-kernel directly >> and partition type was important to detect it.) But not sure about this. >> >> Anyway, today partition type is ignored (both in LVM and LUKS), so it is really >> just for convenience for other applications. >> (Anyway, code should always use (lib)blkid to detect what's really on the device, >> not trust partition id.) >> >> For GPT GUID, I would like to know how these GUID codes appeared in libfdisk >> and how this was standardized for LVM. LUKS should have GUID too then... >> (cc to Karel as util-linux/libfdisk maintainer ;-) > > As Rod for gfdisk, wikipedia is the first source, and then random > requests from community. > >> > [2] - http://www.win.tue.nl/~aeb/partitions/partition_types-1.html > > Karel > > -- > Karel Zak <kzak@redhat.com> > http://karelzak.blogspot.com -- Pali Rohár pali.rohar@gmail.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dm-crypt] LUKS GPT GUID 2014-01-27 10:05 ` Pali Rohár @ 2014-01-27 10:40 ` Karel Zak 2014-01-27 10:49 ` Pali Rohár 2014-01-27 11:47 ` Sven Eschenberg 0 siblings, 2 replies; 19+ messages in thread From: Karel Zak @ 2014-01-27 10:40 UTC (permalink / raw) To: Pali Rohár; +Cc: dm-crypt, Milan Broz On Mon, Jan 27, 2014 at 11:05:29AM +0100, Pali Rohár wrote: > 2014-01-27 Karel Zak <kzak@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 [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, ... > >> > 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. Karel -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dm-crypt] LUKS GPT GUID 2014-01-27 10:40 ` Karel Zak @ 2014-01-27 10:49 ` Pali Rohár 2014-01-27 11:47 ` Sven Eschenberg 1 sibling, 0 replies; 19+ messages in thread From: Pali Rohár @ 2014-01-27 10:49 UTC (permalink / raw) To: Karel Zak; +Cc: dm-crypt, Milan Broz 2014-01-27 Karel Zak <kzak@redhat.com>: > On Mon, Jan 27, 2014 at 11:05:29AM +0100, Pali Rohár wrote: >> 2014-01-27 Karel Zak <kzak@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 [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@redhat.com> > http://karelzak.blogspot.com -- Pali Rohár pali.rohar@gmail.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dm-crypt] LUKS GPT GUID 2014-01-27 10:40 ` Karel Zak 2014-01-27 10:49 ` Pali Rohár @ 2014-01-27 11:47 ` Sven Eschenberg 1 sibling, 0 replies; 19+ messages in thread From: Sven Eschenberg @ 2014-01-27 11:47 UTC (permalink / raw) To: dm-crypt 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@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 [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... 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 additional information. > > 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 >> 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, ..). 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 > > > -- > Karel Zak <kzak@redhat.com> > http://karelzak.blogspot.com > _______________________________________________ > dm-crypt mailing list > dm-crypt@saout.de > http://www.saout.de/mailman/listinfo/dm-crypt > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dm-crypt] LUKS GPT GUID 2014-01-27 9:53 ` Karel Zak 2014-01-27 10:05 ` Pali Rohár @ 2014-01-27 15:25 ` Christoph Anton Mitterer 2014-01-27 20:41 ` Milan Broz 1 sibling, 1 reply; 19+ messages in thread From: Christoph Anton Mitterer @ 2014-01-27 15:25 UTC (permalink / raw) To: dm-crypt [-- Attachment #1: Type: text/plain, Size: 1884 bytes --] On Mon, 2014-01-27 at 10:53 +0100, Karel Zak wrote: > Frankly, who cares about partition types? Sure... > 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 on. c) One goes the pragmatic way and makes just one single type for any plain dm-crypt partition. Cheers, Chris. [-- Attachment #2: smime.p7s --] [-- Type: application/x-pkcs7-signature, Size: 5165 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dm-crypt] LUKS GPT GUID 2014-01-27 15:25 ` Christoph Anton Mitterer @ 2014-01-27 20:41 ` Milan Broz 2014-01-27 21:12 ` Christoph Anton Mitterer 2014-01-28 0:04 ` Arno Wagner 0 siblings, 2 replies; 19+ messages in thread From: Milan Broz @ 2014-01-27 20:41 UTC (permalink / raw) To: Christoph Anton Mitterer, dm-crypt; +Cc: Karel Zak On 01/27/2014 04:25 PM, Christoph Anton Mitterer wrote: > Now coming back to GPT UUIDs and plain dm-crypt/LUKS: ... > c) One goes the pragmatic way and makes just one single type for any > plain dm-crypt partition. So let's define, approve (and forget about it) "Encrypted disk partition (LUKS, dm-crypt, TrueCrypt, loop-AES or similar)" With GUID generated (without doubt by properly seeded Christoph's RNG ;-) ca7d7ccb-63ed-4c53-861c-1742536059cc <fanfare> Regards, Milan ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dm-crypt] LUKS GPT GUID 2014-01-27 20:41 ` Milan Broz @ 2014-01-27 21:12 ` Christoph Anton Mitterer 2014-01-28 16:58 ` Milan Broz 2014-01-28 0:04 ` Arno Wagner 1 sibling, 1 reply; 19+ messages in thread From: Christoph Anton Mitterer @ 2014-01-27 21:12 UTC (permalink / raw) To: dm-crypt [-- Attachment #1: Type: text/plain, Size: 647 bytes --] On Mon, 2014-01-27 at 21:41 +0100, Milan Broz wrote: > "Encrypted disk partition (LUKS, dm-crypt, TrueCrypt, loop-AES or similar)" > With GUID generated (without doubt by properly seeded Christoph's RNG ;-) > ca7d7ccb-63ed-4c53-861c-1742536059cc I think at most we should say: LUKS or rather even LUKS = ca7d7ccb-63ed-4c53-861c-1742536059cc dm-crypt = 7ffec5c9-2d00-49b7-8941-3ea10a5586b7 ... but especially not mix TC and loop-AES together, since dm-crypt is not the upstream for them... Agreed? I could pass this on then to Wikipedia, GPT fdiks and parted Cheers, Chris. PS: UUIDs created with TRNG seeded Linux RNG ;-P [-- Attachment #2: smime.p7s --] [-- Type: application/x-pkcs7-signature, Size: 5165 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dm-crypt] LUKS GPT GUID 2014-01-27 21:12 ` Christoph Anton Mitterer @ 2014-01-28 16:58 ` Milan Broz 2014-01-29 13:47 ` Christoph Anton Mitterer 0 siblings, 1 reply; 19+ messages in thread From: Milan Broz @ 2014-01-28 16:58 UTC (permalink / raw) To: Christoph Anton Mitterer, dm-crypt On 01/27/2014 10:12 PM, Christoph Anton Mitterer wrote: > On Mon, 2014-01-27 at 21:41 +0100, Milan Broz wrote: >> "Encrypted disk partition (LUKS, dm-crypt, TrueCrypt, loop-AES or similar)" >> With GUID generated (without doubt by properly seeded Christoph's RNG ;-) >> ca7d7ccb-63ed-4c53-861c-1742536059cc > > I think at most we should say: > LUKS or rather even > LUKS = ca7d7ccb-63ed-4c53-861c-1742536059cc > dm-crypt = 7ffec5c9-2d00-49b7-8941-3ea10a5586b7 > ... but especially not mix TC and loop-AES together, since dm-crypt is > not the upstream for them... My idea was just to use one generic encrypted partition marking, whatever format it is... But really, who cares? :) If you want, send it to the "upstream". Milan ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dm-crypt] LUKS GPT GUID 2014-01-28 16:58 ` Milan Broz @ 2014-01-29 13:47 ` Christoph Anton Mitterer 0 siblings, 0 replies; 19+ messages in thread From: Christoph Anton Mitterer @ 2014-01-29 13:47 UTC (permalink / raw) To: dm-crypt [-- Attachment #1: Type: text/plain, Size: 1981 bytes --] On Tue, 2014-01-28 at 17:58 +0100, Milan Broz wrote: > On 01/27/2014 10:12 PM, Christoph Anton Mitterer wrote: > > On Mon, 2014-01-27 at 21:41 +0100, Milan Broz wrote: > >> "Encrypted disk partition (LUKS, dm-crypt, TrueCrypt, loop-AES or similar)" > >> With GUID generated (without doubt by properly seeded Christoph's RNG ;-) > >> ca7d7ccb-63ed-4c53-861c-1742536059cc > > > > I think at most we should say: > > LUKS or rather even > > LUKS = ca7d7ccb-63ed-4c53-861c-1742536059cc > > dm-crypt = 7ffec5c9-2d00-49b7-8941-3ea10a5586b7 > > ... but especially not mix TC and loop-AES together, since dm-crypt is > > not the upstream for them... > > My idea was just to use one generic encrypted partition marking, whatever > format it is... Well I don't like the idea of having such kind of wildcard/group types a lot... since it pretty much contradicts the idea of partition types, IMHO. Having something like "Linux Filesystem" is pretty much useless, since then again you don't know what it actually is (even though that is of course just a hint, and no guarantee). > But really, who cares? :) Well I think that especially for plain dm-crypt it could be helpful for tools/etc. to recognise the partition as an encrypted one, which is otherwise not really possible. I pushed forward these "definitions" to: - English Wikipedia: http://en.wikipedia.org/w/index.php?title=GUID_Partition_Table&diff=592830774&oldid=592521574 - German Wikipedia: http://de.wikipedia.org/w/index.php?title=GUID_Partition_Table&diff=126967660&oldid=126000138 - GPT fdisk: http://sourceforge.net/mailarchive/message.php?msg_id=31895963 - util-linux fdisk: http://thread.gmane.org/gmane.linux.utilities.util-linux-ng/8436 - GNU parted: <wrote to their list but either it's broken or I don't know...> Arno, could you add that perhaps to the FAQ? Stating though that right now it's not really used and probably never will. Cheers, Chris. [-- Attachment #2: smime.p7s --] [-- Type: application/x-pkcs7-signature, Size: 5165 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dm-crypt] LUKS GPT GUID 2014-01-27 20:41 ` Milan Broz 2014-01-27 21:12 ` Christoph Anton Mitterer @ 2014-01-28 0:04 ` Arno Wagner 1 sibling, 0 replies; 19+ messages in thread From: Arno Wagner @ 2014-01-28 0:04 UTC (permalink / raw) To: dm-crypt On Mon, Jan 27, 2014 at 21:41:17 CET, Milan Broz wrote: > On 01/27/2014 04:25 PM, Christoph Anton Mitterer wrote: > > > Now coming back to GPT UUIDs and plain dm-crypt/LUKS: > ... > > > c) One goes the pragmatic way and makes just one single type for any > > plain dm-crypt partition. > > So let's define, approve (and forget about it) > > "Encrypted disk partition (LUKS, dm-crypt, TrueCrypt, loop-AES or similar)" > > With GUID generated (without doubt by properly seeded Christoph's RNG ;-) > ca7d7ccb-63ed-4c53-861c-1742536059cc > > <fanfare> I approve this solution! <applause> Arno > Regards, > Milan > _______________________________________________ > dm-crypt mailing list > dm-crypt@saout.de > http://www.saout.de/mailman/listinfo/dm-crypt -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- A good decision is based on knowledge and not on numbers. - Plato ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dm-crypt] LUKS GPT GUID 2014-01-26 1:40 [dm-crypt] LUKS GPT GUID Pali Rohár 2014-01-26 9:24 ` Milan Broz @ 2014-01-26 13:18 ` Arno Wagner 2014-01-31 20:56 ` Pali Rohár 2 siblings, 0 replies; 19+ messages in thread From: Arno Wagner @ 2014-01-26 13:18 UTC (permalink / raw) To: dm-crypt I don't think one is needed. I just use whatever is in the LUKS container. Most are on RAID though, and there I just use 0xfd for autodetection to get a clean, transparent assembly process that doe snot rely on anything in user-space. (The current Linux software RAID folks are unfortunately pretty incompetent and completely missed the point of autodetection. Fortunately the old, well implemented, mechanisms continue to work.) Arno On Sun, Jan 26, 2014 at 02:40:21 CET, 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 > 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. > > [1] - http://en.wikipedia.org/wiki/Partition_type > [2] - http://www.win.tue.nl/~aeb/partitions/partition_types-1.html > [3] - http://en.wikipedia.org/wiki/GUID_Partition_Table > > -- > Pali Rohár > pali.rohar@gmail.com > _______________________________________________ > dm-crypt mailing list > dm-crypt@saout.de > http://www.saout.de/mailman/listinfo/dm-crypt -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- A good decision is based on knowledge and not on numbers. - Plato ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dm-crypt] LUKS GPT GUID 2014-01-26 1:40 [dm-crypt] LUKS GPT GUID Pali Rohár 2014-01-26 9:24 ` Milan Broz 2014-01-26 13:18 ` Arno Wagner @ 2014-01-31 20:56 ` Pali Rohár 2014-01-31 21:32 ` Christoph Anton Mitterer 2 siblings, 1 reply; 19+ messages in thread From: Pali Rohár @ 2014-01-31 20:56 UTC (permalink / raw) To: dm-crypt 2014-01-26 Pali Rohár <pali.rohar@gmail.com>: > 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 > 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. > > [1] - http://en.wikipedia.org/wiki/Partition_type > [2] - http://www.win.tue.nl/~aeb/partitions/partition_types-1.html > [3] - http://en.wikipedia.org/wiki/GUID_Partition_Table > > -- > Pali Rohár > pali.rohar@gmail.com So what do you think? Should there be GPT GUID for LUKS defined? Or not? -- Pali Rohár pali.rohar@gmail.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dm-crypt] LUKS GPT GUID 2014-01-31 20:56 ` Pali Rohár @ 2014-01-31 21:32 ` Christoph Anton Mitterer 0 siblings, 0 replies; 19+ messages in thread From: Christoph Anton Mitterer @ 2014-01-31 21:32 UTC (permalink / raw) To: dm-crypt [-- Attachment #1: Type: text/plain, Size: 418 bytes --] On Fri, 2014-01-31 at 21:56 +0100, Pali Rohár wrote: > So what do you think? Should there be GPT GUID for LUKS defined? Or not? There is one now... as you can see from the later posts of that thread. I placed it already in Wikipedia, etc. Of course nobody really enforces anyone to use that... and there is currently (and likely never) no place where it's really used (technically). Cheers, Chris. [-- Attachment #2: smime.p7s --] [-- Type: application/x-pkcs7-signature, Size: 5165 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2014-01-31 21:33 UTC | newest] Thread overview: 19+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-01-26 1:40 [dm-crypt] LUKS GPT GUID Pali Rohár 2014-01-26 9:24 ` Milan Broz 2014-01-26 10:17 ` Pali Rohár 2014-01-26 16:02 ` Rod Smith 2014-01-26 15:55 ` Christoph Anton Mitterer 2014-01-27 9:53 ` Karel Zak 2014-01-27 10:05 ` Pali Rohár 2014-01-27 10:40 ` Karel Zak 2014-01-27 10:49 ` Pali Rohár 2014-01-27 11:47 ` Sven Eschenberg 2014-01-27 15:25 ` Christoph Anton Mitterer 2014-01-27 20:41 ` Milan Broz 2014-01-27 21:12 ` Christoph Anton Mitterer 2014-01-28 16:58 ` Milan Broz 2014-01-29 13:47 ` Christoph Anton Mitterer 2014-01-28 0:04 ` Arno Wagner 2014-01-26 13:18 ` Arno Wagner 2014-01-31 20:56 ` Pali Rohár 2014-01-31 21:32 ` Christoph Anton Mitterer
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.