GNU bug report logs -
#38783
GPT case that parted can't handle
Previous Next
Full log
View this message in rfc822 format
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
This bug report was last modified 5 years and 163 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.