Well, the actual whole picture here would be that our support team wanted to find out firstly what is the reason why you “must” upgrade the bootloader and just wanted to look into this deeper and help not just to you but also to others by doing some global changes if necessary. Unfortunately, after that, this turns out to be a complaint in forum about unprofessional technical support.
Of course mistakes happen, but 99.9% of cases the questions support ask are with some deeper thought which the end-user might not know or understand. Yes, we can, of course, as anyone else, improve communication, but asking for a supout file is kind of a prerequisite if there is any kind of problem with the router.
In the current situation, our support engineer wanted to get “output” from two commands in RouterOS. Instead of doing that - asked for supout. I do not see harm here.
Everyone: Please remember that this is a user forum. We do keep an eye on version topics and visit others when we can. The only and the office way how to report bugs or feature requests is support@mikrotik.com or support servicedesk.
So please keep this topic related to 7.18beta. If there are any other type of requests/complaints, then create new forum topics if you want to reach out to other users or contact support (where someone might ask for a supout file ).
@strods, thank you and well said. When MikroTik staff can make a forum appearance, many may find it reassuring much as I do.
More information is always better and deft words now and then deflate the speculation space which has typically calming effects.
The reason I “must” upgrade the bootloader, which is included in the ticket, is that after a RouterOS upgrade the following messages are logged (including the erroneous \r characters):
2025-01-23 20:11:32 system,info,critical Optimal nand stability requires a backup-routerboot upgrade.\r
2025-01-23 20:11:32 system,info,critical Universal package can be found here:\r
2025-01-23 20:11:32 system,info,critical https://help.mikrotik.com/docs/display/ROS/RouterBOARD#RouterBOARD-Settings
When you think that is not enough information, please update either that message or the webpage that it points to.
In fact I asked in the ticket what this “nand stability” was about and in what cases it would be important, but got no reply.
As you can see, the message was issued a while ago and it is too late to “generate a supout.rif just after the issue occurred”.
It would be real fun to see this “backup-routerboot upgrade” message on ARM devices - which do not even support this operation. Other devices require enabling “install-any-version” flag in device mode etc. This is messy…
I think it only applies to what we now call “old” devices. The RB951G for example, which is MIPSBE.
It is apparently assumed that everyone had upgraded to v7 before v7.6 and then could upgrade to that version and upgrade the backup-routerboot with that.
In my ticket I explained that I got it when upgrading to 7.18beta2 and it is not practical to downgrade all the way back to 7.6 just to apply that upgrade.
Hopefully they will just release a new package for some later RouterOS version (even when it is only for a stable version).
In that case, “best” be that gets reduced to:
2025-02-13T06:06:43.863Z
Related, feature request on CEF: it be nice if there was an option to always send logs as UTC. IMO, it always better persist date-time as UTC & let viewing tool adjust it back to local time. Now that isn’t possible Winbox/Dude today (other than you can set all routers to use UTC).
I solved the issue selecting the ‘backup bootloader’, rebooting and re-apply the routerboard fw update. Then back to the normal bootloader.
Maybe it’s not right .. but no more complaint in the log
When that is the solution (could well be!) then why the complicated way as explained on the help page?
Of course you need to apply another upgrade to really know if it worked, because the message is only logged on the first boot after a RouterOS upgrade.
This message is there since v7.14. Please stop hijacking version topics with discussions about other features/issues/bugs. We will look into this and will find a solution. Keep this topic related to 7.18 please!
ech1965, strods was answering about “Optimal nand stability requires a backup-routerboot upgrade”. This is something that was there for many versions and is not related to 7.18
I observe on all versions of 7.18 beta. On Winbox versions 3.xx and 4.xx.
All you have to do is click on the “check for updates” button.
I have this happening on cAP ac, wAP ac, hEX and hAP ax3