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

[Brian C. Lane]

On Sat, Dec 28, 2019 at 10:18:40PM +0000, Jason Mancini wrote:
> Install Windows to a 1TB drive but only partition the first 63GB.  Most of 
> the disk is empty.
> 
> Clone the first 63GB to a 512GB drive.  This misses the trailing GPT table.  
> Windows will boot and run fine.  Windows Disk Management is happy.
> 
> But no Linux partitioning tool will touch this disk, or see any partitions.  
> I suspect they all die on the first table's pointer-to-backup that goes past 
> the end of the disk.
> 
> The situation is easy to correct from within Windows, simply add and delete a 
> partition without assigning a drive letter or formatting.  It rewrites both 
> tables correctly.  But this is dependent on having free space to add a 
> partition.  And dependent on booting Windows.
> 
> Can we improve things on the non-Windows side of the tools?  There seems to 
> be no tool that can be manually directed to only use the first or second 
> table.

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