bug#53138: Handling of shrinked GPT disks

[Davis]

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