Open agners opened 1 year ago
Same with the latest preview v1.18.8. An older version I had at hand seems to work (1.5.120).
Same here! On Fedora Workstation 37, exactly as described by the OP.
samesame. thanks for the tip about 1.10.x
and 1.10x stalled out at 99% with 20seconds remaining.
Does it work if you download the file first and try to flash that?
works for me:
Etcher version: 1.18.4-x64 Operating system and architecture: Ubuntu x86-64 Image flashed: https://github.com/home-assistant/operating-system/releases/download/10.1/haos_odroid-n2-10.1.img.xz, downloaded locally, not flashed from URL
@dfunckt yes it works when downloading and then installing. We currently document this as work around.
We've discovered that the same is true for MacOS.
Any chance that this gets addressed? It would be really helpful if we could use flashing directly from an URL again.
I'm also unable to flash from URL, but I don't get an error at all. The progress on bytes written increases until it just about completes and then it stops indefinitely. I can download the image and flash fine, but the workflow problem I'm trying to solve centers around eliminating the download step.
I'm on macOS 14.0
I get the same issue when flashing .img.gz
and .img.xz
from a URL but flashing .img.zip
works from a URL.
Flashing all three of the above compressed images works when flashing from the locally downloaded file.
@dfunckt let me know if there's any more information I can provide to help you guys. We reccomend balenaEtcher to all of our users when installing @getumbrel and currently it's slowing down our build process quite a lot because we can't make use of parallel gzip compression on our images and instead use single threaded zip compression to avoid hitting this bug.
I have the same issue with xz
files (not from URL)
Happens on 1.19.21
and 1.19.19
No issue when using the uncompressed version
I don't know at version it stopped working exacly, but used to work before, keep in mind "Flashing" finishes, it failes on "Validating" I'm on macOS Sonoma 14.5 running on M1 Max
Be aware: The reason the validation fails is seems that was is written to the card is incorrect I've compared both a flashed "uncompressed" and "compressed" dumps - it is different. (further more, the written SD card doesn't boot when the source file is compressed) Older versions didn't have this issue
Almost been a year now ... no one even assigned to this bug :(
Here's info from DevTools
{
"name": "Error",
"message": "Source and destination checksums do not match: 3aede0f91605a464 !== a8995833017c2d76",
"stack": "Error: Source and destination checksums do not match: 3aede0f91605a464 !== a8995833017c2d76\n at CountingHashStream.<anonymous> (/snapshot/Users/runner/work/etcher/etcher/node_modules/etcher-sdk/build/source-destination/source-destination.js:158:36)\n at CountingHashStream.emit (node:events:518:28)\n at CountingHashStream.<anonymous> (/snapshot/Users/runner/work/etcher/etcher/node_modules/etcher-sdk/build/source-destination/source-destination.js:78:16)\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5)",
"code": "EVALIDATION"
}
And unrelated error, but on failure this shows as well
GET file:///Applications/balenaEtcher.app/Contents/Resources/app.asar/.webpack/renderer/main_window/media/icon.png net::ERR_FILE_NOT_FOUND