Re: libgparted bug.
Hi,
your count=122070 was too small. It should have been 128912. See below.
Gene Heskett wrote:
> gene@coyote:~/rock64.imgs$ /sbin/gdisk -l rock-img-shrunk.img
> [...]
> Caution: invalid backup GPT header, but valid main header; regenerating
> backup header from main header.
You cut off ~ 56 GB of the original device data. At the very end of the
original there is the GPT backup copy. So it was not copied.
> Warning! One or more CRCs don't match. You should repair the disk!
This is not a good sign. GPT has checksums in the header block. One
for the header itself and one for the partition entries array.
If any does not match, then some partition editing did not what it
was supposed to do.
Well, old sins ...
> Total free space is 108670973 sectors (51.8 GiB)
gdisk seems still to believe in the size which it found in the copied
GPT header block. Hopefully this misbelief would end if the image was
copied successfully to a new storage medium.
Nevertheless, gdisk or an other partition editor will then have to
adjust this size field in the GPT (and the checksums) to the real
storage device size.
> Number Start (sector) End (sector) Size Code Name
> 1 64 8063 3.9 MiB 8300 loader1
> 2 8064 8191 64.0 KiB 8300 reserved1
> 3 8192 16383 4.0 MiB 8300 reserved2
> 4 16384 24575 4.0 MiB 8300 loader2
> 5 24576 32767 4.0 MiB 8300 atf
> 6 32768 262143 112.0 MiB 0700 boot
> 7 262144 16500735 7.7 GiB 8300 root
The first six partitions should be like on the original card.
I am not so sure about number 7.
Does it have the same size on the original card ?
If it is like on the original:
For a good copy up to the end of partition 7 you would have had to
copy 16500735*512/65336 = 128912 blocks.
So now your copy lacks the last 6842 * 65336 = 447,028,912 bytes of
partition 7.
With a copy of 128912 * 64 KiB the image file should be good and you'd
only have to solve the riddle why the new card did not take the bytes
you copied to it (or why it put them at the wrong place).
Have a nice day :)
Thomas
Reply to: