Successful copy resulting in corrupted data

[hgomersall]

The problem I'm encountering is a situation in which bmaptool copy completes the copy successfully but the actual data is corrupted.

The source is a gzipped sparse image. The created bmap file contains a reasonable collection of sparse blocks.

The problem occurs on an ARM A9 writing to an eMMC device, and also on a Intel PC writing to an SD card the latter on a different image. bmaptool reports completion, which presumably is using the checksums (since AFAICT that is the default).

I initially thought that the issue was that the random writes were causing the driver problems. I initially fixed the problem by setting

echo write through > /sys/block/mmcblk1/queue/write_cache

Then, on completion of the write, doing

sync
blockdev --flushbufs /dev/mmcblk1

However, when I changed the partition layout, this fix proved not reliable.

The invalid write can be checked with

dd count=<IMAGE SIZE IN BYTES> iflag=count_bytes if=/dev/mmcblk1 | sha256sum

and comparing that sha256sum to the expected output from the image. The failed write shows a different checksum.

Using dd on the images directly after unzipping them seems to work fine, and I can manually verify the checksum of the device against the source image (though the kernel could be lying to me here as what data is written).