[Cialug] dd only allocated space?

[Zachary Kotlarek]

On 28 Jul 2017, at 9:36, L. V. Lammert wrote:

> Having an issue copying a chip, .. I need an image to get the MBR, but
> there is unallocated space behind the filesystem that should not get
> copied.

If the space you want it contiguous you can just find the last block you need — the partition map will tell you its LBA — and copy up to that; something like `dd bs=<LBA size> count=<last LBA + 1>` would work. For disks under 2 TB the LBA size is almost always 512 bytes, though you might want to do some math to use a large block size for faster copying (i.e. copy 1/8th as many 4096 byte blocks).

If the space isn’t contiguous, and the disk is partitioned with MBA then you just need the first 32-bit LBA (i.e. 512 bytes). If you copy that and reload the target device it will be partitioned to match the source and you can just copy the individual partitions and ignore the rest of the space.

GPT requires at least the first 2 32-bit LBAs, and may claim more arbitrarily-sized LBAs as defined in its header. If you don’t want to parse the GPT header you can just copy say the first 50 blocks; that will likely copy some of the first partition but that isn’t a problem in terms of logical consistency. Then as with the MBR scheme you’d be able to reload the target device to get access to the now-defined partitions.

Officially GPT keeps a backup copy at the far end of the disk, but in practice it’s optional, and since you’re trying to truncate the copy I wouldn’t worry about that until and unless you restore to another physical device. You can also use tools like `sgdisk` to more precisely extract and restore the GPT header.

	Zach
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2483 bytes
Desc: S/MIME digital signature
URL: <http://cialug.org/pipermail/cialug/attachments/20170728/f67241fe/attachment-0001.bin>