etcher
etcher copied to clipboard
Flash Failed reported on successful flash due to screensaver error
- Etcher version: 1.8.11
- Operating system and architecture: Windows 11 x64
- Image flashed: raspbx-04-04-2018.img (and other raspbx images)
- What do you think should have happened: No error report on successful flash
- What happened: Error reported on successful flash
- Do you see any meaningful error information in the DevTools?
Flash reported as failed despite success on two different Windows 11 machines
Error
gui.js:37 Error: Error invoking remote method 'enable-screensaver': No handler registered for 'enable-screensaver' at o.invoke (node:electron/js2c/renderer_init:57:526)
See also https://github.com/balena-io/etcher/issues?q=is%3Aissue+is%3Aopen+screensaver :wink:
Thanks, @lurch! Should I mark as duplicate? Is there a master case for this? Is it recognized as an issue?
@phillipremaker I don't know, I don't work on Etcher.
The enable-screensaver
error is unrelated to what you describe.
Your problem might come from not being able to unmount the disks at the end of the process, hard to tell.
Thanks @aethernet! Any suggestions of how to do a diagnostic around that? I can't tell why the code has decided the flash process had failed.
I got the same issue yesterday on one of my test flash, but I don't have a solid reproduction yet
I'm suspecting it has to do with the OS mounting the drive before the checks are done, but idk yet how to confirm.
@zvin Can I ask you to look at this? This problem seems to correspond to the electron.ipcRenderer.send changing to electron.ipcRenderer.invoke for the enable-screensave and disable-screensaver calls in #3882.
Windows 11 does not handle these calls correctly, and it seems that the error from these calls mistakenly triggers a Flash Failed for ALL Flash attempts with Windows 11 and Etcher.
I'm not sure what the best fix is.
- Roll back #3882
- Have ipcRenderer apporpriately disable Windows 11 screensaver.
- Have ipcRendered recognize that it can't control Windows 11 screensaver and suppress the error
- Have the error process recognize that an error from the screensaver is not a flash failure.
Not knowing the architecture of the system, I don't know what the fix is. But as it stands now, a lot of people using Etcher on Windows 11 get a flash failed error even when it is successful.
Cc: @builder555 who approved the original patch. Can't seem to tag the original patch author.
More details: Fails on the PCI flash on the motherboard, works on a USB-C reader. So the issue seems to be related to the flash hardware, possibly the unmount. The screensaver error is superfluous, as @aethernet noted. Will do some more tests.
Just to add on and clarify, indeed, the failed message is not from the screensaver issue as aethernet suggests: you can note that there is an earlier error in the console pre-flash that does not get reported as failure, at least not at the time. One should instead open, on the line just above, the Flash results object > results > errors > 0 to see the failure that the program is actually reporting.
In my case, at least, this error is a failure in the checksum (across the entire range, [0, blockmappedSize-1]). It's unclear to me if etcher has another method besides pure checksumming that would be useful to determine when in time or on disk the expected values diverge, but if it did and it would be helpful for those to be reported, please let us know. (Or alternatively if we should be directing to a different issue)
In a previous life, I had different flash hardware report a different checksum because one used an 8-bit read boundary and one a 16-bit read boundary, and the 16-bit hardware produced a different checksum on odd-byte sizes images since it included 8 bits of superfluous data not in the file on a checksum. I know nothing about how checksums are calculated in Etcher or if the OS abstraction hides that kind of thing, just a thought in case USB and PCIe hardware drivers do the magick differently.