Validation fails after 100% complete

balenaEtcher
1

I’m flashing the Raspberry Pi image of DAKBoard to a 16G microusb card. I’m using Windows 10 64 bit and Etcher version 1.7.9.

The flashing portion completes with no errors. Validation completes - all the way, 100% - with no errors, but Etcher says that validation failed. The image has a small FAT32 boot partition and a larger EXT4 partition. Per one of your previous forum posts, I do see where Windows has created a System Volume Information folder in the FAT32 partition - is this why validation is failing? Is there a way to keep Windows from doing this, if so?

The resulting image on the USB card fails to boot on the Raspberry PI. Is Etcher writing something to the drive after validation, and the lack of this is causing problems? I would have thought that everything would have been written during the flashing portion and validation was just checking to see if everything had been written successfully.

I’ve deleted the partition and checked the drive with MiniTool Partition Wizard, and it found no errors. After recreating the partition and flashing again with Etcher, validation failed at 100% complete.

I’m very confused!

Thanks,
Bob

2

Hi Bob,

I tried with a DAKBoard image, I downloaded from their support site.
The flash and the verification was completed successfully.

Can you tell which exact image you used, so we can have a closer look?

The verification failing sometimes is just a misleading message towards the user. (The verification is OK just the message display encounters some error while displaying the message and says verification failed instead of displaying the message failed)
But this case the device should boot.
To have a closer look you can open the devtools by pressing Ctrl + Alt + i , and examine the logs on the console tab.
If you can copy them and attach it here we could have a look too.

Can you tell us which RPi model you use?

One thing I can think of, is an old SD card which got corrupted, do you have an other one to try?

Thanks,
Peter

4

Hi, Peter!

The image I flashed was probably the same one you used. I only downloaded it a few weeks ago, and the image is datestamped 6/15/2022. I’m using a Raspberry Pi 3B+.

I’ve attached the console log to this email. I did notice that at the bottom of it, it does say that it completed 100% with no errors.

I suspect you’re correct on the corrupted micro-usb card. I bought another one and it flashed successfully and booted on the Pi. It just seems odd that it makes it through both flashing and verification with no indication of issues, yet it won’t work in the Pi. I had managed to flash this chip successfully previously. There’s no power switch on the Pi, so the only way to turn it off was to turn off the power to it. This might have caused the problem.

Thanks,

Bob
Etcher_Log.log (98.6 KB)

6

Flash failed after 100% validating

image
image809×511 28.7 KB

7

Please Help any idea how to solve this problem

8

here is the console log

Failed to load resource: net::ERR_FILE_NOT_FOUND
gui.js:354 _____ _ _
| | | | |
| | | | | | ___ _ __
| || / | ’ \ / _ \ '|
| || || (| | | | / |
_/ ____|| ||___||

Interested in joining the Etcher team?
Drop us a line at join+etcher@balena.io

Version = 1.18.4, Type = nsis
gui.js:37 Error: Error invoking remote method ‘disable-screensaver’: No handler registered for ‘disable-screensaver’
at o.invoke (node:electron/js2c/renderer_init:57:526)
(anonymous) @ gui.js:37
gui.js:37 Elevating command: C:\Users\Fiberhome\AppData\Local\Programs\balena-etcher\balenaEtcher.exe C:\Users\Fiberhome\AppData\Local\Programs\balena-etcher\resources\app\generated\child-writer.js
gui.js:35 0 devices, 0% at 0.00 MB/s (total 0.00 MB/s) with 0 failed devices
gui.js:37 Successfully connected to IPC server: etcher-server-10888, socket root C:\Users\FIBERH~1\AppData\Local\Temp
gui.js:37 Image: D:\CIO\LPB FIRMWARE\V15.4-LPBPisoWifiV2OrangePi Release-v15.4.img
gui.js:37 Devices: \.\PhysicalDrive2
gui.js:37 Auto blockmapping: false

9

how do you access the log?

10

To troubleshoot the situation, there are a few steps you can take. First, verify the integrity of the DAKBoard image file to ensure it’s not corrupted. Check the official source from where you downloaded the image and compare the MD5 or SHA checksum with the provided values. This step confirms the file’s integrity.
If the image is intact, consider trying alternative flashing tools such as Win32 Disk Image or Raspberry Pi Imager. These tools might provide a different result and help identify the root cause.