copied an NTFS partition to a new SSD with GParted, but md5sum doesn't match

venom_zx · 08-19-2017, 06:59 PM

hi guys,

i have a HDD with just 1 partition. an NTFS partition. i copied it to a new SSD using GParted.

i wanted to be sure that it was copied correctly so i ran:
sudo md5sum /dev/sda1
437f43e544484a5508416c6d0f23cae0 /dev/sda1
sudo md5sum /dev/sdc1
3e2fbfd84c4f5c2f6ca6ad692bf7482a /dev/sdc1

(where "/dev/sda1" new partition on the SSD in GParted "/dev/sdc1" is the original partition on the HDD)

the md5 hashes don't match. i checked twice, but the result was exactly the same 2 differing hashes. both partitions have their first sector at 2048.

- the data is supposed to be identical right?
- is there a way i can diff them and then patch the partition on the new SSD?

syg00 · 08-19-2017, 07:35 PM

gparted would have mkfs'd the new partition then copied the data. Which would have, at a minimum, defragmented files. The on-disk representation would no longer be the same, although the data should be.
Only way to be sure would be to hash each file individually I would reckon. If you had copied them yourself would you also do a hash check of the partitions ?. I never have.

venom_zx · 08-19-2017, 10:15 PM

oh. that makes sense. i didn't know it made an empty file system. i first tried it in virtualbox on the partition of a fresh installation of windows 7 where the hashes did match. i guess i will just do it for a select few files. i like to double check things.

thanks

rknichols · 08-19-2017, 11:03 PM

Quote:

Originally Posted by syg00

gparted would have mkfs'd the new partition then copied the data.

No, it copies the entire filesystem structure, preserving all the metadata. Files in the copy will have the same inode numbers as in the source, and will be located in the same filesystem blocks. What gparted does not do is copy the free space, so unless the free space in the source has been zeroed and the destination partition has also been zeroed, the md5sums will not match.

Here's a sample mapping of a file in the source and destination filesystems. The two filesystems have different starting LBAs, but the offsets and fragmentation are identical.

Code:

root@sysresccd /root % hdparm --fibmap /mnt/tmp1/initramfs-2.6.32-696.1.1.el6.x86_64.img

/mnt/tmp1/initramfs-2.6.32-696.1.1.el6.x86_64.img:
 filesystem blocksize 4096, begins at LBA 2048; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0     428032     444415      16384
     8388608     395264     411647      16384
    16777216     621112     632511      11400
root@sysresccd /root % hdparm --fibmap /mnt/tmp2/initramfs-2.6.32-696.1.1.el6.x86_64.img

/mnt/tmp2/initramfs-2.6.32-696.1.1.el6.x86_64.img:
 filesystem blocksize 4096, begins at LBA 1435648; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0    1861632    1878015      16384
     8388608    1828864    1845247      16384
    16777216    2054712    2066111      11400

syg00 · 08-19-2017, 11:21 PM

How about that. The things you learn watching the footy.
Thanks.

ondoho · 08-19-2017, 11:37 PM

i just dd'd a complete micro sdcard (not a partition!) to my computer, and later back on the card again.
it worked.
i guess the checksums would match (due to hardware restrictions i can't check now).

venom_zx · 08-22-2017, 12:44 PM

thanks for the fast response guys. although i'm not familiar with those commands, thanks for clearing that up rknichols

jmgibson1981 · 08-22-2017, 01:22 PM

should upgrade to sha256 or something. md5 has been broken for awhile and has collisions.

AwesomeMachine · 08-22-2017, 02:28 PM

Code:

$ dcfldd

is a variant of the dd command written by the US government, that automatically verifies the MDsum periodically and when finished.