Thanks for your report.

You're misinterpreting the final column -- the one you claim should contain the string "Linux LVM". That column contains the GPT partition name data. See http://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_entries; it's the final (72-byte) entry in the "GUID partition entry format" table. GPT fdisk will set this value to something descriptive of the partition type when it CREATES a new entry, and it will change the name to something descriptive when changing the type code IF the original value matches its own internal description. When reading an existing partition table, though, gdisk simply reads what's there and displays it. Thus, if the partition table was created by a tool that doesn't set this field (or more precisely, sets it to a null string), gdisk shows nothing in that column. You can change it to whatever you like by using the "c" option on the main menu.

Thanks for the explanation, Rod Smith. Then perhaps this is a bug or a missing feature of fdisk.

Linux fdisk was designed for MBR partition tables, which don't support partition names, so it doesn't present them on MBR disks; instead, it presents a description of the partition based on the type code. When I wrote gdisk, I tried to replicate the fdisk user interface as much as possible, but fitting both a type-code-based description and a name on a single line would have resulted in a cramped display and probable truncation of one or both fields, so I opted to show the name alone, instead relying exclusively on the type code field to convey type code information. Both my cgdisk and the latest version of fdisk present both a description and a name on a single line for GPT disks, but one or both is likely to be truncated. None of these conditions constitutes a bug. You could argue that omitting one piece of information or another is a missing feature, but the fact is that there's enough information to be presented that it won't all fit completely on one line, so some sort of compromise is required. As shown on the GPT Wikipedia page (http://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_entries), GPT partition entries are 128 bytes in length. Even compressing the 72 bytes for the name to 36 characters (since it's encoded in UTF-16), it would take a 100-character line to display all that information -- and that's without spacing between elements and other human formatting niceties. If you compare gdisk, cgdisk, the latest fdisk, and parted, you'll see that each program omits certain pieces of information from its default display. (All also display additional information, such as partition number, partition size, or the filesystem that's ACTUALLY in the partition, as opposed to the type code.) Both gdisk and cgdisk enable you to see all the information on a partition stored in the data structure via the "information" ("i") option, but that takes EIGHT LINES to summarize (with English labels).

Any of these programs is adequate for casual use, but if you need access to particular information, it behooves you to understand both the GPT data structures themselves and what information from those data structures (and from elsewhere) each program displays and enables you to change. Similar comments apply to MBR, but as MBR is simpler and as both fdisk and parted were designed first for MBR, there are fewer compromises in these programs' MBR support.

I understood the limitations of the display the first time, I was only
trying to say that fdisk could set that field when creating or toggling
the type of a partition, so that users of gdisk would see something. The
GUID or even better the content is what matters in the end, but it's
nevertheless nice to also have a human readable description.

Anyway, sorry for the false alarm and thank you for the i command hint.
I shall also update bug #1056375 which is related to fdisk.

Ah, yes, I see what you're saying. Yes, having some sort of description in the name field is desirable, no matter what tool you use to create the partition. Filing a request for this feature against a program that doesn't do so is certainly reasonable.

For your information I've reported bug #1057894.