GNU bug report logs - #53138
Handling of shrinked GPT disks

Previous Next

To reply to this bug, email your comments to 53138 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: Davis <davikovs <at> gmail.com>
To: bug-parted <at> gnu.org
Subject: Handling of shrinked GPT disks
Date: Sun, 9 Jan 2022 10:08:00 +0200

Hi,

Looks like currently parted cannot handle GPT disks that have been
shrunk (e.g. copied to a smaller physical disk (sometimes with the same
rated capacity - disk capacity can vary a few KBs/MBs between
manufacturers/models) or shrunk virtual/SAN disk).

Instead of handling a shrunk GPT disk (with size that still fits all
partitions) as valid, but needing some fixes (e.g. missing backup GPT,
incorrect size of PMBR and a few values in GPT header), parted
displays "Error: Invalid argument during seek for read on
/dev/test_device_name" and shows no partitions.

This can be reproduced by commands like these:
dd if=/dev/zero of=testfile.img bs=100M count=1
sudo losetup -fP testfile.img
sudo losetup -j testfile.img

sudo parted /dev/loopX -s "mklabel gpt"
sudo parted /dev/loopX -s "mkpart linux ext4 1 50%"
sudo parted /dev/loopX -s "print"

sudo losetup -d /dev/loopX
sudo losetup -fP testfile.img --sizelimit 96M
sudo losetup -j testfile.img

# problem is visible here, there is additional prompt when run interactively
sudo parted /dev/loopY -s "print"

sudo losetup -d /dev/loopY
rm testfile.img

I think correct behavior would be assuming that Backup LBA and Last
usable LBA fields need to be fixed if they point beyond last LBA of
the disk (and last-33 LBA of the disk accordingly).
I think this would be a safe thing to fix if no partitions point
beyond last-33 LBA (the correct Last usable LBA value). And in case
partitions are pointing beyond last-33 LBA, user might want to be able
to delete those partitions.

I have tested parted with GPT disks that have been extended and there
GPT displays a message like "Warning: Not all of the space available
to /dev/loop5 appears to be used, you can fix the GPT to use all of
the space (an extra 40960 blocks) or continue with the current
setting?" and, when running interactively, offers to fix the issue.
Could it be possible to implement similar behavior for shrunk GPT disks?

Best regards,
Davis

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

From: "Brian C. Lane" <bcl <at> redhat.com>
To: bug-parted <at> gnu.org
Subject: Re: bug#53138: Handling of shrinked GPT disks
Date: Mon, 10 Jan 2022 14:18:41 -0800

On Sun, Jan 09, 2022 at 10:08:00AM +0200, Davis wrote:
> Hi,

[snip]

> I have tested parted with GPT disks that have been extended and there
> GPT displays a message like "Warning: Not all of the space available
> to /dev/loop5 appears to be used, you can fix the GPT to use all of
> the space (an extra 40960 blocks) or continue with the current
> setting?" and, when running interactively, offers to fix the issue.
> Could it be possible to implement similar behavior for shrunk GPT disks?

The question I have is, how common a problem is this? While it can
happen, it is a pretty fine line between losing just the backup GPT and
losing the end of the last partition (assuming it is fully utilized).
I'm not sure it's worth adding extra code and the potential for new bugs
if this isn't a common practice.

Brian

-- 
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart

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

From: Davis <davikovs <at> gmail.com>
To: bug-parted <at> gnu.org
Subject: bug#53138: Handling of shrinked GPT disks
Date: Thu, 13 Jan 2022 08:05:55 +0200

> The question I have is, how common a problem is this? While it can
> happen, it is a pretty fine line between losing just the backup GPT and
> losing the end of the last partition (assuming it is fully utilized).
> I'm not sure it's worth adding extra code and the potential for new bugs
> if this isn't a common practice.

I would guess that shrinking the last partition (e.g. using GParted)
and cloning disk using dd is probably a quite common practice - this
method preserves exotic boot loaders, disk/volume IDs and other
things. Also in some situations the size difference between old and
new drive could be less than the free slack space after the last
partition on the old drive (making shrinking unnecessary).
I am not sure how common are the cases when the last partition extends
beyond the end of the drive as the result of copying data without
resizing the partition (I can imagine this would be the case e.g. if
copying data from a failing drive). However I think that even in those
cases parted shouldn't display an empty partition table.

Davis

Previous Next

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