It was recently discovered that there is a bug in the Recovery Loader which could cause installation of the factory image to fail. The Recovery Loader would successfully launch, the user would access the Recovery Loader http page, select and upload the factory installation file, and then wait for the router to reboot, but the image would not install and the router would boot with whatever image was previously installed.
In some cases this issue might even cause the Recovery Loader to not load at all, and the router boots as if the reset button had not been held down.
There were hints in the past that the Recovery Loader wasn't always reliable, but until now I had not been able to reproduce the problem.
The issue is caused by an environmental scenario which only occurs in certain circumstances. The Recovery Loader looks for an active network interface with layer-1/PHY up, but it does not stop the normal boot process or give enough time for some network interfaces on some PCs or switches to come up. The result is that the router could begin the normal boot process before the Recovery Loader senses an attached network interface. If the boot process gets far enough along, this will interfere with the Recovery Loader's installation process and the image will not install. It is even possible that if the attached PC or switch interface is slow enough, the router might fully boot and the Recovery Loader will never load.
This bug is in Trendnet's u-boot code and is not specific to OpenWRT images. The problem can also cause the OEM factory images to fail to install from the Recovery Loader as well.
I have added a workaround to my OpenWRT images which should allow the installation of the factory image from the Recovery Loader when this issue occurs. Images built on and after 2020-05-09 have this workaround.
It is also possible to avoid the issue all together by attaching to the router with a network interface which comes up fast. For example, my Pluggable USB ethernet adapter which uses an ASIX AX88179 chip never experiences this issue, but if I put a 5-port switch in between my computer and the router, the problem always occurs.
Unfortunately, without serial console access, there is no clear indicator which a user can look for to know if this bug is happening. The Recovery Loader web page doesn't provide any useful feedback.
The only way to know for sure if you have been afflicted by this bug is to get a serial console and look at the boot messages.
In older versions of my OpenWRT images, the issue can be identified by looking for serial console messages indicating that the UBI MTD has been assembled/attached before the Recovery Loader's "backup_mode_handle Using ethX device" message is seen, and then a "Failed to set ipq_nand: Quitting." message is given when attempting to install the factory image. Each main() loop in which the Recovery Loader fails to bring up a network interface is indicated by a "fail WHY" message (which I suspect is an engrish/typo for "fail PHY").