ROS 7.23.3 (and firmware 7.23.3), though I'm sure I've seen this in other recent versions; it seems that every time I run /system/routerboard/upgrade it will log "system,info,critical Firmware upgraded successfully, please reboot for changes to take effect!" even though in fact it already is at the most current firmware (and has already been rebooted).
Anyone else seeing this? Or, am I seeing things?
And, revisiting a sometimes-commented topic, /system/routerboard/settings/auto-upgrade y/n ?
if im getting this correctly, yes i get that too, i dont know why it doesnt handshake with mikrotik firmware servers to check the version and if its up to date in stable or the one youre running and just grey out the button.
No yeah it lets me do that aswell, click upgrade and broadcasts a message that the upgrade is successful and i should reboot to take effect.
(I do believe that it literally does nothing if you're running the latest version)
It could be that I misunderstand how this is supposed to work, though I'd argue that I do understand how such things Should work. (I'm not so new to MikroTik as to expect that's how they implement stuff, of course).
An update command - especially if it writes to flash - should not actually do anything if there is not anything to actually do. It should be implemented as "check if different/newer, and only then do anything (otherwise report a status which can be human- and programmatically interpreted as "nothing to do").
if its a problem at all there's absolutely 0 reason not to fix it, and from my experience its a really simple fix, id bet they just didn't get to it or just forgot about it on the TODO list.
16M of flash, and that check code takes space . . . They might have left it "crude" on purpose, since running the command when an update is not present does not likely happen much, hence no flash wear.
Are you trying to script this, hoping that the script can only write flash when there is a delta, or ???
Can't argue with fixing it, but I doubt it will get much priority . . .
The firmware is a file inside the RouterOS image. So "upgrade the firmware" copies it from the firmware file of RouterOS into the boot area of the board. It is not related to internet.
Way in the past the mistake was made to give firmware a version number that is the same as the RouterOS version. Before, firmware had its own version and it seldomly changed, so after a RouterOS upgrade you would see the same "current firmware" and "upgrade firmware" versions as before, and no upgrade was needed. However, time after time people, when asked what RouterOS version they were running, would report the firmware version, and had to be asked again. So then the versions were made the same.
I think it was a bad decision, but of course I am not working at support so I do not know how much it reduced the confusion. I am used to the BIOS version of my computer being completely different from the OS version or Kernel version, but apparently MikroTik customers are different.
Now, we basically have to upgrade the firmware all the time, although 90% of the time the updated firmware is the same as the previous one except for the version number...
(well, probably on some devices today the firmware upgrades are a bit more frequent than back in the RB2011 days)
sure but why not just check a version of the current routerboot version before having the update availible, hash it and check with the copy you have in ur files then, if the hashes match, don't broadcast the upgrade message or broadcast "The firmware version that youre running is matching the one you have in your files". instead of letting the user know HEY U HAVE TO REBOOT TO APPLY AN UPGRADE (thats not there because its already on the newest theres nothing to apply). its so simple..
I just noticed that the upgrade command will do unnecessary work, and, worse, report (And stay reporting, at /system/routerboard/settings/print, until you do reboot] that a reboot is needed).
About the 16MB flash, yes, but .. my (what, 10-year old design? more?) RB951Ui-2HnD devices (to my surprise) can run ROS 7. (I really had expected to have to forklift upgrade these devices). That's .. frankly amazing durability and support longevity. (Thank you, MikroTik; see? We don't only complain!)
If, eventually, after all these years, very small old devices can no longer run ROS v27 or whatever, I wouldn't be particularly upset.
You seem to care. And I think Mikrotik is perfectly aware of how this works. See manual.
To check whether an upgrade is available, compare the current-firmware and upgrade-firmware values under /system/routerboard
But try to convince them. I think they won't change it because it would mean BC breaks in many scripts. And there may be even a use-case to force-upgrade a already up to date firmware.
i do care, because i want it to be good and its already 98% of what i could ask from it. A concept of updates has been around forever and it shouldnt and cant be something other than "Current", "Legacy" or "New version is availible" status.
That being communication to their servers or local upgrades, it really doesnt matter, but it doesnt seem theres something like that here.
Imagine everytime u went to update your Windows 11 machine, you checked for updates, it said you have updates, you update, reboot and it says you're on the same version.
The same thing is happening here with a few differences (same same but different if you get me).
It doesn't really make sense. Sure i guess you can give benefits of the doubt them most of the time but thats just not how its suppost to work.
A HUGE difference! Windows is a virus^h^h^h^h^hOS, not firmware! And ROS does NOT do this, just the firmware.
Sorry, but I continue to see this aregument as somewhere between "purist" and "nonsensical". One FW flash per ROS update is hardly going to damage the flash (heck, the associated ROS uodates write a lot more), so a firmware flash when ROS updates is a 1:1 event, and hardly causes wear. .
(What I DO wish they had was an ability to integrate FW updates with CapsMan driven updates. Otherwise, I'm on the thing anyhow, since I don't believe in blind updates on core devices. Heck, even if you script it, just use the new ROS version as the test . . .
i've requested that as well, they just said more people have to ask for it and they will look into it.
However i sent another ticket for suggesting a feature with some possible software solutions to what we talked about above.
On Windows update you hit the "check for updates" button. Then you see the moving dots, 15 seconds later: your already up to date. You hit the check button again. Again the dots, again up to date. You check another time, boom, update available.
15 seconds? Not if you actually apply anything. I've got Windows servers where the full patch cycle is closer to 20 minutes. (But yes, the inability os MS to follow dependencies is just another one of thier weaknesses, henxe the multiple cycles . . .
At least ROS is one-and-done on upgrades . . . (and they don't forxe thier new bugs down your throat!)
RB951 is from the good old days before 16MB flash! They still had 128MB flash and you could even partition it (2x64MB) so you can copy your running RouterOS version+configuration, upgrade to a new version, and when there is a problem you can just switch partition and be fully back at your previous version. Those were the days. These devices may have a longer lifetime then some of the later models.
And ROS does NOT do this, just the firmware.