1 |
On 5/29/21 7:09 PM, cal wrote: |
2 |
> On 5/29/21 5:42 PM, thelma@×××××××××××.com wrote: |
3 |
>>>> Another mystery. |
4 |
>>>> I copied the file to USB 1TB sandisk. |
5 |
>>>> md5sum check OK same as my computer |
6 |
>>>> |
7 |
>>>> |
8 |
>>>> md5sum /run/media/joseph/SSD-1TB/business/backup/VDI/windows-7_pro_May-23-21.ova |
9 |
>>>> 6f3348f1fb915af9c45806d947558a37 /run/media/joseph/SSD-1TB/business/backup/VDI/windows-7_pro_May-23-21.ova |
10 |
>>>> |
11 |
>>>> I mount the same USB 1TB sandisk on another computer and running md5sum on same file gives me different number, why??? |
12 |
>>>> |
13 |
>>>> md5sum /run/media/fd/SSD-1TB/business/backup/VDI/windows-7_pro_May-23-21.ova |
14 |
>>>> c478cb48e2f7961cb0e3eb452df6e642 /run/media/fd/SSD-1TB/business/backup/VDI/windows-7_pro_May-23-21.ova |
15 |
>>>> |
16 |
>>> Did you sync and unmount the partition before ejecting the drive from |
17 |
>>> the first computer? With a file this large being copied, it is likely |
18 |
>>> that a large amount of data remains buffered/cached and will not be |
19 |
>>> fully written to the flash memory even after the copy command completes. |
20 |
>>> |
21 |
>>> On the first machine, you would still see the correct md5sum because the |
22 |
>>> kernel abstracts this fact away from you. But if you rip out the drive |
23 |
>>> and take it somewhere else without flushing those caches, you're going |
24 |
>>> to get an incomplete file. |
25 |
>>> |
26 |
>>> Check if the file on the drive still md5sums the same if you plug it |
27 |
>>> back into the first machine. Check what size it is, and whether there |
28 |
>>> are a lot of 0s at the end indicating an unfinished write. |
29 |
>>> |
30 |
>>> cal |
31 |
>> |
32 |
>> Yes, I unmounted the USB device every time. |
33 |
>> And yes, I plug the USB device back to original machine and md5sum is correct, same as the original. |
34 |
>> |
35 |
>> I copied the large file over network to another box and md5sum of: windows-7_pro_May-23-21.ova is correct same as on the original box. |
36 |
>> |
37 |
>> I run this: "rsync -avh [source] [destination] && rsync -avhc [source] [destination]" |
38 |
>> |
39 |
>> above code rsync files folder on first run and if complete without issue, will run rsync again immediately while performing same file name comparison by using hash of entire file. |
40 |
>> |
41 |
>> This i what I got: |
42 |
>> |
43 |
>> rsync -avh windows-7_pro_May-29-21.ova fd@10.0.0.138:/home/fd/business/VDI/ && rsync -avhc windows-7_pro_May-29-21.ova fd@10.0.0.138:/home/fd/business/VDI/ |
44 |
>> sending incremental file list |
45 |
>> windows-7_pro_May-29-21.ova |
46 |
>> |
47 |
>> sent 30.29G bytes received 35 bytes 115.81M bytes/sec |
48 |
>> total size is 30.28G speedup is 1.00 |
49 |
>> sending incremental file list |
50 |
>> windows-7_pro_May-29-21.ova |
51 |
>> WARNING: windows-7_pro_May-29-21.ova failed verification -- update discarded (will try again). |
52 |
>> windows-7_pro_May-29-21.ova |
53 |
>> ERROR: windows-7_pro_May-29-21.ova failed verification -- update discarded. |
54 |
>> |
55 |
>> sent 33.44M bytes received 6.47M bytes 123.38K bytes/sec |
56 |
>> total size is 30.28G speedup is 758.62 |
57 |
>> rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1330) [sender=3.2.3] |
58 |
>> |
59 |
>> |
60 |
>> |
61 |
> rsync is emitting errors indicating the file was not transferred |
62 |
> correctly. At this point I would call into question whether your second |
63 |
> machine is the problem rather than any of the tools you're using. If |
64 |
> you have a third machine that is easy to test. Otherwise I would run |
65 |
> memtest86+ and smartctl. |
66 |
> |
67 |
> cal |
68 |
|
69 |
Right On Cal, running memtest86+ gave me nothing but errors. I'm surprised it compiled all the packages recently without any errors. |
70 |
Putting two good stick in it and md5sum worked without a problem. |
71 |
Was able to import OVA into virtualbox without any errors. |