Hi, i wrote: > > your count=122070 was too small. It should have been 128912.
Gene Heskett wrote: > the backup GPT table, if it exists, is actually at the end > of the disk, after another 50Gb of of 0000's. But how do I "fix" the > file? Partition editors suitable for GPT are supposed to be able to create a new backup GPT at the end of the storage medium. Of course this makes few sense in the image file, because it does not have the final medium size and also because yours is too short anyway. > Blame that on gparted which did not update the ending GPT table when I > shrank part 7 from 59.6 GB to about 7 The backup GPT is always at the very end of the storage device. Not necessarily directly after the last allocated partition. (That's why GPT is less suitable for image files as would be MBR partition table, which has reference to the size of the final storage medium.) > gdisk /dev/sdd > x > e > w > seems to have fixed that, gparted is now as happy as a clam. Formally your GPT is ok now. But to my computation, the last ~ 450 MB of your partition 7 are not filled with bytes from the original card. This range rather contains bytes which were on the new card already before you copied the image file onto it. (Not really random, but quite surely not matching the data which were valid on the original card.) You could test this with the image file, by mounting partition 7 and checking whether all its data files are fully readable: mkdir /mnt/partition7 mount -o loop,offset=134217728 rock-img-shrunk.img /mnt/partition7 tar cf /dev/null /mnt/partition7 umount /mnt/partition7 rmdir /mnt/partition7 (134217728 = partition start 262144 * 512 bytes per block) If the directory tree of the filesystem in partition 7 refers to files in a missing end piece of the partition, then you should see an i/o error from tar while it copies all file content into /dev/null. This will not yield i/o errors on /dev/sdd, because there you have readable bytes at the end of the partition. They are just not those which should sit there, to my theory. But i seem to be out of sync with your endeavor: How did you now manage to get rock-img-shrunk.img onto the new /dev/sdd ? To my account, this was not yet achieved when you sent the mail with Date: Fri, 9 Feb 2018 12:22:54 -0500 which reported an MBR partition table with partition 1 starting at block 32768 and containing "HPFS/NTFS/exFAT". Have a nice day :) Thomas