Re: libgparted bug.

["Thomas Schmitt" <scdbackup@gmx.net>]

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