
This is the error window came up on screen:

@rahul606 I'm guessing this error occurred in the middle of trying to write the image? Do you remember how far through it got? Does it work if you simply retry writing the image, or does it fail again? What image is it that you're trying to write?
@jviotti I thought you changed the JSON error-handling to display the complete message when we get invalid JSON? Or did that change come after the release of beta17?
@lurch We're displaying the message already, which in this case is literally:
events.js:160
throw er; // Unhandled 'error' event
^
(thus the unexpected "e" token from events.js)
Sadly this gives us very little information to move forward :S The exception comes from the CLI, but we have no clue about that could have caused this. The fact that the error talks about "error" events points me to etcher-image-write (etcher-image-stream also deals with streams, but it passes it directly to etcher-image-write, which is the entity responsible for handling errors in them anyway), so the assumption is that some stream in there is failing, for which we're not attaching an error handler, which is weird, since we make use of a utility called .safePipe() to ensure an error handler is attached everywhere.
@rahul606 What image were you trying to flash? Was it a compressed image (e.g: .xz, .gz, .zip, etc) If its a compressed one, can you reliably reproduce? Do you mind linking us to it so we can try it here?
Also, at which point did the error happen? Was it validating already, or was it flashing? Did it happen as soon as you clicked "Flash", half-way through, or near to the end?
@lurch @jviotti I am trying the image of raspberry pi and also did with ubuntu Mate none of it worked and stopped after 18% during validating. Also I tried many times with different SD cards but happens every time the same error. For your reference I am here attaching the .img file links:

@lurch @jviotti one another thing when I am trying it to run locally GUI is working good but with CLI I am having this error:
module.js:597
return process.dlopen(module, path._makeLong(filename));
^
Error: Module version mismatch. Expected 48, got 50.
at Error (native)
at Object.Module._extensions..node (module.js:597:18)
at Module.load (module.js:487:32)
at tryModuleLoad (module.js:446:12)
at Function.Module._load (module.js:438:3)
at Module.require (module.js:497:17)
at require (internal/module.js:20:19)
at /Users/rahultomar/Documents/etcher/node_modules/lzma-native/index.js:14:14
at Object.<anonymous> (/Users/rahultomar/Documents/etcher/node_modules/lzma-native/index.js:626:3)
at Module._compile (module.js:570:32)
at Object.Module._extensions..js (module.js:579:10)
at Module.load (module.js:487:32)
at tryModuleLoad (module.js:446:12)
at Function.Module._load (module.js:438:3)
at Module.require (module.js:497:17)
at require (internal/module.js:20:19)
at Object.<anonymous> (/Users/rahultomar/Documents/etcher/node_modules/etcher-image-stream/lib/handlers.js:22:36)
at Module._compile (module.js:570:32)
at Object.Module._extensions..js (module.js:579:10)
at Module.load (module.js:487:32)
at tryModuleLoad (module.js:446:12)
at Function.Module._load (module.js:438:3)
at Module.require (module.js:497:17)
at require (internal/module.js:20:19)
at Object.<anonymous> (/Users/rahultomar/Documents/etcher/node_modules/etcher-image-stream/lib/index.js:26:18)
at Module._compile (module.js:570:32)
at Object.Module._extensions..js (module.js:579:10)
at Module.load (module.js:487:32)
at tryModuleLoad (module.js:446:12)
at Function.Module._load (module.js:438:3)
at Module.require (module.js:497:17)
at require (internal/module.js:20:19)
at Object.<anonymous> (/Users/rahultomar/Documents/etcher/lib/cli/writer.js:20:21)
at Module._compile (module.js:570:32)
Just an heads up by running "npm install lzma-native@latest" on root folder eliminates the above mentioned error in case of CLI run. And now after running the CLI we have the same error like GUI run:

@rahul606 the issue about only one of the GUI or CLI working at a time is a known problem, and something that we're working towards fixing (technical details: the GUI (based on Electron) and CLI use different versions of NodeJS, and so each need the lzma-native module linked against a different ABI version)
Does it always fail at 18%, even for different SD cards? That sounds _very_ odd if so.
Do your "different SD cards" have different sizes, different brands, etc. or are they all the same brand and model?
Would you be willing to test one of the 'failing' SD cards with http://oss.digirati.com.br/f3/ (to rule out the SD card being faulty)
Do you maybe have a different USB SD card reader that you're able to test with? (to rule out your current card reader being faulty)
Thanks!
Well, its not an error, but rather that you're jumping between NodeJS versions that are not ABI compatible. If you installed the dependencies to target Electron (using make electron-develop), you have to re-install (the non-native dependencies) to build agains your current NodeJS version if you want the Etcher CLI to run.
@lurch suggestions are spot on.
In any case, this means we're not handling a potential error in one of the streams during validation. I'll fix that soon.
@lurch problem of CLI is solved, it was in etcher-image-stream due to old version of lzma-native package, which I have committed in that repository.
Error during validation happens sometimes on 18% and sometimes on 10% with the same SD card. So, the percentage even changed after changing the card. Cards are okay because I am able to flash the image via Terminal with bash command instead of using any software to do this.
Cards are okay because I am able to flash the image via Terminal with bash command instead of using any software to do this.
Okay, but you wrote above that it's only during the verification step of Etcher that you got the error, which means that Etcher itself also wrote the image fine. Using bash commands only writes the image, it doesn't verify it. That's why I asked you to test using F3. So if you wouldn't mind giving that a go please?
F3 is not working. I have downloaded the application and clicked the "Start Test". Test never ends even after 3 hours for SanDisk 32GB card. I have no idea what does this means.
@lurch @jviotti So today I bought the new SD Card and software works perfectly fine on it. Which definitely means my earlier 2 SD Cards are defective. But I do not understand what is the defect because image is flashing on it and I can start Ubuntu Mate with them also RPi. I can work on the OS like web browsing, files editing and saving. So, what exactly validation fails means for the SD Card ???
So today I bought the new SD Card and software works perfectly fine on it.
Woohoo! :tada:
But I do not understand what is the defect because image is flashing on it and I can start Ubuntu Mate with them also RPi.
Hmmm, that's really weird. I guess it's possible that there's occasional small random errors on the card which are enough to trip up Etcher's verification, but still small enough to allow the OS to boot from it correctly?
So that we could investigate the problem ourselves, would you be willing to send us one or both of your failing cards, in exchange for brand new replacement cards of the same size? Please send me an email to andrews \@ resin.io (obviously removing the spaces).
Also, do you remember where you bought the cards from?
Very nice! Its weird that the EIO errors happen during reading (validating), rather than during writing. This PR, which retries various times in case of an EIO might be the solution: https://github.com/resin-io-modules/etcher-image-write/pull/70, however its still a work in progress.
I like the idea of retrieving malfunctioning SDCards. Maybe we can even promote this somehow in the website? Like: if you have SDCards that exhibit weird behaviour, please send them to us for debugging purposes. I'll raise this up with the operations team.
Background info: Myself and @rahul606 have now been in touch with each other via email, and @rahul606 is sending his faulty SD cards to @lurch , and I've arranged for the https://resin.io operations team to send @rahul606 some replacement SD cards :-)
Woohoo! :tada: Thank you very much @rahul606! That will hopefully allow us to validate our EIO fix.
@lurch Any updates on the SDCards? Have they been sent?
I've just merged https://github.com/resin-io-modules/etcher-image-write/pull/73, which (I highly believe) fixes EIO errors during writing, and will be working on the same fix for during validation.
I was able to reproduce this exact same error on one of the Appveyor builds: https://ci.appveyor.com/project/resin-io/etcher-image-write/build/1.0.159. Let's hope I can actively reproduce, and if so, I should be able to fix the issue.
Ah, not the exact same one sadly. This one says "Error: EBADF: bad file descriptor, read" instead of EIO...
Turns out I can locally reproduce the EBADF error with the correct NodeJS/npm versions. The good news is that this new error comes from the same "unhandled error" location, so if I find a way to handle it, we should get better information about the error from this issue.
The new error also happens during the validation phase, so we're definitely dealing with the same unhandled scenario.
I've found the place where an error event is not being handler: a silly subtle logical error: https://github.com/resin-io-modules/etcher-image-write/pull/75 :)
Now let's try to fix to real issues behind it.
Damn, closed accidentally. Re-opening...
I sent a PR which I believe fixes this issue: https://github.com/resin-io/etcher/issues/1000.
I'll send a custom build with the patch applied so we can test in the mid time soon.
Here's the build: https://drive.google.com/file/d/0B7tkbonGU-RyR1pRdVB6bUUzWlU/view?usp=sharing
Let me know if this fixes the issue for you! Thanks a lot!
Most helpful comment
Background info: Myself and @rahul606 have now been in touch with each other via email, and @rahul606 is sending his faulty SD cards to @lurch , and I've arranged for the https://resin.io operations team to send @rahul606 some replacement SD cards :-)