bug#38783: GPT case that parted can't handle

[Jason Mancini]

> It's certainly possible. But some things to consider:
> 
>  * In commit 7f753b1b0505b Jim mentions that the spec calls this
>    situation an invalid GPT partition. But I'm not sure I agree after
>    reading over section 5.3.2 a few times.
> 
>  * If parted does create a new backup table it needs to make sure that
>    the end of the last partition doesn't interfere with it.
> 
>  * looking at some of the code, things like _parse_header are written to
>    support growing the disk, but will fail on one that has shrunk.
> 
> Given the amount of work that would be needed to support this, and that
> this is a corner case I don't think it's something I want to tackle.
> Really, you shouldn't be copying pieces of disks around. Make a new
> partition and copy the data -- it's safer that way.
> 
> -- 
> Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart

This works perfectly with MBR.  It's too bad that such drive mirroring 
functionality is lost moving to GPT, where the target disk is slightly smaller, 
but the partitions don't reach that far.  I can make due with gdisk (or 
manually editing the header + recalc crc32).  But know that Windows boots and 
runs fine, while basically any Linux installer will overwrite what's on the 
disk.  I think that if Windows and gparted can handle the situation, 
fdisk/cfdisk/parted/gparted could too.  End users see conflicting GPT 
interpretation from multiple tools.  It behooves us to handle obscure corner 
case conditions as well as possible.  You never know when someone just might 
recover some data because of it.  I think it's regretful that a dual-header GPT 
is less robust than MBR in this case.  Surely that was never the intention.
Jason