etcher 🚀 - "Unknown error" when writing .img.xz file on Windows

Hi @WasabiFan ,

Thanks for reporting this issue and the valuable information. Can you share a link to that exact same image you're trying to flash to see if I can reproduce? Also, you mention a .img.xz, but in the screenshot, I see an uncompressed .img instead.

Does this happen only with this image? If so, do you have another USB Drive or SD Card to try burning this exact same image to it, and see if the error still happens?

Regarding DevTools, is there a stack trace when expanding the Error object?

jviotti on 13 Jul 2016

Can you share a link to that exact same image you're trying to flash to see if I can reproduce?

Yep, it's here. It is the one called ev3-nightly-2016-07-13-bootroot.img.xz. The purpose of burning these images is to test this new nightly build system, so it is possible that the image is invalid; keep that in mind. Obviously, regardless of its validity, the burner should never throw these errors if it can be helped.

Also, you mention a .img.xz, but in the screenshot, I see an uncompressed .img instead.

Ah, unfortunate window placement :wink: It _is_ a .img.xz.

Does this happen only with this image? If so, do you have another USB Drive or SD Card to try burning this exact same image to it, and see if the error still happens?

I tried burning an image file that I know has worked with Etcher before, but I hit that "Starting..." bug 5 times in a row and gave up. Trying again, it happened another 4 times on that image and is continuing to happen on the original image as well. It got past the "Starting..." issue once after reinstalling Etcher (using the original image that I linked to), then started failing with various other errors which I believe there are already issues for. When I run it as administrator manually, I get this:

After reinstalling just now, I got this (which is again covered by #552):

None of it is reproducible or consistent, but it's definitely very broken. I have not yet gotten the original error on a known-good image, but I haven't gotten to the burn step either, so that doesn't tell us much. It does seem that the chance of getting to the 80% mark increases if Etcher has been freshly installed and was launched by the installer, but that is only conjecture. I have yet to get past the "Starting..." stage if I was prompted by UAC previously.

I can't get to the stage that would let me repro the original bug on a different storage device, either.

_Side note:_ The bug where the button just says "Starting..." seems to be caused by a race condition or other oversight that is making the main application wait for the child process indefinitely.

Regarding DevTools, is there a stack trace when expanding the Error object?

There is not, however if I add some breakpoints I can get a bit more information on what's happening. This is as much useful context as I can get:

But that doesn't seem to give much insight into what is actually happening.

WasabiFan on 13 Jul 2016

Hi @WasabiFan ,

Thanks a lot for the great amount of details about the issue.

I have no idea what could be causing this, but I see that just very few certain people are experiencing it, which makes me think there is a common system setting or something along those lines.

The application gets stuck at "Starting..." because it forks the writer process, and waits for it to emit progress state back to the parent process. I see you mentioned you were running the application as administrator. What happens if you run the application as a normal user, and go though the UAC elevation dialog (you do get it right?)?

I'll make a custom Etcher build for you from master with extra debugging information, to see if we can get to the bottom of it.

jviotti on 13 Jul 2016

I'm uploading the custom build. In the mid-time, can you test v1.0.0-beta.9? If the previous version works we can try bisecting Etcher to try to find the culprit. You can download v1.0.0-beta.9 from https://resin-production-downloads.s3.amazonaws.com/etcher/1.0.0-beta.9/Etcher-win32-x64.exe

jviotti on 13 Jul 2016

Since you are more developer-oriented, you might want to give the Etcher CLI a try, and see if that makes any difference. The Etcher CLI currently lives in this same repository, although is not being property released yet.

You can make use of it by cloning the repo and installing dependencies, as described in https://github.com/resin-io/etcher/blob/master/docs/CLI.md.

jviotti on 13 Jul 2016

I have no idea what could be causing this, but I see that just very few certain people are experiencing it, which makes me think there is a common system setting or something along those lines.

I know that I am running Windows Insider Preview builds, which can be unstable and break existing applications. Although I'd doubt that that is the problem as Microsoft is currently in the final stages of stabilizing for their Anniversary Update, it is something to consider. It's also possible that they changed something small intentionally that has side-effects.

I see you mentioned you were running the application as administrator. What happens if you run the application as a normal user, and go though the UAC elevation dialog (you do get it right?)?

Yes, I've tried launching it from the installer, from the Start menu, from CMD, and from Start as administrator. Launching it as admin seems to completely break Etcher, running it from CMD is no different from Start, and running it from the installer seems to increase the likelihood of getting past the "Starting..." message. The reason that I tried launching as administrator was because I noticed that I wasn't prompted when it was launched from the installer, and given my previous success on first install I posited that running as administrator may solve the problem. Interestingly, it seems to behave differently depending on whether it was run by the installer as administrator or by me as administrator. Again, this is all simply conjecture (and loosely-based conjecture at that) so don't consider these ramblings as fact.

I'll make a custom Etcher build for you from master with extra debugging information, to see if we can get to the bottom of it.

OK, sounds good! I'm happy to try that out and give you what you need.

In the mid-time, can you test v1.0.0-beta.9? If the previous version works we can try bisecting Etcher to try to find the culprit.

Yep, I'm working on testing the previous version now. However, assuming that you are referring to git bisect, I don't know how to run an Electron-based app from source; I'd need some tips on how to do that, but I'm willing to try the bisect if I can get some help with that build operation. Additionally, there are multiple issues here -- the two screenshotted most recently, the "Starting..." thing, and the nondescript error when it gets to 80%. Which would I be looking for?

Although I have no idea how Etcher and its modules are architected, it might simplify debugging in the future if the child process logged to a log file independent of the main Etcher application so that one could access more detailed textual logs even if the GUI was having problems or doesn't handle that information.

WasabiFan on 13 Jul 2016

Since you are more developer-oriented, you might want to give the Etcher CLI a try, and see if that makes any difference. The Etcher CLI currently lives in this same repository, although is not being property released yet.

I'll try that later today and see how it goes.

WasabiFan on 13 Jul 2016

I know that I am running Windows Insider Preview builds, which can be unstable and break existing applications. Although I'd doubt that that is the problem as Microsoft is currently in the final stages of stabilizing for their Anniversary Update, it is something to consider. It's also possible that they changed something small intentionally that has side-effects.

I doubt this is the issue. I remember a user reporting this one from Windows 10 Home.

Yep, I'm working on testing the previous version now. However, assuming that you are referring to git bisect, I don't know how to run an Electron-based app from source; I'd need some tips on how to do that, but I'm willing to try the bisect if I can get some help with that build operation. Additionally, there are multiple issues here -- the two screenshotted most recently, the "Starting..." thing, and the nondescript error when it gets to 80%. Which would I be looking for?

Bisecting Etcher yourself might be a pain, since you need to compile from source on every step (which requires Visual Studio 2013). I'm happy to assist you on it if you really want to do it, but otherwise lets hope my custom build reveals something worthy.

Although I have no idea how Etcher and its modules are architected, it might simplify debugging in the future if the child process logged to a log file independent of the main Etcher application so that one could access more detailed textual logs even if the GUI was having problems or doesn't handle that information.

Actually, the writer child process writes the progress to a temporary file, which is then tailed by the parent process. I'm logging the temporary file name on the custom build, so should be able to open it manually and see what's going on if needed.

jviotti on 13 Jul 2016

Here's the custom build: https://www.dropbox.com/s/lao6mcn1k0gvjyx/Etcher-win32-x64.exe?dl=0

jviotti on 13 Jul 2016

Downloading now. Anything special I should do (should I run the application from the command line?)?

WasabiFan on 13 Jul 2016

Nothing special should be necessary. Just install and run normally.

jviotti on 13 Jul 2016

BTW, thanks a lot for all the help so far. You're being super helpful and valuable debugging this issue! Very appreciated :)

jviotti on 13 Jul 2016

BTW, thanks a lot for all the help so far. You're being super helpful and valuable debugging this issue! Very appreciated :)

No problem! I know how hard it can be to attempt to provide project support to someone who can't stick with it to test things, and am willing to put the time in to make sure that this gets resolved. If it would be easier to chat in Gitter (as I see Etcher has a Gitter room), I'd be available for that in an hour or two and probably most of the time for the next few weeks.

After installing the test build, I allowed the installer to launch Etcher directly. I picked the image and it got to the 80% mark and then threw the original error, as expected. The UAC dialog did not come up, as presumably the installer launched it as admin. It doesn't look like there was much of interest that came out of the logs, but it does validate that the process is being elevated and seems to be running fine up until then. It's also worth noting that at least part of the image was successfully written, it's just not complete (the target device boots and displays the splash screen but then throws boot errors and panics).

You can find the output from both the dev console and the log file here.

I ran it again as a normal user and it threw the Command failed: diskpart /s... error. Running that command manually from an admin command prompt works without error. As one would assume, the console says STDOUT: Is elevated? false... tracker.js:10 STDOUT: Elevating! and I was prompted to allow it.

I ran it a third time, this time as administrator. It threw the "child process exited..." error. The dev console looked like this:

And the child process log only had a single line:

{"command":"error","data":{"message":"Command failed: diskpart /s \"C:\\Users\\<username>\\AppData\\Local\\Temp\\_diskpart-1468446780855\"\n"}}

Interestingly, this seems to be the same internal error as occurred previously, but something masked the internal error and instead just displayed the message about the process dying.
One thing I notice here is that there's a \n at the end. Is that line feed included when the command is executed? Given that the command runs fine when I do it manually, one thing to consider is that Windows may be unhappy about the \n instead of \r\n. Moreover, is it possible that those characters (\ and n) are literally being sent?

I am unable to find any builds of beta 9. I have a previously-downloaded copy of the beta 7 installer, but beta 9 (or any of the older versions) doesn't seem to be available anymore. If you can point me to a place I can find those installers, I can test out the older versions too.

WasabiFan on 14 Jul 2016

Etcher version: 1.0.0-beta.10
Operating system and architecture: Windows 10 x64, Version 1511 (Build 10586.494)

same problem as op trying to write debian-8.5.0-amd64-netinst.iso to a sandisk cruze 4gb flashdrive.

if you need more info from me let me know and I'll post it, still noob to all of this stuff.

jeffiscow on 14 Jul 2016

@jeffiscow Is it the same error in the developer console? Does it also stop at 80%?

_The developer console can be accessed via Ctrl+Alt+I_

@jviotti New piece of information: The same error, aside from slightly different messages as a result of more recent changes, occurs for me in beta 7. It seems like it might offer a slight bit more information -- you can see the error in the screenshot below. This does however show that this isn't a new issue, and judging by @jeffiscow's comment, it happens on vanilla WIndows 10 too.

WasabiFan on 14 Jul 2016

@WasabiFan im sorry but where in the dev console do I look?

Edit : @WasabiFan no it never even starts just gets to "starting..."

jeffiscow on 14 Jul 2016

Ah, I see -- yep, that's one of the issues that I'm seeing.

WasabiFan on 14 Jul 2016

Thank you very much for the huge help on this issue. You guys rock! This is all extremely weird, and I don't have anything in mind yet. I'll be focusing 100% of my time on this issue from now on, so we'll hopefully get it fixed very soon.

I'll try to get more clues about what's going on and will report back, and probably ask you some questions, or ask you to test anything soon.

Thanks a lot again!

jviotti on 14 Jul 2016

If you really have some spare time (you don't have to do it), you could test every Etcher version (there are not many luckily yet :) ) to attempt to identify in which one the issue started appearing:

[x] v1.0.0-beta.10: https://resin-production-downloads.s3.amazonaws.com/etcher/1.0.0-beta.10/Etcher-win32-x64.exe
[ ] v1.0.0-beta.9: https://resin-production-downloads.s3.amazonaws.com/etcher/1.0.0-beta.9/Etcher-win32-x64.exe
[ ] v1.0.0-beta.8: https://resin-production-downloads.s3.amazonaws.com/etcher/1.0.0-beta.8/Etcher-win32-x64.exe
[x] v1.0.0-beta.7: https://resin-production-downloads.s3.amazonaws.com/etcher/1.0.0-beta.7/Etcher-win32-x64.exe
[ ] v1.0.0-beta.6: https://resin-production-downloads.s3.amazonaws.com/etcher/1.0.0-beta.6/Etcher-win32-x64.exe
[ ] v1.0.0-beta.5: https://resin-production-downloads.s3.amazonaws.com/etcher/1.0.0-beta.5/Etcher-win32-x64.exe
[ ] v1.0.0-beta.4: https://resin-production-downloads.s3.amazonaws.com/etcher/1.0.0-beta.4/Etcher-win32-x64.exe
[ ] v1.0.0-beta.3: https://resin-production-downloads.s3.amazonaws.com/etcher/1.0.0-beta.3/Etcher-win32-x64.exe
[ ] v1.0.0-beta.2: https://resin-production-downloads.s3.amazonaws.com/etcher/1.0.0-beta.2/Etcher-win32-x64.exe
[ ] v1.0.0-beta.1: https://resin-production-downloads.s3.amazonaws.com/etcher/1.0.0-beta.1/Etcher-win32-x64.exe

Earlier versions were very unstable, so I wouldn't be surprised if they don't even work at all or exhibit other bugs that were fixed in newer versions :) Testing down to v1.0.0-beta.5 is probably enough.

jviotti on 14 Jul 2016

The error code we're getting is 4094. Sadly, Microsoft is really bad at giving more information about error codes, but this is what I've found:

The windows error code 4094 is generally generated due to errors reported by the driver itself meaning that this error is a software problem or compatibility issues between the hardware installed and the system being used. And it is very common and it is occurs when the operating system and the drivers installed are not companionable with each other.

I'd try opening the Device Manager and seeing if the operating system is reporting any errors for the drive you're trying to flash to. Did you test with other drives btw? Did the issue still happen?

jviotti on 14 Jul 2016

4094 is not even documented in https://msdn.microsoft.com/en-us/library/windows/desktop/ms681387(v=vs.85).aspx :sigh:

jviotti on 14 Jul 2016

If there was a weird I/O error with the drive, then diskpart failing might actually make sense. While the drive is connected, can you try the following?

Run diskpart.exe.
Run list disk to list the available drives. They'll have an ID number that should take note of.
Run select disk N, where N is the ID number above (make sure you type the right one to avoid wiping up your hard-drive!).
Run clean.
Run rescan.

Did diskpart complained in the process?

jviotti on 14 Jul 2016

I've uploaded a new custom build based on the previous one that includes extra debugging information to attempt to find out if diskpart provides any information about the reason it fails: https://www.dropbox.com/s/6b8g9jrx4157iub/Etcher-win32-x64-14-July-DISKPART-DEBUG.exe?dl=0

jviotti on 14 Jul 2016

I'l try the the things suggest above and get back to you when I get home in about 2 hours

jeffiscow on 14 Jul 2016

I manage to reproduce the diskpart and the Child process exitted with code: 1 a couple of times. It seems the recipe is:

Clean the drive with diskpart.
Create a "New Simple Volume" with the default options using diskmgmt.msc.
Run Etcher as Administrator.

Any variation of those steps causes the error to not appear for me.

I didn't find much about the cause yet, but I got the Child process exitted with code: 1 one and by manually inspecting the writer process logs, I can see its actually the same diskpart issue.

jviotti on 14 Jul 2016

The reason why the error gets sometimes masked seems to be because the child process emits the close event faster than the data coming from stderr at https://github.com/resin-io/etcher/blob/master/lib/src/child-writer/index.js#L92.

I believe this happens because of the interval when tailing the log file. We should ensure somehow that all data from the log file has been read and emitted before killing the process.

jviotti on 14 Jul 2016

Damn, I can't reproduce anymore, even with the steps outlined above :/

jviotti on 14 Jul 2016

beta 9: press "flash!" go to "starting..." the quickly back to "flash!" with nothing being written to flashdrive
beta 8: same as 9
beta 7: pressed the "flash!" button popup titled "Error" "An error ocurred!" button is stuck on "Starting..."
beta 6: go to flash get error https://drive.google.com/open?id=0B-Pp_HBf1mVBRjJGak9id01ES0k
beta 5: press the "flash" button gets stuck on "Starting..."
14-July-DISKPART-DEBUG.exe: error https://drive.google.com/open?id=0B-Pp_HBf1mVBYnR4QzZ4OWxrWDA

hope this helps

jeffiscow on 14 Jul 2016

If you really have some spare time (you don't have to do it), you could test every Etcher version (there are not many luckily yet :) ) to attempt to identify in which one the issue started appearing:

I can try out the older ones later today. Keep in mind that there are multiple issues we've mentioned here -- the "Starting..." thing, the "child process exited" error, and the generic "write" error at 80%. My guess is that the first two might be the same thing (and just the behavior is being differentiated by a race condition) but the latter one definitely isn't exactly the same.

I'd try opening the Device Manager and seeing if the operating system is reporting any errors for the drive you're trying to flash to. Did you test with other drives btw? Did the issue still happen?

Yes, I have tested with other devices; all of the issues previously mentioned also happen on other devices. Windows seems happy with the device based on the information in device manager.

If there was a weird I/O error with the drive, then diskpart failing might actually make sense. While the drive is connected, can you try the following?

I tried that and it worked without issue yesterday; I tried both running the exact command that Etcher runs (the one that passes the command file to diskpart) and running them manually, and it worked repeatedly without fail. When running the Etcher GUI or CLI though, I was seeing this error very frequently -- so much so that I couldn't get past it to test the error at 80%.

I manage to reproduce the diskpart and the Child process exitted with code: 1 a couple of times. It seems the recipe is...

I have been doing something similar; because Etcher (i.e. the utility that Etcher uses) only recognizes the drive if it already has a partition on it, I have been re-formatting the drive after each attempt to repro these issues because Etcher dies somewhere after wiping the drive. I haven't been running as administrator, but I have been doing the other two things.

The reason why the error gets sometimes masked seems to be because the child process emits the close event faster than the data coming from stderr at ...

Why don't you use stdout to receive progress events instead of the file? I imagine that would be more robust, but presumably you're doing it this way because that didn't work right.

I ran the new debug build and both the dev console and the log file are exactly the same as they were before. Where is the new debug information supposed to be?

On a whim, I decided to check the Windows event log to see if anything had been showing up there. Sure enough, I see a bunch of errors like this that correspond to me seeing the diskpart error:

Cannot zero sectors on disk \\?\PhysicalDrive3. Error code: 5@0101000F

This seems to be the most direct information on the root cause that we've seen. There are other mentions of that error string online, but based on my quick search, none of them seem applicable to our situation. I have tried running disk check, but it says both drives are fine. I still plan to do some more searching.

Based on what @jeffiscow posted (I haven't gotten a chance to try older versions myself) it appears that the diskpart error goes back to at least beta 6, maybe 5. That's interesting, as I was previously able to flash cards with Etcher without issue until I tried earlier this week.

WasabiFan on 14 Jul 2016

@WasabiFan Windows updated last night could that be a cause?

edit: updated for me anyway

jeffiscow on 14 Jul 2016

It is possible that a Windows update is causing this, but I believe we are on different versions of Windows, so that seems unlikely.

WasabiFan on 14 Jul 2016

I have been doing something similar; because Etcher (i.e. the utility that Etcher uses) only recognizes the drive if it already has a partition on it, I have been re-formatting the drive after each attempt to repro these issues because Etcher dies somewhere after wiping the drive. I haven't been running as administrator, but I have been doing the other two things.

Looks like drivelist considers a drive that doesn't have a file system as non-removable. I'll fix it very soon, thanks a lot for raising this up.

On a whim, I decided to check the Windows event log to see if anything had been showing up there. Sure enough, I see a bunch of errors like this that correspond to me seeing the diskpart error:
Cannot zero sectors on disk \\?\PhysicalDrive3. Error code: 5@0101000F

Amazing discoveries! I didn't know about the Windows Event Log thing (I'm a Mac guy), super helpful. I'll investigate why this is the case.

jviotti on 14 Jul 2016

I've been doing some investigation, and it seems that you have to make Windows "repair" the drive so clean succeeds. I'm still struggling to manage to reproduce the issue again, but I wonder what'd happen if we run chkdsk <driveletter>: /f right before clicking "Flash". Does that solve the issue?

Alternatively, I'm thinking the clean operation fails because Windows doesn't acknowledge recent changes to the drive (e.g: a format change). Another thing to try would be to run the rescan diskpart command _before_ clicking "Flash".

jviotti on 14 Jul 2016

The chkdsk /R option might be worth testing as well:

/R Locates bad sectors and recovers readable information (implies /F).

jviotti on 14 Jul 2016

According to this guy, running clean again after the error does the trick. We could run the command once, and if it fails, retry.

jviotti on 14 Jul 2016

Looks like drivelist considers a drive that doesn't have a file system as non-removable. I'll fix it very soon, thanks a lot for raising this up.

Ah, that's what it is called! I remembered reading about that module somewhere in this repo but couldn't remember the name. The file system discovery issue isn't a big problem, but yeah it would probably make it a bit easier.

I didn't know about the Windows Event Log thing (I'm a Mac guy), super helpful. I'll investigate why this is the case.

Haha yeah... it's a place that one rarely wants to go, because seeing the event log breaks the illusion that your PC is running fine. It's often full of error messages that one really doesn't want to know about :laughing:

It's very odd that diskpart doesn't return any of that information automatically, and instead makes you go searching for it. Definitely doesn't make debugging any easier!

I've been doing some investigation, and it seems that you have to make Windows "repair" the drive so clean succeeds. I'm still struggling to manage to reproduce the issue again, but I wonder what'd happen if we run chkdsk : /f right before clicking "Flash". Does that solve the issue?

I tried repairing and it didn't report any issues, but I haven't tried Etcher since, so it may have done something anyway. I can try that soon.

Yesterday I tried several times to repro the error using diskpart on the command line to no avail. Just now, however, I was able to do it, so I did some testing. This seems to indicate that you are either correct in that the rescan fixed it or in that the second clean did. See below.

DISKPART> list disk

  Disk ###  Status         Size     Free     Dyn  Gpt
  --------  -------------  -------  -------  ---  ---
  Disk 0    Online          238 GB      0 B        *
  Disk 1    Online          931 GB  1024 KB
  Disk 2    Online          931 GB      0 B
  Disk 3    Online         1901 MB      0 B

DISKPART> select disk 3

Disk 3 is now the selected disk.

DISKPART> clean

DiskPart has encountered an error: Access is denied.
See the System Event Log for more information.

DISKPART> rescan

Please wait while DiskPart scans your configuration...

DiskPart has finished scanning your configuration.

DISKPART> list disk

  Disk ###  Status         Size     Free     Dyn  Gpt
  --------  -------------  -------  -------  ---  ---
  Disk 0    Online          238 GB      0 B        *
  Disk 1    Online          931 GB  1024 KB
  Disk 2    Online          931 GB      0 B
* Disk 3    Online         1901 MB  1900 MB

DISKPART> clean

DiskPart succeeded in cleaning the disk.

WasabiFan on 14 Jul 2016

Looks promising! I'll quickly make a custom build that retries clean if an error happens, and we'll see how it goes.

jviotti on 14 Jul 2016

I ran the new debug build and both the dev console and the log file are exactly the same as they were before. Where is the new debug information supposed to be?

Agh, I hot-edited a dependency and then re-installed dependencies when packaging, so silly :)

jviotti on 14 Jul 2016

😄1

I've just uploaded three custom builds:

Retry once if clean fails: https://www.dropbox.com/s/8tpmvlmmsqap0x3/Etcher-win32-x64-ONE-RETRY.exe?dl=0
Retry up to ten times if clean fails: https://www.dropbox.com/s/hkhn2cx9dn595k6/Etcher-win32-x64-TEN-RETRIES.exe?dl=0
Run rescan before clean: https://www.dropbox.com/s/ezaw74x1g41173z/Etcher-win32-x64-RESCAN-BEFORE-CLEAN.exe?dl=0

Hopefully one of these fixes the issue.

jviotti on 14 Jul 2016

Wow, covering all your bases! I'll try them and report back.

WasabiFan on 14 Jul 2016

Using the "One retry" version, I ran it 6 times and every time it got past the "Starting..." phase when it previously threw the diskpart errors. I tried multiple drives and various other configurations, and every time it worked as it should have up to that point. It did not fix the later error (the original one mentioned in this issue), but as far as I can tell the diskpart ones are resolved. Reinstalling the standard beta 10 brought the error back first try.

So, I think that's the fix to go with. However, it would be great if it warned you in the dev console that it was retrying so that it was clear that it had hit that problem. That way, we could be sure that the retry logic was in fact activating and future debugging would probably be easier as well.

I think that, based on what I saw with the one-time version, ten times is probably unnecessary. Would you like me to also try the one that rescans?

Now, I think the main thing that we have to figure out is the "unknown error, write" issue, which now happens every time for me. @jeffiscow would you mind installing the version that @jviotti linked to entitled "ONE RETRY"? I'd like to know if you now see an error there like I do or if it works without issue.

WasabiFan on 15 Jul 2016

🎉1

@WasabiFan im getting a "Command failed: diskpart /s" "C:Users\USERNAME\AppData\Local\Temp_diskpart-1468535173355"

https://drive.google.com/open?id=0B-Pp_HBf1mVBZ0k3eVZaRVdvRW8

jeffiscow on 15 Jul 2016

Did you install Etcher from the link that @jviotti provided (https://www.dropbox.com/s/8tpmvlmmsqap0x3/Etcher-win32-x64-ONE-RETRY.exe?dl=0)?

WasabiFan on 15 Jul 2016

reinstalled to double check

Error: Child process exitted with error code: 1
    at ChildProcess.child.on (C:\Program Files (x86)\Etcher\resources\app.asar\lib\src\child-writer\index.js:106:38)
    at emitTwo (events.js:106:13)
    at ChildProcess.emit (events.js:191:7)
    at maybeClose (internal/child_process.js:850:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:215:5) `undefined`

jeffiscow on 15 Jul 2016

Interesting... I just tried it a few more times and I am still unable to get that error while running this new version.

WasabiFan on 15 Jul 2016

@WasabiFan Thanks a lot for the testing. Its awesome to hear the bug is gone for you. Regarding the build that rescans, if you can test that one, that'd be amazing. If the rescan one works fine as well I'd definitely go with that, given its a more elegant solution to the problem.

@jeffiscow Hm, I guess one retry is not enough for you. Do you mind quickly testing the other two builds I uploaded above as well (one that retries up to 10 times, and one that rescans the drive before attempting to clean it)?

jviotti on 15 Jul 2016

@WasabiFan

Now, I think the main thing that we have to figure out is the "unknown error, write" issue, which now happens every time for me.

Yeah, lets go for it now. Does it happen with every image/drive combination? I'd be really interested to hear if you can reproduce it with the CLI (https://github.com/resin-io/etcher/blob/master/docs/CLI.md).

jviotti on 15 Jul 2016

if you can test that one, that'd be amazing. If the rescan one works fine as well I'd definitely go with that, given its a more elegant solution to the problem.

Unfortunately, after running it a few times, it looks like the rescan does not fix the problem; I got the diskpart error every time.

Yeah, lets go for it now. Does it happen with every image/drive combination?

Using an image that I know has worked with Etcher in the past, the flash completed successfully. However, running it using the image that I was trying originally, it consistently throws the error.

Doing a bit of digging, I think I have uncovered the problem: the image is 4GB instead of the ~0.5 that I was expecting. Burning a 4GB image to a 2GB card is obviously not going to work. So, switching to a 16GB card, Etcher finished successfully.

The takeaway here is that I think Etcher needs to validate that the image you are trying to use will fit. Can that be done easily? Or is it already supposed to be happening?

I guess it's time to open an issue on the project that created the image to figure out why the images have grown 😆

WasabiFan on 15 Jul 2016

I do believe Etcher already guards against that case. I wonder why it
didn't in this case, and if it may be linked to the issue.

_Alexandros Marinos_

Founder & CEO, Resin.io

+1 206-637-5498

@alexandrosm

On Fri, Jul 15, 2016 at 11:38 AM, Wasabi Fan [email protected]
wrote:

if you can test that one, that'd be amazing. If the rescan one works fine
as well I'd definitely go with that, given its a more elegant solution to
the problem.

Unfortunately, after running it a few times, it looks like the rescan does
not fix the problem; I got the diskpart error every time.

Yeah, lets go for it now. Does it happen with every image/drive
combination?

Using an image that I know has worked with Etcher in the past, the flash
completed successfully. However, running it using the image that I was
trying originally, it consistently throws the error.

Doing a bit of digging, I think I have uncovered the problem: the image is
4GB instead of the ~0.5 that I was expecting. Burning a 4GB image to a 2GB
card is obviously not going to work. So, switching to a 16GB card, Etcher
finished successfully.

The takeaway here is that I think Etcher needs to validate that the image
you are trying to use will fit. Can that be done easily? Or is it already

supposed to be happening?

I guess it's time to open an issue on the project that created the image
to figure out why the images have grown 😆

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/resin-io/etcher/issues/571#issuecomment-233033358,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABLUCMfdocWjcwqOHuvJQJt1JH4r3DzVks5qV9OagaJpZM4JLE0-
.

alexandrosm on 15 Jul 2016

We indeed make that check. I'm thinking there is either some subtle way to bypass it accidentally or drivelist, which is module reporting the drive size, is reporting an incorrect size for that specific drives.

Can you run this script (https://github.com/resin-io-modules/drivelist/blob/master/scripts/win32.bat) when the drive is plugged in and report back that it outputs?

Also, did the problematic drive used to get auto-selected? If so, can show us what you get when clicking the "Change" label below the second drive? The label opens the drive selector modal, which should show a warning label if it detects the drive is not large enough.

jviotti on 16 Jul 2016

Here's the drive-specific output for one of them:

device: "\\\\.\\PHYSICALDRIVE3"
description: "Generic Flash Disk USB Device"
size: 1990517760
mountpoint: Null
name: Null
system: True

And the other one:

device: "\\\\.\\PHYSICALDRIVE3"
description: "Multi Flash Reader USB Device"
size: 2031644160
mountpoint: "H:"
name: "H:"
protected: False
system: False

Etcher correctly determines that the drive is 2GB in the menus as well, but does not show any warning.

WasabiFan on 16 Jul 2016

Ok, I believe I know what's going on. The logic that retrieves the size of the image, does so ignoring compression, so the code gets the size of the _compressed_ image. This passes the check that image size <= drive size and therefore doesn't throw any error, but the image is in reality ~3.7GB.

I believe there is an easy way to fix this, given we do have access to the uncompressed image size in a certain point, so I'll hope I'll be pushing a fix very soon.

I'm very happy we got to the bottom of both bugs though, your help was really valuable, so thanks a lot for that! :)

jviotti on 18 Jul 2016

I'm glad to hear that you found the problem! Happy I could be helpful.

WasabiFan on 18 Jul 2016

Etcher: "Unknown error" when writing .img.xz file on Windows

All 53 comments

supposed to be happening?

Related issues