<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 2020-05-14 12:10 p.m., Giles Orr via
talk wrote:
</div>
<blockquote type="cite"
cite="mid:CAEnxSC7JRWAGdbi5K_5O5DP2nrb=LgN_DoPugRDUbsz7hX6_fQ@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<p>Hi Giles,</p>
<p>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:<br>
</p>
<ul>
<li>Start by seeing if you get a partition table: 'fdisk -l
RG350.SD.2020-05-14.img'</li>
<li>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</li>
<li>explicitly zero empty space: 'dd if=/dev/zero of=tmp/zero.dat
bs=1M'</li>
<li>rm tmp/zero.dat; umount tmp/</li>
<li>recompress</li>
</ul>
<p>If the partitioning isn't obvious, I would still look for a
filesystem superblock in there somewhere, and then loopmount etc.
as above.</p>
<p>Good luck!</p>
<p>Cheers,<br>
Mike<br>
</p>
</body>
</html>