The problem is as described in the topic.
The flashing was made without any issues.
I was carefully observing the whole flashing process and saw nothing disturbing.
And the problem at validation is at 99% - it’s written “flash failed” without any error code.
I suspect the whole flashing process was successful. I just don’t know why it shows “flash failed” only at 99%. The SD card being flashed is 256Gb Sandisk Extreme PRO, V30.
The BalenaEtcher version I’m running = 1.7.3 portable;
The operating system I’m running Etcher in = Windows PRO 64bit;
Windows Disk Management shows “no media” after SD card being flashed, but I’ve read this post on your blog, so I’m cool about it.
I have 3 SD cards of that model, and flashing/validation failed on all of them at 99% validation.
balenaEtcher verification failed at 99 percent.log (50.8 KB)
On the positive side of things I was able to successfully flash Raspberry Pi OS to my Samsung USB stick the day before. Also from computer with Windows PRO 64bit.
Is there any way I can manually check if the flashing was completed successfully?
A simple link to the process of manual verification would be fine.
Hi, unfortunately there’s really no way to manually verify the disk other than just trying to use it. Unix machines all run e2fsck before starting up, so there should be an error in the logs if the file system is corrupted.
Regarding the verification failure, I see in the logs it says:
"Error: certificate has expired\n at TLSSocket.onConnectSecure (_tls_wrap.js:1497:34)\n at TLSSocket.emit (events.js:315:20)\n at TLSSocket._finishInit (_tls_wrap.js:932:8)\n at TLSWrap.ssl.onhandshakedone (_tls_wrap.js:706:12)","config":{"url":"https://balena.io/etcher/static/config.json","method":"get","headers":{"Accept":"application/json, text/plain, */*","User-Agent":"axios/1.7.3"},"transformRequest":[null],"transformResponse":[null],"timeout":0,"responseType":"json","xsrfCookieName":"XSRF-TOKEN","xsrfHeaderName":"X-XSRF-TOKEN","maxContentLength":-1,"maxBodyLength":-1,"transitional":
Which I have seen in a previous ticket regarding verification errors, so I’m thinking they might be related, although I will have to test this to be sure. It looks like the write was actually successful though. Can you try the the flashed disk and run journalctl -a | grep e2fsck and share the output?