Web lists-archives.com

libgparted bug.

Greetings all;
Trying to make a backup image of a 64GB bootable sdcard. Th os say its 
59.b GB when it mounts the original, but pull copy to a file and its 
nearly a megabyte bigger than 64gigs.  So obviously the file is bigger 
than a brand new unformatted disk.

dd said, when it ran out of room:

gene@coyote:~/rock64.imgs$ dd of=/dev/sdd bs=64k if=working-rock64.img
dd: writing `/dev/sdd': No space left on device
976897+0 records in
976896+0 records out
64021856256 bytes (64 GB) copied, 2512.18 s, 25.5 MB/s

So nominally 600k of card disappeared. 

And while it seems gparted ought to be able to fix it, it refuses to read 
it at all, throwing up a messages box claiming:

Assertion (last_usable <= disk->dev->length) 
at ../../../libparted/labels/gpt.c:723 in function _parse_header() 

And its only clickable button says "no" and is a gparted exit when its 
clicked on.

Obviously I need to restrict dd to about the first 10 gigs as there is 
not any data beyond that anyway.  So wash, rinse and repeat.

But I need too, to shrink the file system, and the last partition on the 
card to low enough I could use a 16GB sdcard as the test tool, which 
would also be a time saver since reading out the whole 64GB is a 1.5 
hour project.

I have used about every disk utility there is, and have identified the 
first problem is that partition 7 is around 125k bigger than the disk. 
But I have not found a way to do a shrink.

Since these sdcards are rarely the exact same size, even in 2 from the 
same peg, it seems to me there ought to be a way to reduce them to a 
lowest common total size just so an image backup can be done.  Why 
hasn't such a utility been done?

Many thanks for any advice.
Cheers, Gene Heskett
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>