Error flashing ev3dev-stretch to microSD--fails to validate

[jlbabilino]

• Etcher version: 1.18.8
• Operating system and architecture: macOS Ventura 13.2.1 (22D68)
• Image flashed: ev3dev
• What do you think should have happened/How to reproduce: Flash from file ev3dev-stretch-ev3-generic-2020-04-10.zip, select a microSD card (I'm using 32gb SanDisk SDHC), click flash.
• What happened: It failed to validate the flashed SD card.
• Do you see any meaningful error information in the DevTools? This error happens after completely flashing but at 0% of validation stage:

Checksum does not match for range [55480320, 55508991]:
"651fb8f59468c35a98a50ec6ec9f6de06350e3815cd70c9c444856ba6e9a7603" !=
"00f24e1ae5bdf10b5b6509b29154c2c46f423730ac3eea97555a1f42245fb2ab"

• How I fixed it Instead of flashing ev3dev-stretch-ev3-generic-2020-04-10.zip, extract this zip and select the .img file when flashing instead of the zip itself.

The ev3dev installation then worked instead of hanging indefinitely. Please note I tried to flash this same image on three other sd cards, on a PC with Windows, then the same PC with Ubuntu (using etcher on both of course), a different version of ev3dev, and had the same issue on all. I think there's a common issue of flashing from zip files that only certain images have.

[chrschn]

Same here, I tried various combinations of SD cards and card readers, I tried Etcher 1.18.8 on Windows and Linux, the result was exactly as jlbabilino described. Instead, I used Etcher 1.17.0 which worked without problems.

[elisgrahn]

I too just had the exact same problem as @jlbabilino and now when I tried, his solution worked.

[kockelkorencj]

Thx you're a life saver 🥇 ... had the same issues, now it worked

[dlech]

This image uses an image.bmap file for faster flashing. So maybe support for that has broken in Etcher?

[dlech]

Sounds like same issue as https://github.com/balena-io/etcher/issues/3475

[jcormier]

Same here, I tried various combinations of SD cards and card readers, I tried Etcher 1.18.8 on Windows and Linux, the result was exactly as jlbabilino described. Instead, I used Etcher 1.17.0 which worked without problems.

I just ran into this as well.

Checksum does not match for range [139603968, 171724799]: "03894622b037535ba73985c02f1570d4726ecd917459ab4374e4a64d90096ec8" != "0fc043999123e5aec2a1b4ba739999000f0e981ff8e578a4609c6a5df86b0692

So far I've tested the following versions:

Broken: Version = 1.18.11, Type = nsis Version = 1.19.21, Type = nsis

Works: Version = 1.7.9, Type = deb Version = 1.14.3, Type = deb Version = 1.17.0, Type = portable

I don't think this is the same issue as #3475. It may be similar though. In the linked issue the last block causes problems if the file isn't 4k aligned. However with this problem its failing for me in one of the early blocks.

It also is a writing issue as the block of data written to the sdcard's checksum changes when flashed from the zip vs when flashed with image file (without bmap).

Bmap block info in case its useful:

                "ranges": [
    ...
                    {
                        "start": 34083,
                        "end": 41924,
                        "checksum": "03894622b037535ba73985c02f1570d4726ecd917459ab4374e4a64d90096ec8"
                    },
   ...
            "blocks": [
                {
                    "checksum": "03894622b037535ba73985c02f1570d4726ecd917459ab4374e4a64d90096ec8",
                    "checksumType": "sha256",
                    "blocks": [
                        {
                            "offset": 139603968,
                            "length": 32120832
                        }
                    ]
                },

Generated checksum for this block as follows

$ sudo head --bytes=171724800 /dev/sdf | tail --bytes=32120832 | sha256sum 
03894622b037535ba73985c02f1570d4726ecd917459ab4374e4a64d90096ec8  -
# sdcard flashed with newer etcher
$ sudo head --bytes=171724800 /dev/sdf | tail --bytes=32120832 | sha256sum 
0fc043999123e5aec2a1b4ba739999000f0e981ff8e578a4609c6a5df86b0692  -

[jcormier]

It also is a writing issue as the block of data written to the sdcard's checksum changes when flashed from the zip vs when flashed with image file (without bmap).

This doesn't look to be true. I see a similar sha256 change on either etcher version. My current guess is this has something to do with linux/windows automount. Though idk what could have changed between version 1.17.0 and 1.18.11 to affect that if that's the case.

[dlech]

I tested v1.18.0 and it has the bug as well. The only thing that changed between 1.17.0 and 1.18.0 was updating the electron version (which also updated the nodejs and V8 versions). So I'm guessing something change in one of those frameworks that causes the code to behave differently now.

I wasn't able to get Etcher to run from source correctly though - it thinks my SD card is too small even though it isn't, so I'm not sure how to debug this.

[jcormier]

I wasn't able to get Etcher to run from source correctly though

Hmm I couldn't even get npm to build etcher on my ubuntu machine. Must be doing something wrong.