etcher
etcher copied to clipboard
Flashing xz compressed file from URL fails
- Etcher version: 1.18.4-x64
- Operating system and architecture: Arch Linux x86-64
- Image flashed: https://github.com/home-assistant/operating-system/releases/download/10.1/haos_odroid-n2-10.1.img.xz
- What do you think should have happened: Flash that image
- What happened: Error: The elevated process died unexpectedly
- Do you see any meaningful error information in the DevTools?
gui.js:37 Error: The elevated process died unexpectedly
at createError (gui.js:37:219904)
at Object.createUserError (gui.js:37:220117)
at gui.js:341:5180
at async withTmpFile (gui.js:1:718820)
at async elevateCommand (gui.js:341:4411)
at async Server.<anonymous> (gui.js:341:8515)
Same with the latest preview v1.18.8. An older version I had at hand seems to work (1.5.120).
Also v1.10.4 seems to work just fine.
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
For anyone who came across this issue. On MacOS the default unarchiver can decompress an .xz image, while on Windows you can use 7zip archiver. As mentioned above, writing an uncompressed image will not show any issue. That's one way to work around this error until a fix arrives.