Re: libgparted bug.
Hi,
Gene Heskett wrote:
> Warning! Secondary partition table overlaps the last partition by
> 33 blocks!
Sorry, my mistake. I should have staid with my first rough estimation
of 8 GiB = 131072 * 64 KiB.
Actually i missed the safe size by just one chunk of 64 KiB.
128913 would have been enough. But 131072 looks more like a lucky number.
And safer against my miscalculations !
All was well before gdisk was allowed to write to the image file.
Now its last 33 blocks of 512 bytes are spoiled.
Do not forget to umount all partitions of the original /dev/sdd before
starting again to copy it to the image file.
After the next copy from original sdd to file, first copy the file to
the new card, and only then let gdisk access it for tests.
Let gdisk repair the backup GPT on the new card, because it must be
adapted to that storage size anyway.
-------------------------------------------------------------------
What happened and why i am to blame:
> gene@coyote:~/rock64.imgs$ /sbin/gdisk rock-img-shrunk.img
> Warning! Disk size is smaller than the main header indicates!
True. The "disk" is now the data file. But the GPT header still knows
the block address of the backup GPT header, which is the last usable
block on the original storage medium.
> Caution: invalid backup GPT header
True. "Not there" is surely "invalid".
> Warning! One or more CRCs don't match. You should repair the disk!
True. We will let gdisk handle these GPT damages ...
... but i should have thunk in advance and should have warned of
letting gdisk write to the image file.
On the second run of gdisk:
> gene@coyote:~/rock64.imgs$ /sbin/gdisk rock-img-shrunk.img
> ...
> Warning! Secondary partition table overlaps the last partition by
> 33 blocks!
Duh. When telling the dd size i forgot to account for a new backup GPT.
As said, the backup GPT header goes to the last block of the "disk".
Obviously gdisk wrote it and 32 blocks before that position
for the backup GPT array with 128 possible partition slots.
Stupid enough to do it, smart enough to tell us that we now need
to repair it. Grrr at gdisk.
And this all for a backup GPT which becomes invalid again after the
image is copied onto a real storage device. Grrr at myself.
(You did not by chance copy the image to sdd before the first write
by gdisk, did you ?)
Partition 7 ends at 512-byte block 16500735, including it.
So safe against gdisk's repair work would be at least
16500736 + 33 = 16500769 blocks.
In chunks of 64 KiB that's 128912.2578125. Rounded up: 128913
If you are adventurous enough and if the original sdd partition 7 was
not mounted since you made the recent copy to rock-img-shrunk.img,
then you could make a small block copy from original card to the image
file. Just enough to repair the overwritten partition end and to add
enough room for the backup GPT:
dd if=/dev/sdd bs=512 skip=128879 count=66 \
of=rock-img-shrunk.img seek=128879
This would restore the 33 overwritten blocks and add 33 victim blocks
for gdisk - if you at all let it touch the image file before it is safely
copied to the memory card.
A higher count= would add more safety bumper to the image end.
But do this only if there is surely no risk that a filesystem driver had
write access to partition 7.
Else repeat the whole copying with surely all partitions of the card
not being mounted.
Have a nice day :)
Thomas
Reply to: