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()
failed
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>
Reply to: