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

From: Jason Mancini <[email-masked]>
Date: Mon, 6 Jan 2020 23:00:03 +0000

> 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