GNU bug report logs - #38783
GPT case that parted can't handle

Previous Next

To reply to this bug, email your comments to 38783 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jason Mancini <jayrusman <at> hotmail.com>
To: "bug-parted <at> gnu.org" <bug-parted <at> gnu.org>
Subject: GPT case that parted can't handle
Date: Sat, 28 Dec 2019 22:18:40 +0000

[Message part 1 (text/plain, inline)]

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.

Thanks!
Jason Mancini

[Message part 2 (text/html, inline)]

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Nio Wiklund <wiklund.olle <at> gmail.com>
To: bug-parted <at> gnu.org
Subject: Re: bug#38783: GPT case that parted can't handle
Date: Sun, 29 Dec 2019 01:07:24 +0100

Den 2019-12-28 kl. 23:18, skrev Jason Mancini:
> 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.
> 
> Thanks!
> Jason Mancini

@ Jason Mancini,

Did you try to repair the backup partition table with 'gdisk'?

Best regards
Nio

Message #11 received at 38783 <at> debbugs.gnu.org (full text, mbox):

From: Jason Mancini <jayrusman <at> hotmail.com>
To: "38783 <at> debbugs.gnu.org" <38783 <at> debbugs.gnu.org>
Subject: feedback
Date: Sun, 29 Dec 2019 01:47:06 +0000

> Did you try to repair the backup partition table with 'gdisk'?
> Best regards
> Nio

Nice, gdisk correctly handles the situation.  Literally: gdisk, write, quit.
Can we get parted and fdisk/cfdisk to be as clever, and not discard the first table because the second table is inaccessible?  That's the whole point of having two tables ...

This bug causes Linux installers to overwrite working Windows installations.

Jason

Message #14 received at 38783 <at> debbugs.gnu.org (full text, mbox):

From: "Brian C. Lane" <bcl <at> redhat.com>
To: Jason Mancini <jayrusman <at> hotmail.com>
Cc: 38783 <at> debbugs.gnu.org
Subject: Re: bug#38783: GPT case that parted can't handle
Date: Mon, 6 Jan 2020 14:22:51 -0800

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

Message #17 received at 38783 <at> debbugs.gnu.org (full text, mbox):

From: Jason Mancini <jayrusman <at> hotmail.com>
To: "38783 <at> debbugs.gnu.org" <38783 <at> debbugs.gnu.org>
Subject: Re: bug#38783: GPT case that parted can't handle
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

Message #20 received at 38783 <at> debbugs.gnu.org (full text, mbox):

From: Ulf Zibis <Ulf.Zibis <at> gmx.de>
To: Jason Mancini <jayrusman <at> hotmail.com>
Cc: 38783 <at> debbugs.gnu.org
Subject: Re: bug#38783: GPT case that parted can't handle
Date: Tue, 7 Jan 2020 12:07:44 +0100

Hi,

what you mean by "cloning"?
Hardcopy of the first 63 GB by help of e.g. dd tool or using parted to
copy the 63 GB partition?

Did you try to use the tool testdisk to repair the situation?

Hope this helps,
Ulf

> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.