LUKS partition types, redux

LUKS partition types, redux

[Drake Wilson]

Good day, folks of util-linux;

Summary: I would like to reopen the suggestion to add LUKS partition type codes
for MBR and for GPT to util-linux's fdisk.  In a previous discussion, it was
said that since Linux does not interpret partition types, there is no need for
this, but concrete data loss has now occurred as a result of a related bug in
other software combined with the lack of a user-visible LUKS type in a similar
partitioning program, and I believe that warrants re-examination of the situation.

Details:

I recently submitted Debian wishlist bug #770211 [1] suggesting to add e8 as the
MBR type code for LUKS to fdisk, per [2], mainly for consistency with my wishlist
item for gdisk at [3].  I was asked to ask about it here.  (I see now that fdisk
also handles GPT disklabels, which I wasn't previously aware of.)

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770211
[2] http://www.win.tue.nl/~aeb/partitions/partition_types-1.html
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769631

I see now that there was a thread in January starting at [4] (message-ID
1390934933.15213.17.camel@heisenberg.scientia.net) about this, and the overall
result seemed to be that since Linux ignores partition type codes, there is
no reason to provide one for LUKS volumes.  The counterargument (which I agree
with) was roughly that since the type code slots exist in the first place, it
would be better to help the user semantically align them with the partition
contents, to prevent future issues from other type codes being used instead and
then misinterpreted by other systems.

[4] http://marc.info/?l=util-linux-ng&m=139093540719399&w=2

I would like to point out additional concrete evidence for the counterargument
now, in terms of harm minimization.  I previously tagged LUKS volumes on GPT with
a type code corresponding to the underlying volume type, as the closest thing I
could find (and a straw poll of some other Linux sysadmins I know says some of them
do the same).  I recently submitted Debian bug #768897 [5] in which partman-lvm,
a component of the Debian installer, overaggressively interprets the LVM type as a
normative request to make the partition contain an LVM PV, thus destroying all of
my existing LVM-on-LUKS volumes.  While I firmly believe that this is a bug in
partman-lvm and not in util-linux, had I used util-linux's fdisk to make the
partition tables, the presentation of a LUKS type code there would have
prevented significant data loss in this case.  (In my case, I used gdisk, but
I'm taking it up with them separately.)

[5] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768897

I would thus like to re-propose adding a LUKS type.  Alternatively, if a LUKS
type is still considered a bad idea, I would like to suggest allocating a GPT ID
analogous to the "da = Non-FS data" MBR type code, which would at least allow the
user to choose a fallback that has a known null semantic, rather than tagging their
volumes with some arbitrary ID that may be misinterpreted; that would help avert
analogous problems for future types as well.

(I also believe more philosophically that the user should be supported in the
possibility of integrating with other partition management systems that may wish
to detect LUKS and do something special with it, without requiring all other such
systems to incorporate a blkid-like system for checking in several places for the
"basic nature" of a volume.  I mention this only for the record, since the previous
thread suggests the util-linux maintainers don't agree with this.)

Thanks for any (polite) replies.

   ---> Drake Wilson

Re: LUKS partition types, redux

[Dale R. Worley]

> From: Drake Wilson <drake@dasyatidae.net>
> 
> Summary: I would like to reopen the suggestion to add LUKS partition
> type codes for MBR and for GPT to util-linux's fdisk.

It certainly makes sense to me.

This raises the related question of whether there should be codes to
identify the partition type inside the LUKS partition.  That is, the
partition table code identifies the partition as a LUKS partition, but
once one has supplied the keys for LUKS encryption, is there any way
to tell the type of the encrypted partition without testing for magic
numbers (using "file" or the like)?

I suppose there aren't enough type codes in MBR to allow separately
identifying "ext4 inside LUKS", but with GPT it would be possible, and
even could be done systematically.  E.g., if the UUID for a partition
type is XXX, then the partition type for that type inside of LUKS is
MD5("LUKS" XXX)...

Then again, perhaps you would not want to reveal the type of the
encrypted partition.

Dale

Re: LUKS partition types, redux

[Drake Wilson]

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

Re: Bug#770211: LUKS partition types, redux

[Phillip Susi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/19/2014 5:24 PM, Dale R. Worley wrote:
> This raises the related question of whether there should be codes
> to identify the partition type inside the LUKS partition.  That is,
> the partition table code identifies the partition as a LUKS
> partition, but once one has supplied the keys for LUKS encryption,
> is there any way to tell the type of the encrypted partition
> without testing for magic numbers (using "file" or the like)?

Linux doesn't pay any attention to partition type codes anyhow and
just uses blkid to identify the contents.

> I suppose there aren't enough type codes in MBR to allow
> separately identifying "ext4 inside LUKS", but with GPT it would be
> possible, and even could be done systematically.  E.g., if the UUID
> for a partition type is XXX, then the partition type for that type
> inside of LUKS is MD5("LUKS" XXX)...
> 
> Then again, perhaps you would not want to reveal the type of the 
> encrypted partition.

That too.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUbhoWAAoJEI5FoCIzSKrwfZAH/AnTDFG8Nes4Sa+cKebZs9D/
Atf7SrWYQFy++p0o0sNKcSIrdjHghIGEzq8oTZ5pBgnEfu94/uTATUSGSFum7bqL
3ZYPgKNGi7SOj/Oc03p+Tzadjk01gpHUQMcj8jcHJUbrJheLCssPyB558vA5Vqrz
D8bLbOz9JmoDQ+zpWrachKv3+7XAfh0ri54tKsEmNFKN3LOhrxyoVfIGIJf+MFQK
kssPT/ZKD3W/PEBTaI/pcwaCo1+vdR2JYiy4ODBQy7LMfvvw97N3aZEKgRGgLudF
NWApQR7AZLxjD2YllE0NI2NBeq4/8DgLicwnnJSqdHvKFKlbwC0Iq5wIugNjSds=
=s8LS
-----END PGP SIGNATURE-----

Re: LUKS partition types, redux

[Dale R. Worley]

> From: Drake Wilson <drake@dasyatidae.net>

> 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).

That sounds like a better proposal to me.  But I have no idea whether
LUKS can support such an extension.

Dale

Re: LUKS partition types, redux

[Milan Broz]

On 11/20/2014 10:33 PM, Dale R. Worley wrote:
>> From: Drake Wilson <drake@dasyatidae.net>
> 
>> 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).
> 
> That sounds like a better proposal to me.  But I have no idea whether
> LUKS can support such an extension.

If I understand it correctly, you want to duplicate some UUID stored
in LUKS container payload to LUKS header?

LUKS will not support such extension. For two reasons:

- there is a clear layer separation, LUKS handle block layer encryption,
treating container data as a block device. It doesn't care about any
signatures or whatever is contained in data.
This information can be stored elsewhere (UUID in fstab of underlying device,
for example) but not in the LUKS header.

- for security reasons: if you add visible UUID of data inside container,
now you have definitely at least part of plaintext/ciphertext pair
available for attacker (UUID is stored on fixed offset).

Not that it makes possible ciphertext modification attacks to devices without
integrity protection much worse... but use this concept as a design decision
in a security tool would be just ridiculous.

Milan

Re: LUKS partition types, redux (wandering into the weeds)

[Drake Wilson]

Milan Broz wrote:
> If I understand it correctly, you want to duplicate some UUID stored
> in LUKS container payload to LUKS header?

Just to be clear (even though you weren't responding to me), I only said anything
about LUKS extension as an offhand comment in response to Dale.  This is not relevant
to my _original_ post, which was about partition type codes as part of GPT and MBR
disklabels for disks that contain LUKS volumes.  The latter is the only thing I'm
directly interested in, and I'm not going to participate further in this subthread.

   ---> Drake Wilson

Re: Bug#770211: LUKS partition types, redux

[Drake Wilson]

Phillip Susi wrote:
[originally re Dale's question]
> Linux doesn't pay any attention to partition type codes anyhow and
> just uses blkid to identify the contents.

So---entirely aside from the _other_ subthread about types _inside_ LUKS---do
you still intend to provide this as a reason for not adding GPT/MBR LUKS
types to fdisk, even in light of the destructive interaction I mentioned in
my first post?  I'm worried that my having said anything else while replying
to Dale may have been a mistake and given the impression that "no types inside
LUKS" answers my original concern, which it doesn't.

As I mentioned, GPT and MBR have significant interop characteristics with
other tools, so I'm not convinced by the "Linux only uses blkid" there.  If
that's what you're truly going with after having seen the practical results,
I won't argue further, but I'd like to know.

   ---> Drake Wilson

Re: LUKS partition types, redux

[Karel Zak]

On Wed, Nov 19, 2014 at 02:59:01PM -0600, Drake Wilson wrote:
> Summary: I would like to reopen the suggestion to add LUKS partition type codes
> for MBR and for GPT to util-linux's fdisk.  In a previous discussion, it was
> said that since Linux does not interpret partition types, there is no need for
> this, but concrete data loss has now occurred as a result of a related bug in
> other software combined with the lack of a user-visible LUKS type in a similar
> partitioning program, and I believe that warrants re-examination of the situation.

 But it seems that the problem is what details partitioning tools
 provide to end-users rather than problem with data within disk
 labels. I don't see problem to add FS type column to fdisk(s) (it's
 already linked with libblkid).

> I would thus like to re-propose adding a LUKS type.  Alternatively, if a LUKS
> type is still considered a bad idea, I would like to suggest allocating a GPT ID
> analogous to the "da = Non-FS data" MBR type code, which would at least allow the
> user to choose a fallback that has a known null semantic, rather than tagging their
> volumes with some arbitrary ID that may be misinterpreted; that would help avert
> analogous problems for future types as well.

 You want to make a connection between partition type and partition
 format (FS, LUKS, LVM...). This idea is more than 30years old and it
 has been always fragile and introduced for poorly designed systems
 (kernels and boot loaders). 
 
 The current trend is to use partition type to define for what purpose
 we want to use the partition (for example "this is /home")
 independently on partition format. 
 
 For example systemd is able to generate on the fly mount table
 according to GPT partition types (so we have type for root and
 /home). All this is independent on FS/LUKS/etc. The same GUID is for
 XFS, ext4 ... this concept is not compatible with your idea.

 BTW, LUKS (and also XFS) is one of well designed on-disk formats
 where magic string is at the begin of the device, so all you need is
 one seek()+read().

 Anyway, I'd like to minimize number of situations when we depend
 on GPT/MBR partition types at all.

> (I also believe more philosophically that the user should be supported in the
> possibility of integrating with other partition management systems that may wish
> to detect LUKS and do something special with it, without requiring all other such
> systems to incorporate a blkid-like system for checking in several places for the
> "basic nature" of a volume.  I mention this only for the record, since the previous
> thread suggests the util-linux maintainers don't agree with this.)

 This is about partitioning tools, not about on-disk disk label data.


    Karel

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

Re: LUKS partition types, redux

[Drake Wilson]

Firstly: thank you very much for engaging in a reasonable discussion about this.

Karel Zak wrote:
> On Wed, Nov 19, 2014 at 02:59:01PM -0600, Drake Wilson wrote:
>> Summary: I would like to reopen the suggestion to add LUKS partition type codes
>> for MBR and for GPT to util-linux's fdisk.  In a previous discussion, it was
>> said that since Linux does not interpret partition types, there is no need for
>> this, but concrete data loss has now occurred as a result of a related bug in
>> other software combined with the lack of a user-visible LUKS type in a similar
>> partitioning program, and I believe that warrants re-examination of the situation.
> 
>  But it seems that the problem is what details partitioning tools
>  provide to end-users rather than problem with data within disk
>  labels. I don't see problem to add FS type column to fdisk(s) (it's
>  already linked with libblkid).

I don't quite understand the relation of this paragraph to what I was talking
about.  The case of data loss via partman-lvm wasn't related to what fdisk
would have presented to me, but what the disklabel presented to partman-lvm
as a result of the choices fdisk would have presented.

>  You want to make a connection between partition type and partition
>  format (FS, LUKS, LVM...). This idea is more than 30years old and it
>  has been always fragile and introduced for poorly designed systems
>  (kernels and boot loaders). 

It's not quite that I _want_ to make such a connection, more that I think it
has already been made and the current interop situation is suboptimal; see
below.  I would be quite happy as well with a single "Linux other" type
instead of a LUKS-specific type.

>  The current trend is to use partition type to define for what purpose
>  we want to use the partition (for example "this is /home")
>  independently on partition format. 

I can see some of that, yes.  I've only recently encountered this.  This can
somewhat conflict with the purpose of disk encryption, incidentally, which
tends to want to keep those subdivisions hidden if possible (thus LUKS+LVM
being a common setup).  I'm not opposed to the idea being around; _requiring_
it would conflict with my goals, but I don't see any evidence of that, so
let's put that away.

>  Anyway, I'd like to minimize number of situations when we depend
>  on GPT/MBR partition types at all.

So, my more concrete concern here is not in places where Linux or util-linux
read partition type codes; it is where fdisk or a similar utility writes them,
and some other program entirely reads them.  In the bad case I ran into, the
"some other system" happened to be partman-lvm from Debian, but it could just
as well be something else.

Here's the specific scenario: imagine I'm a Linux sysadmin who is writing a
disklabel for a new disk which will contain a LUKS volume.  (The volume does
not necessarily correspond to any of the "usage" types you mentioned, and I
may not want to expose that information anyway.)  The type code field in MBR
or GPT exists already; I cannot simply remove it, and there is no null value.
What value do I type in for that field?

The likely chain of events, if I'm using fdisk or a similar tool, is that I
look up the list of type codes included in that tool and pick the "closest"
one.  If there is no LUKS type, and no "Linux other" or "other" type in
general, I'm likely to wind up picking one of the existing Linux types.
This risks the disk being plugged into a system that misinterprets the type,
because those other types are _notionally_ meaningful even if the core Linux
kernel and utilities don't care much.

Adding a LUKS type to the table means I can pick that, and if Linux, cryptsetup,
etc. never read it, that's fine---the point is that no _other_ system will read
it as something it wasn't meant to be either.  A "Linux other" or "generic /
unspecified" type would also satisfy this, but more weakly because it wouldn't
be as visible (and I would actually love to have all three, honestly).

So it's a combined interop and UI problem, and is related to the disklabel data
itself.  And my main goal in participating here is to help avoid other users
running into similar problems to what I did if they write disklabels using fdisk,
by reducing the risk of accidentally encouraging the user to trigger aggressive
interpretation by other software, even if that other software should not have
made such assumptions in the first place.

Does that help at all?

   ---> Drake Wilson

Re: Bug#770211: LUKS partition types, redux

[Phillip Susi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/23/2014 11:45 PM, Drake Wilson wrote:
> So---entirely aside from the _other_ subthread about types _inside_
> LUKS---do you still intend to provide this as a reason for not
> adding GPT/MBR LUKS types to fdisk, even in light of the
> destructive interaction I mentioned in my first post?  I'm worried
> that my having said anything else while replying to Dale may have
> been a mistake and given the impression that "no types inside LUKS"
> answers my original concern, which it doesn't.
> 
> As I mentioned, GPT and MBR have significant interop
> characteristics with other tools, so I'm not convinced by the
> "Linux only uses blkid" there.  If that's what you're truly going
> with after having seen the practical results, I won't argue
> further, but I'd like to know.

I have to say that adding more type codes for no reason is something
I'm against.  Like you said in your first post, the loss was caused by
a bug in debian-installer coupled with the lvm type code.  If you
simply use the normal "Linux" type code, then everything works out
fine so I don't see any reason to add more complexity and confusion by
introducing yet another type code.  Had the useless lvm type code
never been introduced in a similar manner, you wouldn't have had the
problem you did.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUc0GtAAoJEI5FoCIzSKrwEtkH/iCiZ1Hm4EaBs7btRWD5C0FW
fC363eGKNCK4KsYMPpVv+MjdLy1kwonmmI9OFl+uROdnCaZ2/GzgmynlUtviYl3H
MtXlWEvmJGCT43Qgm97H3OC/3ihJ2epxAP4J5L7gK7fofTq7iqxpk47J1bm2MjUI
XgNMxx31OfQzOtHKZSolJ8wCIC76Zre8tvMjDuGx8AF8JvBnkHpTykWG0B4K3niD
6B5pm/FnSV7t+YoZjkdrJMJsxoZFKU78A1cHeSRuKbXqJVrQXhJbxlcCg21DUGtD
YniJM+W/Cy5KQAh2EfuwMQxkSOXnPTZvSTGdjTserDW5fmdUN2Z7PFlGFOlRZmA=
=Xcjj
-----END PGP SIGNATURE-----

Re: Bug#770211: LUKS partition types, redux

[Drake Wilson]

Phillip Susi wrote:
> I have to say that adding more type codes for no reason is something
> I'm against.  Like you said in your first post, the loss was caused by
> a bug in debian-installer coupled with the lvm type code.  If you
> simply use the normal "Linux" type code, then everything works out

Which "normal" "Linux" type code are you talking about?  The one that's
marked "Linux filesystem"?  That sounds like it's simply shifting the
potential for trouble somewhere else.  The one for "Linux reserved"?
If that's the intent of that one, perhaps it should be clearer that it's
"reserved for user" rather than "reserved for some unknown OS use".  If
there were a "Linux general/other" type code, then I agree that that
would be fine, but I don't see one in the list.

   ---> Drake Wilson

Re: LUKS partition types, redux

[Phillip Susi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/24/2014 6:37 AM, Karel Zak wrote:
> The current trend is to use partition type to define for what
> purpose we want to use the partition (for example "this is /home") 
> independently on partition format.

I wouldn't call this bone headed idea of redhat's a trend.  Using
partition table type codes to decide to auto mount in particular parts
of the filesystem is such a brain damaged idea, those who thought it
up need beaten with a clue-by-four and its use needs to be *strongly*
discouraged.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUc0PqAAoJEI5FoCIzSKrwF3AIAKsduxIzyXOqSlCf0emWc/m3
r/QmAMqyFG5ua1msWmAQaeTTnSFYqwyf4xubIQay8PTd0ruT7Hq/rusu4DCS1aQ1
fecZQhTQi/HHBbZ3mM8w472IB2PM5qDNEDDwZkgbOCpBoEByeZUZFqq+stFSakoD
CHc4sVqHj5FPA3HRq+XuCfqhawc3TcGaO40J0qr0c+7vMm1cAHLIAjifRR8WNrnf
UNk+kDfZJwixaL45t/YcHx001FNJO9Aitj42KV5k4cHke2wAmcmSVj4T9k0NgoCE
TfeDbJrhuQPtJ/V1/oE7q3aH9agppucuEcIjW5Y4ICnqgCeydwlfVfx+FMlVLTk=
=xHEg
-----END PGP SIGNATURE-----

Re: Bug#770211: LUKS partition types, redux

[Phillip Susi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/24/2014 9:37 AM, Drake Wilson wrote:
> Which "normal" "Linux" type code are you talking about?  The one
> that's marked "Linux filesystem"?  That sounds like it's simply
> shifting the potential for trouble somewhere else.  The one for
> "Linux reserved"? If that's the intent of that one, perhaps it
> should be clearer that it's "reserved for user" rather than
> "reserved for some unknown OS use".  If there were a "Linux
> general/other" type code, then I agree that that would be fine, but
> I don't see one in the list.

The one that fdisk identifies as "Linux", i.e. 83.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUc0RuAAoJEI5FoCIzSKrwiMEH/3Njqw51tHDH2Kg3EDKpHfzR
tu5CyfSmuj7e+hnSykvto4zdUly+wCRzIs3ZfhLa/ym1ClJhbOtISagcbv3tc+/C
S80SEU2Hv1uV96yTTo1hd5Hv2kKeWwBTXcPZRW76GddgrSnU6y5kv3yh4pnQNxEV
/wE4TOqXIVa7hg6Yxm45UUP9jRzDm9kgYR+9bva5flqf0Dc+O3P51iKvtLjhuZvA
/LbRIln5fpJeYpxuD/a/BGhGE7jlcTirTobUz/xEuALdDWdGrcIPh2I6DWdCWVh3
aJjr9ZCU7Be1qvMMDOViaWNO6J7ef0AqhjVG/xqteqe3/BaB8srupEXbn62OI2s=
=Un4V
-----END PGP SIGNATURE-----

Re: Bug#770211: LUKS partition types, redux

[Drake Wilson]

Drake Wilson wrote:
> Which "normal" "Linux" type code are you talking about?  The one that's
> marked "Linux filesystem"?
[etc.]

To clarify, that's in the GPT list, not the MBR one.  I see that the MBR one
names 0x83 "Linux", at least.  Does that mean that {0FC63DAF-8483-4772-8E79-3D69D8477DE4}
should also be named "Linux" rather than "Linux filesystem"?

I'm still a little suspicious of this in the context of "all the other Linux
types are more discriminating", but if that's really the "Linux everything-else"
type and _not_ merely the "Linux ext2/XFS/etc./things-that-store-files" type, then
making sure that's documented somewhere everyone can see suffices for me (and a
rename in the list is probably enough for that, assuming the more specific
backcompat case of "someone already made this assumption" (rather than "someone
may assume this in the future") is narrow enough that it can be ignored).

   ---> Drake Wilson

Re: Bug#770211: LUKS partition types, redux

[Phillip Susi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/24/2014 9:48 AM, Drake Wilson wrote:
> To clarify, that's in the GPT list, not the MBR one.  I see that
> the MBR one names 0x83 "Linux", at least.  Does that mean that
> {0FC63DAF-8483-4772-8E79-3D69D8477DE4} should also be named "Linux"
> rather than "Linux filesystem"?

Oh boy.  I hadn't noticed that util-linux had added so many silly type
codes now that it supports GPT.  This mess really needs cleaned up.
There should just be "Linux" and that's it.  That's the only one we
have in parted and it is quite sufficient.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUc0ehAAoJEI5FoCIzSKrwiGoIAIksu6+umL4VfaE6UWr/5LCP
Td+rMenz/IosGo1cn602SKbTewNyMzZ3T5RJnTY5dVHt7aWMJGtKMtZ4GavHnttL
nV8yZvXcv7JGmvOtZiu0zK1V/WUxrQY0KaUd2wjtYUOkCpuHRaj5wkk7erarGZIt
Z1OgVfXfOEfVjC4jf1rbnOQib53azceVgge6knI8uHAq7qONdzCX588xAypz2Vok
t08LalysnVqckuhwsbFzWvUblMfelnI0qhGp/GwkT2s/cRuLlGf28yAyq73/bbaw
zHDbZg8PbehyHwoBjPiVA1bNAg7sVrXQV4TJSrddo0UosgqpxXHE7B3+sEa3rOg=
=3Gq7
-----END PGP SIGNATURE-----

Re: Bug#770211: LUKS partition types, redux

[Drake Wilson]

Phillip Susi wrote:
> Oh boy.  I hadn't noticed that util-linux had added so many silly type
> codes now that it supports GPT.  This mess really needs cleaned up.
> There should just be "Linux" and that's it.

I'd be fine with everything getting merged into a single "Linux" type.

If that happens, would it make sense to get rid of the listings for the
other Linux types in MBR mode too and loosely standardize on all 0x83
types there?  (Or interpret them for existing disklabels, and of course
don't forbid setting them, but remove them from the actively-displayed
list.)

> That's the only one we
> have in parted and it is quite sufficient.

In parted, really?  While I was chasing down the partman-lvm data flow
involved, it seemed to me that it was libparted that was setting flags
based on interpreting the LVM GPT type, which were later getting interpreted;
it wasn't obvious to me where to break the logic chain.  Is that part of
libparted a Debianism, or did you mean parted-the-tool as opposed to
libparted-the-library, or... ?

   ---> Drake Wilson

Re: Bug#770211: LUKS partition types, redux

[Phillip Susi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/24/2014 10:04 AM, Drake Wilson wrote:
> In parted, really?  While I was chasing down the partman-lvm data
> flow involved, it seemed to me that it was libparted that was
> setting flags based on interpreting the LVM GPT type, which were
> later getting interpreted; it wasn't obvious to me where to break
> the logic chain.  Is that part of libparted a Debianism, or did you
> mean parted-the-tool as opposed to libparted-the-library, or... ?

Ahh, I forgot about that.  I never use it and there's no reason to,
but it was added, probably to maintain parity with MBR, which already
had an lvm type code as well.  Now that I check the code it does also
have raid and swap for similar reasons and they are equally useless.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUc0pDAAoJEI5FoCIzSKrw+08H+QG9SO+aD0Zc2fmzZj+RpQr7
95TtewhPkd56MmhxNPkn2IFKd7wwnm/fqutwW8UwTTrJPiPOF3csq4ugyC35t9hZ
tY9xgjw0YwSKa3yAKVzGkdKpO09vtinQWmOMtGdk8uiBpM1vehIM84Vpi3HQuLuL
IUCsFl/y2fhFIq1Ol8bcnaEtz4YVBpQBRIPPxivEXrehIOvBcZFZsc6i/hZsquw5
oP2qUs65t7sTgTKVC/vmINZz5MQx/wSMwVC2/6KivvN0SbRebrJ7wOxesJFR5t6c
25Rf2Q/wSomBqhgbKBgSenPbXGORFMsogLXFtfkk8JHY/tfMr1lunmu1oOOefis=
=ztuu
-----END PGP SIGNATURE-----

Re: LUKS partition types, redux

[Karel Zak]

On Mon, Nov 24, 2014 at 09:42:50AM -0500, Phillip Susi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 11/24/2014 6:37 AM, Karel Zak wrote:
> > The current trend is to use partition type to define for what
> > purpose we want to use the partition (for example "this is /home") 
> > independently on partition format.
> 
> I wouldn't call this bone headed idea of redhat's a trend.  Using
> partition table type codes to decide to auto mount in particular parts
> of the filesystem is such a brain damaged idea, those who thought it
> up need beaten with a clue-by-four and its use needs to be *strongly*
> discouraged.

 well, it's designed for auto-generated fstab-less systems like
 containers/virt images, etc. I'm not big fan of this feature, but for
 some use cases it makes sense. (And it's systemd upstream decision.)

 Anyway, use partition type for "usage" makes more sense than for "fs-type".

    Karel

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

Re: LUKS partition types, redux

[Dale R. Worley]

> From: Phillip Susi <psusi@ubuntu.com>
> 
> On 11/24/2014 6:37 AM, Karel Zak wrote:
> > The current trend is to use partition type to define for what
> > purpose we want to use the partition (for example "this is /home") 
> > independently on partition format.
> 
> I wouldn't call this bone headed idea of redhat's a trend.  Using
> partition table type codes to decide to auto mount in particular parts
> of the filesystem is such a brain damaged idea, those who thought it
> up need beaten with a clue-by-four and its use needs to be *strongly*
> discouraged.

I have to agree here.  Trying to use partition type codes to specify
where partitions should be mounted has many flavors of fail.  Among
others, it assumes that there is a small, fixed set of mount points
that will *work for every installation*.  If you want to know what
gets mounted where, look in /etc/fstab, like we've done for 40 years
or so.

Dale

Re: Bug#770211: LUKS partition types, redux

[Karel Zak]

On Mon, Nov 24, 2014 at 09:58:41AM -0500, Phillip Susi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 11/24/2014 9:48 AM, Drake Wilson wrote:
> > To clarify, that's in the GPT list, not the MBR one.  I see that
> > the MBR one names 0x83 "Linux", at least.  Does that mean that
> > {0FC63DAF-8483-4772-8E79-3D69D8477DE4} should also be named "Linux"
> > rather than "Linux filesystem"?
> 
> Oh boy.  I hadn't noticed that util-linux had added so many silly type
> codes now that it supports GPT.  This mess really needs cleaned up.

 Well, UEFI standard defines only 3 partition type GUIDs, the rest is vendor 
 specific ..  so there is huge area for human creativity :-) 
 
 The initial source for fdisk was
    http://en.wikipedia.org/wiki/GUID_Partition_Table
 and extended by stuff from free desktop
    http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/

 (Hmm.. someone already added dm-crypt and LUKS specific GUIDs to
  wikipedia.)

> There should just be "Linux" and that's it.  That's the only one we
> have in parted and it is quite sufficient.

 and also RAID and LVM ;-)


    Karel

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

Re: Bug#770211: LUKS partition types, redux

[Phillip Susi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/24/2014 11:10 AM, Karel Zak wrote:
> and extended by stuff from free desktop 
> http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/

Yes...
> 
that spec is awful and needs to die in a fire.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUc1xrAAoJEI5FoCIzSKrw7tQH/2V08mrXE702aFdMQSwaJd9q
z1QxTuKExES5z7tKW2KhIAhHj7aDCwnNf2596acifwDBzYnoiDKMXOEnM8jxPJUa
sDFblmWtVw5DTpkhtxcoZGxPgm72io6fas/2EobK3T8hFqHSMnzhwKpUvj41Svbu
NwBX43EMcLBxKWwpcCgxQmW5Lz4ceC+NTqGCsY8nKxgeyG6Xzs7Og7DsQ59DJ1wd
si+k3spJVOYj5H/9ccwMA+7+UjnRgVeNUJ4AQl1lXSpXcabFxTRSI2nloU8HGxma
N+GrS7yoZrNAwc41ggMqzDw29qSYPDhJkxUN93GdW55I0GgT7mMtUXgxOY+88ec=
=+y7Q
-----END PGP SIGNATURE-----

Re: LUKS partition types, redux

[Bruce Dubbs]

Karel Zak wrote:
> On Mon, Nov 24, 2014 at 09:42:50AM -0500, Phillip Susi wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 11/24/2014 6:37 AM, Karel Zak wrote:
>>> The current trend is to use partition type to define for what
>>> purpose we want to use the partition (for example "this is /home")
>>> independently on partition format.
>>
>> I wouldn't call this bone headed idea of redhat's a trend.  Using
>> partition table type codes to decide to auto mount in particular parts
>> of the filesystem is such a brain damaged idea, those who thought it
>> up need beaten with a clue-by-four and its use needs to be *strongly*
>> discouraged.
>
>   well, it's designed for auto-generated fstab-less systems like
>   containers/virt images, etc. I'm not big fan of this feature, but for
>   some use cases it makes sense. (And it's systemd upstream decision.)
>
>   Anyway, use partition type for "usage" makes more sense than for "fs-type".

Since when is systemd upstream of util-linux?

   -- Bruce

Re: LUKS partition types, redux

[Karel Zak]

On Mon, Nov 24, 2014 at 01:56:51PM -0600, Bruce Dubbs wrote:
> Karel Zak wrote:
> >On Mon, Nov 24, 2014 at 09:42:50AM -0500, Phillip Susi wrote:
> >>-----BEGIN PGP SIGNED MESSAGE-----
> >>Hash: SHA1
> >>
> >>On 11/24/2014 6:37 AM, Karel Zak wrote:
> >>>The current trend is to use partition type to define for what
> >>>purpose we want to use the partition (for example "this is /home")
> >>>independently on partition format.
> >>
> >>I wouldn't call this bone headed idea of redhat's a trend.  Using
> >>partition table type codes to decide to auto mount in particular parts
> >>of the filesystem is such a brain damaged idea, those who thought it
> >>up need beaten with a clue-by-four and its use needs to be *strongly*
> >>discouraged.
> >
> >  well, it's designed for auto-generated fstab-less systems like
> >  containers/virt images, etc. I'm not big fan of this feature, but for
> >  some use cases it makes sense. (And it's systemd upstream decision.)
> >
> >  Anyway, use partition type for "usage" makes more sense than for "fs-type".
> 
> Since when is systemd upstream of util-linux?

 Ah.. freedesktop guys introduced some new GUID and util-linux project
 has accepted these identifiers (rather than interpret these IDs as
 "unknown") ...  as well as we accepted partition IDs for Apple stuff,
 as well as we accepted Hurd patches, ports to freebsd, uClibc,
 not-perfect zram stuff from kernel, stuff from SysVinit, and many
 many many other things.

 I don't plan to be censor for another projects and apply any
 emotional criteria. The reason why this project still alive is that
 we are very friendly to arbitrary distributions and another projects. 

    Karel

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

Re: Bug#770211: LUKS partition types, redux

[Dale R. Worley]

> From: Karel Zak <kzak@redhat.com>

>  Well, UEFI standard defines only 3 partition type GUIDs, the rest is vendor 
>  specific ..  so there is huge area for human creativity :-) 

At least there's no risk we'll run out of partition type codes!

Dale

Re: LUKS partition types, redux

[Dale R. Worley]

> From: Karel Zak <kzak@redhat.com>

>  well, it's designed for auto-generated fstab-less systems like
>  containers/virt images, etc. I'm not big fan of this feature, but for
>  some use cases it makes sense.

I thought that's what filesystem "label" values were for.

>  (And it's systemd upstream decision.)

I've never run into something from systemd that I didn't consider
bizarre and horrible, designed to solve problems I don't have at the
cost of making my life worse.

Dale

Re: LUKS partition types, redux

[Bruce Dubbs]

Karel Zak wrote:
> On Mon, Nov 24, 2014 at 01:56:51PM -0600, Bruce Dubbs wrote:
>> Karel Zak wrote:
>>> On Mon, Nov 24, 2014 at 09:42:50AM -0500, Phillip Susi wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> On 11/24/2014 6:37 AM, Karel Zak wrote:
>>>>> The current trend is to use partition type to define for what
>>>>> purpose we want to use the partition (for example "this is /home")
>>>>> independently on partition format.
>>>>
>>>> I wouldn't call this bone headed idea of redhat's a trend.  Using
>>>> partition table type codes to decide to auto mount in particular parts
>>>> of the filesystem is such a brain damaged idea, those who thought it
>>>> up need beaten with a clue-by-four and its use needs to be *strongly*
>>>> discouraged.
>>>
>>>   well, it's designed for auto-generated fstab-less systems like
>>>   containers/virt images, etc. I'm not big fan of this feature, but for
>>>   some use cases it makes sense. (And it's systemd upstream decision.)
>>>
>>>   Anyway, use partition type for "usage" makes more sense than for "fs-type".
>>
>> Since when is systemd upstream of util-linux?
>
>   Ah.. freedesktop guys introduced some new GUID and util-linux project
>   has accepted these identifiers (rather than interpret these IDs as
>   "unknown") ...  as well as we accepted partition IDs for Apple stuff,
>   as well as we accepted Hurd patches, ports to freebsd, uClibc,
>   not-perfect zram stuff from kernel, stuff from SysVinit, and many
>   many many other things.
>
>   I don't plan to be censor for another projects and apply any
>   emotional criteria. The reason why this project still alive is that
>   we are very friendly to arbitrary distributions and another projects.

I have not problem with that.  I just don't want to see a hard 
dependency on systemd like other projects have done.  There are a lot of 
projects that are mutually dependent, but the term upstream sounded some 
alarm bells for me.

I do think util-linux is managed in an excellent way.

   -- Bruce