[GTALUG] Compressing an image of a microSD card

[El Fontanero]

On 2020-05-14 12:10 p.m., Giles Orr via talk wrote:
> It uses a Linux distro that was developed for an older hand-held game
> console.  It turns out that the OS and "internal storage" are on an
> actual microSD card inside the case: four screws and a gentle tug to
> get the card out, and you can image the "main drive."
>
> It's a 16G SD card with two partitions that occupy the whole card.
> Between them, they have 1.4G of used space.  I imaged the whole card:
>
>      # time dd if=/dev/sdi bs=4M of=./RG350.SD.2020-05-14.img
> conv=fsync status=progress
>
> This produced a roughly 16G image as expected.  Then I compressed it:
>
>      # time xz --threads=5 RG350.SD.2020-05-14.img
>
> This produced a 10G image.
>
> My assumption was that compression would see the empty partition
> space, presumably as a bunch of zeroes, and compress the crap out of
> it so that the final image would be the same size or smaller than the
> 1.4G of used space.  I'm aware that the free space may not be zeroed
> out ...  It's not encrypted, so that's not the issue.  Is there a sane
> way to back this up that would produce a smaller image?  I prefer to
> image the whole card ... and I like 'dd' because I'm familiar with it,
> although maybe I should move on ...  Is somehow zeroing the empty
> space on the card a possibility?  Suggestions welcomed ...
>
> I can live with the 10G backup if I have to, but would prefer a
> "better" solution if it's available.
>
Hi Giles,

Firstly, there's a good chance that if the space is unused, it can be 
made compressible.  If it were zeroed, it would have compressed very 
well.  Since the unit is linux-based, you have a very good chance of 
being able to loop-mount it. If, furthermore, you're lucky enough to be 
dealing with an old-style partition table on the card:

  * Start by seeing if you get a partition table: 'fdisk -l
    RG350.SD.2020-05-14.img'
  * Loop mount, e.g. 'mount -o loop,offset=$((512 * xxxx))
    RG350.SD.2020-05-14.img tmp/' where xxx is the number of, e.g.,
    512-byte sectors
  * explicitly zero empty space: 'dd if=/dev/zero of=tmp/zero.dat bs=1M'
  * rm tmp/zero.dat; umount tmp/
  * recompress

If the partitioning isn't obvious, I would still look for a filesystem 
superblock in there somewhere, and then loopmount etc. as above.

Good luck!

Cheers,
Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gtalug.org/pipermail/talk/attachments/20200514/dc3c361f/attachment.html>