[Parted-maintainers] Bug#504099: gnu-fdisk: fails to display GPT partition properly

[Christoph Anton Mitterer]

severity 504099 critical
stop

Hi.

I can't quite understand why you've lowered the severity of this, as
this is really critical and has easily the potential to destroy all
data.

It's even more critical that gnu fdisk makes itself the default fdisk
over the utillinux one (which at least detects GPT and warns)... why
don't you use the alternatives mechanism?!


Anyway... GNU fdisk fails even more than not just understanding GPT or
at least warn that GPT is in place... it also seems to detect completely
bogus MBR data:
GNU Fdisk
     Device Boot      Start         End      Blocks   Id  System 
/dev/loop0p1   *          17        7808      499440   83  Linux 
/dev/loop0p2            7809   167755808 10735871936   83  Linux 
/dev/loop0p3       167755809   167772144     1045440   82  Linux Swap /
Solaris 


But the MBR of a GPT contains (per default) only one overall partition
of type EE... so called protective MBR.

utillinux fdisk shows at least this correctly.
      Device Boot      Start         End      Blocks   Id  System
/dev/loop0p1               1  4294967295  2147483647+  ee  GPT



I'm raising the severity (critical - "makes unrelated software on the
system (or the whole system) break, or causes serious data loss") again,
as users should be warned by this (apt-listbugs)... since every (write)
operation with GNU fdisk on a GPT system will most likely destroy
everything on it.


Having a GPT is not even unlikely... at least the Debian wheezy
installer already creates them for HDDs that needs it (i.e. all HDDs > 2
TB)... and these are more or less standard nowadays.


I guess no one demands that GNU-fdisk is able to create/modify GPTs...
but it should correctly identify the protective MBR... and if found
never write anything.
Actually it should generally assume a GPT in place, if any partition in
the MBR with type EE is found...
While the GPT specification demands that there is only one! overall!
partition with type EE... there are setups with hybrid GPT/MBR where
this is not the case... therefore... better assume GPT if any EE type
partition is found.



Cheers,
Chris.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5165 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/parted-maintainers/attachments/20130629/b3c5422e/attachment.bin>