Checksums do not match

Where /dev/sdX is your sd card device.

1 Like

I am happy to do any testing that may help, but I am not convinced that the problem is with Etcher.

With that said, I did the following:

On Windows 10, downloaded “Raspbian Buster with desktop” 2019-09-26-raspbian-buster.zip

Hash from web page: 2c4067d59acf891b7aa1683cb1918da78d76d2552c02749148d175fa7f766842
Hash from Win10 (certutil sha256) 2c4067d59acf891b7aa1683cb1918da78d76d2552c02749148d175fa7f766842

Use 7zip on Windows 10 to extract img file from zip; copy to USB flash drive
File size as reported by Win 10: 3.56 GB (3,829,399,552 bytes) – Same as in your message

On Win 10, use balenaEtcher-Portable-1.5.57.exe to flash a microSD card. Used a Transcend card and Transcend TS-RDF5 USB adapter.

1 Failed device Checksums do not match: f6019b399edeb08a !== d64f7f2395400666
[Checksums typed by hand from screenshot]

The following operations were performed on a Raspberry Pi 3B+ using Raspbian “Buster” 10.0

Copy .img file from USB drive to local storage (this is the extracted .img file)

ls -l 2019-09-26-raspbian-buster.img
-rw-r–r-- 1 pi pi 3829399552 Sep 25 16:31 2019-09-26-raspbian-buster.img

sudo dd if=/dev/sda of=sdcard.img bs=1M count=$(expr 3829399552 / 1024);
15223+0 records in
15223+0 records out
15962472448 bytes (16 GB, 15 GiB) copied, 878.105 s, 18.2 MB/s

Oops. Trying this…

sudo dd if=/dev/sda of=sdcard.img bs=1M count=$(expr 3829399552 / 1048576);
3652+0 records in
3652+0 records out
3829399552 bytes (3.8 GB, 3.6 GiB) copied, 220.477 s, 17.4 MB/s

sudo vbindiff 2019-09-26-raspbian-buster.img sdcard.img

Many differences throughout the file. Here is the first page:

2019-09-26-raspbian-buster.img
0040 03E0: 00 00 00 00 72 72 41 61 0F 42 06 00 51 9E 01 00 …rrAa .B…Q…
0040 03F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA … …U.
0040 0400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0040 0410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0040 0420: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0040 0430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0040 0440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0040 0450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0040 0460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
sdcard.img
0040 03E0: 00 00 00 00 72 72 41 61 0C 42 06 00 03 00 00 00 …rrAa .B…
0040 03F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA … …U.
0040 0400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0040 0410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0040 0420: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0040 0430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0040 0440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0040 0450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0040 0460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …

sudo cmp -l 2019-09-26-raspbian-buster.img sdcard.img >sdcard.diff
That produced a file that’s 3,610 lines long, so 3,610 bytes different between the two files.

sdcard.diff can be downloaded here: https://drive.google.com/open?id=1VopIwSTjwRIeg2AkKtPmcZuL42KXpIRg

I can put sdcard.img on Google Drive if you want a copy of it. It will take about four
hours to upload. I can also run some other comparison if that will help. I can make another sdcard.img file and do the cmp again. Because I got different output checksums with various runs of Etcher, I expect the differences will not be the same. I wonder whether they will be in the same file locations.

While all of that was running, I was able to flash the same file successfully twice using Etcher 1.5.45
on a 32-bit computer with Windows 7.

I did flash another microSD card, make an image, and compare it. The locations of the differences are very similar but not identical. I have an sdcard2.diff if it would be helpful.

I had been using the portable version of Etcher. I downloaded the setup and installed Etcher. Running from the installed version of 1.5.59 also gives checksum mismatches.

Hello, my guess would be that something writes to the sd card before it finishes validating. If you provide the sd card image I can have a look.

I can now post more replies! This is material that was edited into an earlier message, now removed.

The image of the SD card is here: https://drive.google.com/open?id=1m167nKavhNmP42FpiqRgdzpuuGY7bczG and thank you very much.

This morning (U.S. Eastern time) I bootstrapped the Win 10 computer in Safe Mode with Networking and ran ten trials using Etcher Portable 1.5.57, all of which succeeded. I ran five more trials using Etcher 1.5.57 installed, and all of those succeeded as well.

I restarted the computer twice once to recover from the automatic start of apps after Safe Mode and again to get a cold start. Five trials of installed Etcher failed with checksum errors.

From that I conclude that either another process is writing to the SD adapter or Etcher’s output buffer is being somehow corrupted when Windows is in “normal” mode.

I still don’t understand why this problem appears only with the 09-26 version of Raspbian as released, and not with other versions of Raspbian, including the immediately previous version and even the 09-26 version after I’ve added some software and removed other software.

Software removed: Wolfram Mathematica and associated modules; Geany

Software added: Vivaldi browser, Gnome screenshot, w1thermsensor added to Python library.

Application launcher customized.

The raspbian image has 2 partitions:

  • a 256MiB fat32 one starting at 4MiB;
  • a 3.3GiB ext4 one just after;

There are 359 bytes that differ between the 2 images.
All differences are located between 4MiB and 261MiB, only affecting the fat32 partition.
That makes sense as it is the only partition windows can handle.

I’ve compared the 2 fat32 partitions using meld.
Turns out the difference is a new System Volume Information folder containing IndexerVolumeGuid and WPSettings.dat files.
These look like files added by Windows so I guess there’s nothing to worry about.

It is strange that it only happens on this computer.
I’ll try to check if we can lock the drive on windows when I find some time.

Thank you very much! That explains it. It may also be a clue to why this version and no other. I will poke at that a bit. As far as why this computer and no other, it’s probably some setting having to do with indexing that I’ve overlooked.

You’ve solved my immediate problem perfectly. As you say, the long term solution is to lock the drive. Thank you again.

For what it may be worth, following the steps outlined here: https://superuser.com/a/1199824/394000 will prevent creation of that SVI folder. I can now get clean flashes of 2019-09-26 with Etcher on the Win10 computer.

I could flash earlier versions, e.g. 2019-07-10 without making the changes indicated in the link. That makes me think something in the boot partition is “tickling” Windows to create the SVI directory.

I didn’t know about meld until your message. Thanks! I’ve extracted the boot partitions from 09-26 and 07-10 to directories and compared them. There are, of course, differences, but nothing strikes me as something that would trigger Windows. So, I’ve posted a question here: https://superuser.com/q/1493717/394000 If I get a useful answer, I’ll come back here.

No response is necessary; you’ve helped me quite a lot! Thanks again!

1 Like

Hello!
I’m late to the party but I have also been experiencing the problems described by the OP. Several different images of Raspbian, different mSD cards, different card readers (/writers) and everything else mentioned. I did try the cards after the checksum failures, and all appear to have worked flawlessly.
Same thing happened at my brother-in-law’s house, where everything is different, so I’ve changed literally EVERY parameter - except my own presence in the room!
I am going to try the procedure @bbrown linked to, to see if that works for me.

The reason I mention this is just to let people know that this is not that uncommon a problem. But as @zvin says, it’s not a big problem, it’s just Windows interfering with it.


Added: Sure enough, it worked, the checksums matched.

Hi there,
We are glad the problem is solved. And thanks for pointing to that superuser thread explaining the details on how to disable SVI folder creation.

I have same problem. i try write image on windows computer and get “checksum not match” any image and any usbflash. But on linux computer no problem, same image and same usbflash.

Hi @hulitolku, and welcome to the forums.

Have you seen the earlier explanation posted here Checksums do not match with regards to how Windows creates the System Volume Information folder? You can disable this behavior with the instructions provided in this thread https://superuser.com/questions/1199823/how-to-prevent-creation-of-system-volume-information-folder-in-windows-10-for/1199824#1199824.

The device should work even with the checksum error. Can you let us know if it is not working as expected?

With checksumerror not working. Usbflash not loading and grub freeze(i use linux image).

@hulitolku Have you tried the fix linked above for the checksum error? It would be interesting to isolate the issue i.e. if you still have the boot error even after the checksum error has been fixed.

i done it:

  • In Windows 10 / 8.1 Pro & Enterprise Editions, press Windows Key + R combination, type put gpedit.msc in Run dialog box and hit Enter to open the Local Group Policy Editor .
  • Navigate here: Computer Configuration → Administrative Templates → Windows Components → Search
  • In the right pane, look for the setting named Do not allow locations on removable drives to be added to libraries and double click it.
  • Click on Enabled and then click Apply followed by OK . Close the Local Group Policy Editor .

That solved the problem, thanks!
No errors.

@hulitolku Thanks for confirming that and glad it is working!

Just FYI, same issue flashing Kali Linux with balenaEtcher on a win10 system. Also, Windows 10 Home edition does not have gpedit.msc so don’t waste your time looking for it and just jump straight into editing the registry.

Thanks for sharing @SDark. And welcome to balena forums :slight_smile:

I’m encountering the same checksum issues as described above, but the remedy prescribed has not fixed the problem. After modifying my windows policies through the procedures detailed, I’m still encountering the same error when I attempt to flash the image. Are there further steps that I can attempt?

Followed steps 1 and 2 of Superuser followed by a reboot and it solved the problem. https://superuser.com/questions/1199823/how-to-prevent-creation-of-system-volume-information-folder-in-windows-10-for/1199824#1199824

Windows 10