Checksums do not match

i downloaded raspbian buster image and checksum of file is correct.
but when i flash it, finally it occurs error.
the error is…
\.\PhysicalDrive4: Source and destination checksums do not match : blah !== blah
and the result of drives checksum are different every time.

my pc’s mainboard is asrock b150m hyper/pro4. and windows 10 pro x64.
i changed SD card, usb port, and SD card reader but same result.
and mainboard driver is latest version.

but when i flashing it using notebook (dell inspiron 15R se 7530), it has been success.

does anyone know that?

1 Like

Hi,

I’ve raised the issue with our Echer maintainer, we will get back to you as soon as we can.

1 Like

I am also having trouble flashing the latest ( 2019-09-26) “Raspbian Buster with desktop and recommended software.” I always get “1 device failed” when trying to write it to a microSD card using balenaEtcher 1.5.33 and also balenaEtcher 1.5.57. Flashing older Raspbian images does work.

The environment is Windows 10 Pro 1903, 64 bit, Lenovo Thinkpad T-530 using the USB 2.0 port.

I have tried:

  • Different microSD cards (All SanDisk brand from a reputable source.)
  • Different USB adapters
  • Different USB ports
  • Re-downloading the zip file
  • Verifying the checksum of the downloaded file.

Debugging suggestions or help will be most welcome.

@adamzchmbr Did you try to use the written sd cards that were supposed to be failed, by chance? Asking because this issue is generally seen when the writing process has been successful, but something goes wrong when reading which is generally tied to the hardware that is reading, which would also explain why it works instead on a different machine. So again, first of all you could try the sd card you flash even though it says that is “failed”, after that I would also check the devtools console (ctrl + shift + i) when the fail occurs to see if there’s more verbose information that you can share here, as what I just described is just the most common cause of it.

@bbrown As for your issue, have you got a different card reader/adapter to try out, if you didn’t already? As mentioned above, you can pull up the devtools console with ctrl + shift + i and get some more insight on the issue. There you’ll likely find the full error, but you should be able to get the error message when you hover over the “1 failed” line.

1 Like

Thank you very much, I’ve tried both Transcend and Anker brand adapters with various cards in various USB ports. The error is a checksum mismatch, and I have captured the devtools console contents, but am unable to learn anything else from it.

Although the main window tells me “1 Failed device” the pop-up notification at the lower right says the operation was a success. I’ll try to be fast enough to capture a screen shot. I’ve captured a screenshot, but there doesn’t seem to be a way to attach it. The lower right message was “Flash complete! 2019-09-26-raspbian-buster-full.zip was successfully flashed to SDHC Card (E:)”

The file I am attempting to flash is a zip file downloaded from here: https://www.raspberrypi.org/downloads/raspbian/

If I knew the checksum algorithm, I could compute source and destination checksums externally.

Hello, Etcher uses xxhash, we use this implementation: https://www.npmjs.com/package/xxhash . In general a checksum mismatch means that the sd card has broken sectors.

1 Like

Thanks! I’ll work with that a bit, and also the info about the SD card. I’ve tried several, but have more I can try.

@thundron Hi. Im very sorry too late.
First of all, I tested 2 new SD cards (transcend and sandisk) and the result was fail.
I can understand if one card fails, but I think it’s a problem that two cards fail.
And as you says, follow is my console log.

Tue Oct 15 2019 20:19:48 GMT+0900 (대한민국 표준시) Validation error ({“applicationSessionUuid”:“1478abf4-2552-4635-b965-91b7fe49479a”,“flashingWorkflowUuid”:“b6d83cf8-dc44-4ce3-971f-b84f2ace19eb”,“flashInstanceUuid”:“053eebd5-de0f-4e13-a20e-058d2d7027ee”,“image”:“C:\Users\Adamz\Downloads\2019-09-26-raspbian-buster.zip”,“drives”:[{“size”:15931539456,“isVirtual”:false,“enumerator”:“USBSTOR”,“logicalBlockSize”:512,“raw”:"\\.\PhysicalDrive4",“error”:null,“isReadOnly”:false,“displayName”:"H:\, "}],“description”:“Generic STORAGE DEVICE USB Device”,“isUAS”:false}],“driveCount”:1,“uuid”:“053eebd5-de0f-4e13-a20e-058d2d7027ee”,“unmountOnSuccess”:true,“validateWriteOnSuccess”:true,“trim”:false,“sample”:0.1})

Tue Oct 15 2019 20:19:51 GMT+0900 (대한민국 표준시) Done ({“errors”:[{“name”:“Error”,“code”:“EVALIDATION”,“device”:"\\.\PhysicalDrive4"}],“devices”:{“failed”:1,“successful”:0},“status”:“started”,“image”:“C:\Users\Adamz\Downloads\2019-09-26-raspbian-buster.zip”,“drives”:[{“size”:15931539456,“isVirtual”:false,“enumerator”:“USBSTOR”,“logicalBlockSize”:512,“raw”:"\\.\PhysicalDrive4",“error”:null,“isReadOnly”:false,“displayName”:"H:\, "}],“description”:“Generic STORAGE DEVICE USB Device”,“isUAS”:false}],“driveCount”:1,“uuid”:“053eebd5-de0f-4e13-a20e-058d2d7027ee”,“flashInstanceUuid”:“053eebd5-de0f-4e13-a20e-058d2d7027ee”,“unmountOnSuccess”:true,“validateWriteOnSuccess”:true,“trim”:false,“applicationSessionUuid”:“1478abf4-2552-4635-b965-91b7fe49479a”,“flashingWorkflowUuid”:“b6d83cf8-dc44-4ce3-971f-b84f2ace19eb”,“sample”:0.1})

i wish that is helpful.

OK… there is something pathological about my setup and the newest Raspbian image files! AAaarrgghh!

Using the same setup as always, and described above, I can reliably flash older Raspbian images, including the July image. However, using a card that has just been read-write tested with h2testw.exe, trying to flash the 9-26 image fails with a checksum error. The 9-26 image of “Raspbian Buster with desktop” also fails, even though it’s smaller than the July “full” image, so it’s not the size of the image.

So, I use a USB drive to transfer the 9-26 file to an old machine running Windows 7, then download and install Etcher on that machine. Using the same card that just failed, plugged into the same USB adapter, I get a perfect flash.

I don’t have a clue what causes this problem, nor how to debug it, but my overall dilemma is solved because I don’t have any trouble flashing the 9-26 release after I’ve customized it. The moral of the story is, it if doesn’t work, you have to get a different computer.

{Goes slowly away, shaking head sadly…}

@bbrown I couldn’t reproduce this on Windows 10 nor Linux. Did you use the zip file or did you extract it first? At which percentage does the validation fail?

1 Like

Maybe something on your computer writes to the sd card before the validation finishes?

1 Like

Do you have any tool to compare the sd card (after flashing) and disk image contents?

1 Like

I don’t think you will be able to reproduce it; there’s something pathological about my setup and that particular version of Raspbian. It works fine on my old Win 7 computer. Older versions of Raspbian work fine on the Win 10 system.

I don’t think it’s something writing to the card before validation. I can write other Raspbian images, just not that one.

I do not have a tool to compare the disk image to the SD card. I tried making an ISO from the SD card to do that, but the ISO included the unallocated part of the SD card. I have no reason to distrust the Etcher checksums. If you know of such a tool, I’ll be glad to test with it.

By the way, the file checksum from Etcher was always the same, as it should be, but the SD checksum was always different, indicating that whatever was corrupting the SD card was not the same thing (i.e. not the same location or not the same value, or both) for each run.

Thank you very much for the help.

Hello again,
If you have time, you could try the following with the flashed sd card on a Linux (or maybe mac) computer:

  • check the disk image size : ls -l 2019-09-26-raspbian-buster.img, it should be 3829399552 bytes if you use the desktop raspbian buster 2019-09-26 image;
  • create a disk image of your sd card with dd if=/dev/sdX of=/path/to/disk/image.img bs=1M count=$(expr 3829399552 / 1024);
  • compare the original image with the one extracted from the sd card with vbindiff /path/to/original/image /path/to/the/extracted/image.
1 Like

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.