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.ca...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
