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