Hi everyone! After the system update, I was faced with the inability to boot the device.
I ran the following to try and recover the device:
I tried to reset the settings by holding the Reboot button (until it started blinking) - it didn’t help;
I tried to boot into the netinstall as indicated in the manual (by holding down the reboot button until the “user” indicator goes out) - it did not help.
I installed the DHCP server on my PC to check whether the device requests an address for downloading - no, it does not.
I installed TinyPXE on a PC to see if the device could boot from it - no, it doesn’t ask to boot.
I tried to read the SPI flash (I have a GigaDevice 25Q127CSIG chip installed) from the board to find out if it contained something - no, when read by the programmer there were only zeros (only FFFF in bin file).
Maybe it is possible to use the file routeros-arm-7.11.2.npk to restore the SPI using the programmer? Maybe you found a solution to the problem? Maybe you can use the UART+SPI contacts. If so, then how to do it correctly. Thanks for answers!
Wow, you’re trying way too hard. If you went through the Netinstall troubleshooting procedure to no avail (search for tips on the forums), it’s probably gone.
Netinstall is the only viable option. By erasing the chip or replacing it, you also lose the ROS licence assigned to the device at the factory. So unless you plan to use OpenWrt…
I have 2 of these, and they work a lot better on the v6 firmware branch IMO.
I have one (the international version though), using it primarily as router (and secondarily as AP) … and works much better under v7 (act of upgrading from v6 to v7 was netinstall and configuration from defaults). I’m attributing that to the fact that I did gazillion of changes in v6 and I guess there were some things that were bogging the device (so probably netinstalling the device with v6 would unleash the power as well).
Hello, everyone! I wanted to let you know that I managed to overcome the problem.
At some point, I managed to boot the device into “initramfs” mode (OpenWRT in RAM) through the Tiny PXE server. After booting up, I made sure that the hardware of hAP ac² was working properly. Next, I checked which version of the bootloader is currently installed (command in OpenVRT “cat /sys/firmware/mikrotik/hard_config/booter_version”). In my case, it was release 6.48.6, but after downloading the nearest version of netinstall (this is Release 6.49), I somehow miraculously managed to boot the device through netinstall. And then everything follows the instructions in the usual way.
P.S.1. I spent a lot of time on different attempts and seemed to do everything as indicated in the instructions. I’m honestly surprised what happened this time, that I managed to find exactly the right version of netinstall and boot successfully.
P.S.2. After restoring the device, I was still unable to read the SPI flash. Maybe I’m doing something wrong, maybe there is read protection installed there. I’m not sure.
My situation is similar to yours. I have 2 wAp ac wireless APs and I set them as managed by CAPsMAN. In the beginning they work properly, after several hours they 2 all suddenly POWER-OFF and no longer get connected to ethernet. I hold the reset button for 15 seconds to carry out netinstall and expect them to get reconnected but they are still offline. Winbox cannot find them. However, I still don’t know how to deal with it consequently.
What exactly is your device model? I ask because when I was looking for a solution to my problem, I found information that in some devices, to reset, you need to short-circuit special contacts on the board.
The AP cannot be recognized by netinstall of 7.11.2 stable but 7.12beta9 successfully found the RouterBOARD and rewrote RouteOS. My AP is brought back to life. I guess 7.11.2 stable, both RouterOS and netinstall, has some bugs, at least on wAPac (RBwAPG-5HacD2HnD).
Again, I agree there may be an issue with netinstall on 7.11.2.
Enough reports here to support that statement.
But regular operation, not that I know of.
My capsman setup was also upgraded using remote cap - upgrade ( coming from 7.10).
None of the 15 devices failed to do so.
2 weeks ago I updated roughly 20 other devices to 7.11.2, all remotely. None failed.