[PATCH] fdisk: Add support for GPT partition type codes

[Simon Rettberg]

Now that I needed to get the type codes of GPT partitions in a script I
decided to add this functionality to busybox fdisk, which had a big
FIXME in the code and just printed 0700 for every partition (and gave me
some headache before I realized this).
Since this adds a big lookup table I made this feature optional and off by
default.
With feature enabled:

function old new delta
.rodata 82378 83602 +1224
static.list_table 1268 1381 +113
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 2/0 up/down: 1337/0) Total: 1337
bytes
text data bss dec hex filename
543392 3899 1920 549211 8615b busybox_old
544729 3899 1920 550548 86694 busybox_unstripped

This also changes the format-specifier from %04x to %04X since, as far as
I can tell, the output format is based on that of gdisk, which also uses
uppercase letters for the type code.

I have some doubt that printing 0700 if this feature is disabled is the
best choice, as this could mislead others as well. Maybe using FFFF
(=unknown GUID type code) or just printing '-' or '?' would make more
sense, but I didn't dare to change this for the sake of backwards
compatibility.

Lastly, I added the embarrassing one-liner I used for creating the lookup
table as a comment, to document where the values come from and make it
easier to update the list in the future. In case this breaks any style
guidelines it might be preferable to move this to some readme file or even
create a more readable external script that does all the magic.

- Simon

[Denys Vlasenko]

On Thu, Nov 17, 2016 at 8:28 PM, Simon Rettberg

Post by Simon Rettberg
Now that I needed to get the type codes of GPT partitions in a script I
decided to add this functionality to busybox fdisk, which had a big
FIXME in the code and just printed 0700 for every partition (and gave me
some headache before I realized this).

Unfortunately I don't have GUID partitioned disks.

I looked at these "type codes of GPT partitions" and they seem to be
a figment of imagination of "GPT fdisk" people: they are not stored on disk,
fdisk authors just assigned them to some GUIDs.

How do you find them useful?

[Jody Bruchon]

Post by Denys Vlasenko
I looked at these "type codes of GPT partitions" and they seem to be
a figment of imagination of "GPT fdisk" people: they are not stored on disk,
fdisk authors just assigned them to some GUIDs.
How do you find them useful?

I use gptfdisk tools for disk imaging and information scripts. The
made-up partition types from gptfdisk are an extremely handy mnemonic
device because I can actually remember them and they make for cleaner
code that has to embed these known GUIDs. Off the top of my head, I know
that 0700 is "Microsoft basic data", af00 is "Apple HFS+", ef00 is "EFI
system", and IIRC af01 is "Apple Core Storage." If you asked me to tell
you the corresponding GUIDs, I have no clue at all. The usefulness is
like programming in assembly instead of banging in raw hex codes.

On a somewhat related note, I have started working on implementing the
'-t' switch in fdisk; having BB fdisk automatically pick my GPT
partition table makes me unable to use fdisk to modify the protective MBR.

-Jody

[Denys Vlasenko]

Post by Denys Vlasenko
I looked at these "type codes of GPT partitions" and they seem to be
a figment of imagination of "GPT fdisk" people: they are not stored on disk,
fdisk authors just assigned them to some GUIDs.
How do you find them useful?

I use gptfdisk tools for disk imaging and information scripts. The made-up
partition types from gptfdisk are an extremely handy mnemonic device because
I can actually remember them and they make for cleaner code that has to
embed these known GUIDs.
Off the top of my head, I know that 0700 is
"Microsoft basic data", af00 is "Apple HFS+", ef00 is "EFI system", and IIRC
af01 is "Apple Core Storage." If you asked me to tell you the corresponding
GUIDs, I have no clue at all. The usefulness is like programming in assembly
instead of banging in raw hex codes.

Makes sense.

However, I still don't understand how do you use them,
apart from seeing them on output.

On a somewhat related note, I have started working on implementing the '-t'
switch in fdisk; having BB fdisk automatically pick my GPT partition table
makes me unable to use fdisk to modify the protective MBR.

Is your work available somewhere?

I am happy to accept patches from people who are actually using the tool
they are patching - they are "scratching the itch" which exists in
real-world usage.

From your description, you are doing that right now.

When you send a patch, add a bit of background why do you need this change,
and if there were other solutions which at first looked better, but then proved
non-workable, mention those too.

For example, before I saw your email, I looked at fdisk_gpt.c and decided
to simply delete "Code" column on the output. I take it this is not a good idea?
Why?

[Simon Rettberg]

Post by Denys Vlasenko
However, I still don't understand how do you use them,
apart from seeing them on output.

That's pretty much it. Following the same line of argument, you could
ask why we have this table in fdisk.c that maps the MBR type ids
to their names. They also do nothing except for showing up in the
output.

Plus, in case bb fdisk will get write support for GPT one day, the
table would be even more useful, since you usually just enter the type
code in existing GPT editing tools, instead of the full GUID. The
utility then just maps the short type code back to the long GUID when
writing.

Actually, the type codes of GPT are based on the type ids from MBR,
so for example HPFS/NTFS is 07 for MBR and 0700 for GPT, Linux Swap
is 82 for MBR, 8200 for GPT.

Post by Denys Vlasenko
When you send a patch, add a bit of background why do you need this change,
and if there were other solutions which at first looked better, but then proved
non-workable, mention those too.
For example, before I saw your email, I looked at fdisk_gpt.c and
decided to simply delete "Code" column on the output. I take it this
is not a good idea?
Why?

Alright, so as mentioned above, those type codes are almost exclusively
used when humans are dealing with GPT partitions in any way.

Not supporting them in busybox would not mean the end of the world; we
could still do everything by reading (and some day writing) type GUIDs
directly, at the expense of having to look them up manually every time,
unless you can memorize them.

As for removing the column: I saw that the formatting of the output
looks exactly like that of gdisk, so I assumed the original author
of fdisk_gpt.c decided that it would be better to print a dummy
value than not having the column at all.
I can't speak for the rest of the world, but I don't care about that
output format compatibility, so I would be fine with not having that
column instead of printing a misleading dummy value; it might
actually be the more reasonable choice, since it had me confused for
a while before checking the source. A new column showing the GUID
directly would be ok with me. I would change my scripts and add a
lengthy comment, probably.
But showing neither the short code nor the GUID does render the output
somewhat useless, just as if MBR mode would not print the type id.

[Tito]

Post by Simon Rettberg

Post by Denys Vlasenko
However, I still don't understand how do you use them,
apart from seeing them on output.

That's pretty much it. Following the same line of argument, you could
ask why we have this table in fdisk.c that maps the MBR type ids
to their names. They also do nothing except for showing up in the
output.
Plus, in case bb fdisk will get write support for GPT one day, the
table would be even more useful, since you usually just enter the type
code in existing GPT editing tools, instead of the full GUID. The
utility then just maps the short type code back to the long GUID when
writing.
Actually, the type codes of GPT are based on the type ids from MBR,
so for example HPFS/NTFS is 07 for MBR and 0700 for GPT, Linux Swap
is 82 for MBR, 8200 for GPT.

Hi,
one stupid question, could the 2 tables be merged or reused in some way
as they share related values (e.g. 82 and 8200)?

Ciao,
Tito

Post by Simon Rettberg

Post by Denys Vlasenko
When you send a patch, add a bit of background why do you need this change,
and if there were other solutions which at first looked better, but then proved
non-workable, mention those too.
For example, before I saw your email, I looked at fdisk_gpt.c and
decided to simply delete "Code" column on the output. I take it this
is not a good idea?
Why?

Alright, so as mentioned above, those type codes are almost exclusively
used when humans are dealing with GPT partitions in any way.
Not supporting them in busybox would not mean the end of the world; we
could still do everything by reading (and some day writing) type GUIDs
directly, at the expense of having to look them up manually every time,
unless you can memorize them.
As for removing the column: I saw that the formatting of the output
looks exactly like that of gdisk, so I assumed the original author
of fdisk_gpt.c decided that it would be better to print a dummy
value than not having the column at all.
I can't speak for the rest of the world, but I don't care about that
output format compatibility, so I would be fine with not having that
column instead of printing a misleading dummy value; it might
actually be the more reasonable choice, since it had me confused for
a while before checking the source. A new column showing the GUID
directly would be ok with me. I would change my scripts and add a
lengthy comment, probably.
But showing neither the short code nor the GUID does render the output
somewhat useless, just as if MBR mode would not print the type id.
_______________________________________________
busybox mailing list
http://lists.busybox.net/mailman/listinfo/busybox

[Mattias Schlenker]

Post by Tito

Post by Simon Rettberg

Post by Denys Vlasenko
However, I still don't understand how do you use them,
apart from seeing them on output.

That's pretty much it. Following the same line of argument, you could
ask why we have this table in fdisk.c that maps the MBR type ids
to their names. They also do nothing except for showing up in the
output.
Plus, in case bb fdisk will get write support for GPT one day, the
table would be even more useful, since you usually just enter the type
code in existing GPT editing tools, instead of the full GUID. The
utility then just maps the short type code back to the long GUID when
writing.
Actually, the type codes of GPT are based on the type ids from MBR,
so for example HPFS/NTFS is 07 for MBR and 0700 for GPT, Linux Swap
is 82 for MBR, 8200 for GPT.

Hi,
one stupid question, could the 2 tables be merged or reused in some way
as they share related values (e.g. 82 and 8200)?

During the last weeks I did some tests on dual MBR and GPT partition
tables, mainly for building bootable USB thumb drives taht have one
partition visible and usable under Windows.

If the drive is less than 2TB and four partitions or less are used, it
is very easy to use dual partition tables. If more partitions are used
or some partitions should only be visible on MBR and others on GPT it
gets tricky: Linux for example expects the protective partition to start
at the second block, no matter how big the protective partition is and
how many partitions follow. If this is the case Linux uses the GPT and
ignores the rest of the MBR. Windows however expects a protective
partition that spans the whole disk, otherwise it will use the MBR. So
if you insert a USB drive with a small protective partition into
Windows, Windows will prompt you to format the (unknown) partition. Only
OS X ignores any MBR partitioning if a GPT is present.

So while theoretically interesting, in practice it does not make sense
to sync partition tables. Use GPT on any linux only system (also makes
sense on BIOS, albeit a bit more work to boot from), use GPT on any
external media. Use GPT on any UEFI system as boot media, and only use
MBR on drives with less than 2TB that should boot windows on BIOS (64
bit windows 7 and up should be possible to boot from GPT on BIOS - I did
not yet test).

Yours,
Mattias

Post by Tito
Ciao,
Tito

Post by Simon Rettberg

Post by Denys Vlasenko
When you send a patch, add a bit of background why do you need this change,
and if there were other solutions which at first looked better, but then proved
non-workable, mention those too.
For example, before I saw your email, I looked at fdisk_gpt.c and
decided to simply delete "Code" column on the output. I take it this
is not a good idea?
Why?

Alright, so as mentioned above, those type codes are almost exclusively
used when humans are dealing with GPT partitions in any way.
Not supporting them in busybox would not mean the end of the world; we
could still do everything by reading (and some day writing) type GUIDs
directly, at the expense of having to look them up manually every time,
unless you can memorize them.
As for removing the column: I saw that the formatting of the output
looks exactly like that of gdisk, so I assumed the original author
of fdisk_gpt.c decided that it would be better to print a dummy
value than not having the column at all.
I can't speak for the rest of the world, but I don't care about that
output format compatibility, so I would be fine with not having that
column instead of printing a misleading dummy value; it might
actually be the more reasonable choice, since it had me confused for
a while before checking the source. A new column showing the GUID
directly would be ok with me. I would change my scripts and add a
lengthy comment, probably.
But showing neither the short code nor the GUID does render the output
somewhat useless, just as if MBR mode would not print the type id.
_______________________________________________
busybox mailing list
http://lists.busybox.net/mailman/listinfo/busybox

_______________________________________________
busybox mailing list
http://lists.busybox.net/mailman/listinfo/busybox

--
Mattias Schlenker - Freier IT-Fachredakteur und -autor
***@mattiasschlenker.de
Mattias Schlenker - IT-Consulting, Softwareentwicklung
***@mattiasschlenker.de

Address__ August-Bebel-Str. 74 - D-04275 LEIPZIG - GERMANY
Phone: [phone] Fax: [phone]
Mobile: [phone] Another mobile: [phone]
VATIN_________________________________________ DE240998538

Fork me!____________________ https://github.com/mschlenker
Website.__________________ http://www.mattiasschlenker.de/
My books!___________ http://www.arduino-hausautomation.de/

[James Bowlin]

Use GPT on any UEFI system as boot media, and only use MBR on
drives with less than 2TB that should boot windows on BIOS (64
bit windows 7 and up should be possible to boot from GPT on
BIOS - I did not yet test).

Aside from size constraints, etc, all four combinations work:

o UEFI booting on GPT partitioning
o UEFI booting on MSDOS partitioning
o Legacy booting on GPT partitioning
o Legacy booting on MSDOS partitioning

For example, my live-usb-maker script:
https://github.com/BitJam/live-usb-maker boots via both legacy
and UEFI and it can be set to partition with GPT or MSDOS.


Peace, James

[Mattias Schlenker]

Post by James Bowlin
o UEFI booting on GPT partitioning
o UEFI booting on MSDOS partitioning
o Legacy booting on GPT partitioning
o Legacy booting on MSDOS partitioning
https://github.com/BitJam/live-usb-maker boots via both legacy
and UEFI and it can be set to partition with GPT or MSDOS.

In theory they work and in practice in 99% of the cases when booting
internal hard drives. My preferred boot configuration on all PC systems
are GPT partitioned drives with a partition markes EFI system and one
marked legacy boot (might apply to the same partition) and using
gptmbr.bin from syslinux to boot.

In practice there are some early EFIs (ca. 2007 to 2010) that are
disguised as BIOS that ignore the 448 byte boot block on USB drives and
instead look for a MBR partition table and one partition marked as
active. Because of the protective MBR they won't boot a GPT partitioned
stick. Something similar applies to many 32 bit UEFIs (cheap Intel
tablets and netbooks). To boot from external media those expect a single
partition drive, MBR partition table and the partition flagged as (EFI
system partition) containing all the boot files. This might violate the
UEFI standards, but I guess since Windows bootable USB drives use
exactly this single partition MBR layout, no one cares in practice.

Yours,
Mattias
--
Mattias Schlenker - Freier IT-Fachredakteur und -autor
***@mattiasschlenker.de
Mattias Schlenker - IT-Consulting, Softwareentwicklung
***@mattiasschlenker.de

Address__ August-Bebel-Str. 74 - D-04275 LEIPZIG - GERMANY
Phone: [phone] Fax: [phone]
Mobile: [phone] Another mobile: [phone]
VATIN_________________________________________ DE240998538

Fork me!____________________ https://github.com/mschlenker
Website.__________________ http://www.mattiasschlenker.de/
My books!___________ http://www.arduino-hausautomation.de/