Hey, are you running under an admin or normal user account? The flashing process needs to be able to elevate to admin privileges in order to write directly to the SD card
Edit:
Sorry I didn’t notice you did already attach the logs in your initial message. Having a look at those, seems like the root issue is this diskpart error: Couldn't clean the drive, Command failed: diskpart We will keep looking into this and get back to you as soon as we figure out what may cause the error.
Tryed flashing with win32 disk manager and it worked perfectly.
Tryed again with etcher and it failed again.
Note that after failure my SD card isn’t recognized by my computer anymore.
Disk manager tells me the volume isn’t allocated anymore and I can fix it only with diskpart so far.
Hi, the SD card isn’t recognized by the computer anymore due to the nature of the image - the partition need to be made so that Windows can read them, otherwise you won’t see the target in the file explorer after flashing.
Does the image require special treatment (e.g. to make it bootable) to your knowledge? Some images need extra steps in order to function properly and for that reason, Etcher isn’t the best tool (yet ) for those, as it just copies raw data 1:1 like dd does.
Also, on Windows we wait writing the first bytes of the image because we can’t get exclusive access to the target, which means Windows would try mounting it mid-flash, and it can cause some inconsistencies on the verification.
Did you try using the image you just flashed to check that it works even though the verification fails?
I wanted to comment I am having the same issue on my Win10 machine. I’m using balenaEtcher v1.5.70 on my windows machine which is running an Evaluation copy, Build 19536.rs_prelease.191211-1446.
I formatted the microSD to exFAT (Etcher when it starts wipes this)
I extracted the ISO from the Zipped file
Used a different USB adaptor
Rebooted my PC
Tried several other images (Fedora, BlackArch & Kali).
Used a USB drive rather than the SD card (Innostor USB 4.03 GB)
I gave up on Etcher and tried Rufus (v3.1.1320) and it seemed to work fine.
UPDATE
Problem Solved, at least in my case. I have Controlled Folder Access enabled. For some reason balenaEtcher was trying to write to a folder under My Documents (In my case this is D:). I authorized it to access that controlled folder and it was able to burn the file. I’m uninstalling the program for now, I don’t really like a program writing to My Documents without a good reason.
Tank you for posting this detailed information on the error and the update on how you fixed it. The reason balenaEtcher is writting to your Documents folder, is because it is storing its settings into a subfolder of your documents folder.
Hi, if there are leftover files, they are likely to be in the folder C:\Users\<username>\AppData\Local\. That’s typically where electron apps store config files by default, and compatibility is the reason we kept that location.
I noticed that the removal process was not complete. I used the Apps & Features to select and remove balenaEtcher. However, I saw that it left behind:
C:\Users<username>\AppData\Local\balena-etcher-updater\installer.exe
Under protected folders, it says “Windows system folders are protected by default.” I wouldn’t expect C:\Users<username>\AppData\Local\ to fall under that grouping. In addition I am protecting;
D:\
C:\Users\Public\Documents
D:\My Pictures
C:\Users\Public\Videos
C:\Users<username>\Videos
D:\Music
C:\Users\Public\Music
C:\Users<username>\Favorites
So I don’t understand why Controlled Folders would stop balenaEtcher if it is only using the AppData folder(s). That is where it belongs.
While the cause isn’t clear, it is probably due to the fact that Etcher uses system resources to perform actions such as writing, which behave differently on the different OSes.
For example on Windows we circumvent the lack of exclusive access to targets by offsetting the first bytes written and writing them at last to prevent Windows mounting the image mid-flash.
Controlled folder access checks the applications against a “known list”, and every new version of Etcher unfortunately counts as a new application unless it’s updated via auto-updates (which we trigger ourselves for specific versions), which means it’ll be flagged as a threat more often than not even though it is not.
As for the leftover files, there’s not much we can do, it’s just how the installer works as of now. We’re still improving all the bits and pieces though, so it might be something we’ll try to revisit in the future
I was suffering from this issue. I had a CAC/PIV in my Mac, which changes the Mac OS authentication to CAC/PIV PIN instead of password. When authenticating for Etcher, I used the CAC/PIV PIN and it proceeded – but kept throwing this error.
Simple duh solution: Pull the CAC/PIV card out. Restarted Etcher, authenticated with password, worked as advertised.