Wear-level md5sum issue? - (Re)Imaging cards for a Linux (Android) Device, dd and md5sum...
by LinuxAssailant from LinuxQuestions.org on (#4ZMM4)
I make backups for a proprietary device, with a proprietary (non-)distro w/a few partitions on it, so I have been doing backups to an image file from a SD/MicroSD card, as there have been multiple card failures (they are using China cards it seems) and corrupt data on cards.
Once I have a known-good card, I'll do a backup to an image file, so if I need to copy it, or write a new version to an old card, it is snap-and-pop for an upgrade too, instead of waiting a long time for the backend-update it does from the server, or multiple updates, via an "upgrade path".
If I dd /dev/sdb to an image file, and md5sum the image file and /dev/sdb I get identical md5sums. When I write to another card and then verify the data is kosher with "md5sum [imagefile]" then "md5sum /dev/sdb" (in my case) the md5sum is different even though the dd completed.
Many cards, same issue on write...
Could my issue be that wear-leveling is whacking out the md5sum w/a different card size due to cut-off (or blocked) blocks via wear-level controller on-chip?
This is on a Slackware x64 14.2 VM, if that matters, as I basically have to run Windows on my work rig, but I don't think I have ever had this issue in the past... but wasn't checking md5sums then.
Once I have a known-good card, I'll do a backup to an image file, so if I need to copy it, or write a new version to an old card, it is snap-and-pop for an upgrade too, instead of waiting a long time for the backend-update it does from the server, or multiple updates, via an "upgrade path".
If I dd /dev/sdb to an image file, and md5sum the image file and /dev/sdb I get identical md5sums. When I write to another card and then verify the data is kosher with "md5sum [imagefile]" then "md5sum /dev/sdb" (in my case) the md5sum is different even though the dd completed.
Many cards, same issue on write...
Could my issue be that wear-leveling is whacking out the md5sum w/a different card size due to cut-off (or blocked) blocks via wear-level controller on-chip?
This is on a Slackware x64 14.2 VM, if that matters, as I basically have to run Windows on my work rig, but I don't think I have ever had this issue in the past... but wasn't checking md5sums then.