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>