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

Tue Nov 29 07:38:30 UTC 2016

Am 28.11.2016 um 20:53 schrieb Tito:
> On 11/28/2016 05:42 PM, Simon Rettberg wrote:
>> 27.11.2016, 20:24 +0200, Denys Vlasenko <vda.linux at googlemail.com>:
>>
>>> 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

>
> Ciao,
> Tito
>
>>> 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
>> busybox at busybox.net
>> http://lists.busybox.net/mailman/listinfo/busybox
>>
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox

-- 
Mattias Schlenker - Freier IT-Fachredakteur und -autor
                              redaktion at mattiasschlenker.de
Mattias Schlenker - IT-Consulting, Softwareentwicklung
                             consulting at mattiasschlenker.de

Address__ August-Bebel-Str. 74 - D-04275 LEIPZIG - GERMANY
Phone: +49 341 39290767              Fax: +49 341 30393578
Mobile: +49 163  6953657  Another mobile: +49 159 03160327
VATIN_________________________________________ DE240998538

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