Autoupdate routerbook

RouterOS General
1

Hello,

i manage about 100 mikrotik router.

now with ROS 7 long-term is time to update all from 6 to 7.

i’m updated all from 6 to 7.20.7 and all works fine.

i DON’T use mass update, because if have a bug or router i MUST run on all customer…

so for now i connect to first mikrotik, update. wait to reboot…. reboot again for routerboot… wait….

when first mikrotik works fine and i can reach him form internet (of course with rules only from my work static ip or VPN) i update second mikotik.. wait … reboot… wait…

but i’m boring to reboot twice (1 for routeros and 1 for routeboot)

i will plan to use this script

:if ([/system routerboard get current-firmware] != [/system routerboard get upgrade-firmware]) do={
:execute {/system routerboard upgrade}
:delay 1000ms
:execute {/system reboot}
}

so i would create a survey if script is 90% unbreakable… or may have same problem if some device…

  • script may work without issue more than 90% of the time
  • script may have issue from 10% to 90% of the time
  • script may cause problem more than 10% of the time
  • never use that script !!!!
0 voters

thank you in advance…

if i receive enough vote i try to use in production…

of course can you explain possibile strange behavior which I didn't think of…

big thank you

2

What about running

/system/routerboard/settings/set auto-upgrade=yes

and letting ROS to do the job without bothering with the custom script? The effect will be the same (after first reboot, routerboot gets upgraded ... the only (optional in vast majority of cases) thing to do afterwards is reboot. The reboot after routerboot upgrade is only necessary if there's some notable change in routerboot which prevents upgraded ROS to run properly (e.g. some piece of hardware is initialized improperly), but even then sometimes a cold boot is required (which can't be done without manual intervention on site).

2 Likes
3

The script do not work 100% of the times, because after the upgrade all features like set something on routerboard are disabled fot the new device-mode.

The script isn't well written. What's the purpose?

Paste it into the terminal AFTER the update?

Whatever happens, the script is poorly written.

The easiest way to reboot only once is to update the firmware BEFORE rebooting the device....

1 Like
4

I don't think OP is setting anything. Firmware update is not covered by device-mode.

1 Like
5

Correct steps are something like:

Prepare a upgrade server wit all needed .npk,
and extract all /etc/*.fwf from each .npk for each platform with something like 7-zip, etc.

Paste a script in terminal that do

  1. Like suggested from @mkx do /system/routerboard/settings/set auto-upgrade=yes
  2. connect to own server/device to download proper firmware based on architecture
  3. upgrade the firmware
  4. connect to own server/device to download proper software .npk based on architecture, not missing needed wireless.npk or other packages
  5. Reboot

Done.

6

Or alternatively paste a script like this below, before upgrading:

/system routerboard settings set auto-upgrade=yes
/system scheduler
remove [find where name=autoreboot]
add name=autoreboot policy=reboot,read,write start-time=startup on-event="\r\
    \n:delay 20s\r\
    \n/system scheduler remove [find where name=autoreboot] ; /system reboot\r\
    \n"
2 Likes
7

If you want to get adventurous, you could do what I do and leave the script in place to cover future updates.

/system scheduler
add name=autoUpgrade policy=reboot,read,write start-time=startup on-event=":delay 15s\
    \n/system/routerboard\
    \n:local routerBoard [get]\
    \nsettings\
    \n:if ((\$routerBoard->\"upgrade-firmware\") != (\$routerBoard->\"current-firmware\") and ([get auto-upgrade] = true)) do={\
    \n  /system/reboot\
    \n}"
8

sorry, yes i plan to setup a scheduler on startup for future updates…

really i will use this

/system scheduler
add comment=UpgradeFirmware name=UpgradeFirmware on-event=":if ([/system routerboard get current-firmware] != [/system routerboard get upgrade-firmware]) do={\r
\n:execute {/system routerboard upgrade}\r
\n:delay 1000ms\r
\n:execute {/system reboot}\r
\n}\r
\n" policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon start-time=startup

yes, i know is just a reboot…

but for 100 devices , is 5 minutes for 100…

thank you

9

Leaving something that potentially causes your router board to reboot endlessly is a truly terrible idea, from ANY perspective...

Note that the first thing my script does (after the reboot) is delete itself to avoid any future complications...

for example, in your script, if RouterOS syntax change upgrade-firmware to update-firmware (just an example, but OFTEN happen),
voilà endless reboot....

On my script, if somewhere syntax change, the line is not runned at all...

2 Likes
10

Use my before/during upgrade, and except the problems for v6->v7 you do not have any problems...

11

Hm. I would have thought an invalid element would cause the script to error out, but apparently not. Thanks for the observation. I'm still thinking this can be mitigated by verifying the array elements and increasing the delay time to allow for manually stopping the script before it runs. The sweet spot between automation and manual processes is always a moving target.

1 Like
12

Honestly, my solution is precise and does its job without any frills...
If the upgrade is done "by hand" or automatically,
all it takes is for the automation to insert the script BEFORE the update, and you'll definitely not have any problems...

Why complicate matters?

2 Likes
13

I see the point. That said, complexity is a matter of perspective. Your solution is precise and elegant, but requires an external process to be invoked every time, which adds complexity of a sort. Mine is self-contained and doesn't require external automation but adds local complexity and, as you pointed out, needs to be carefully vetted as a result. I suppose it all depends on whether the upgrade automation is happening on-device or not.

14

In this case it seems like a human is passing all the devices around one by one...

But even in the case of automation, since the automation still has to do "something," it just needs to apply the script first.

How many other cases are there?
Either there's a human, who I think feeds a script (rather than clicking all the buttons—but even if they did, pasting the script into a newly opened terminal is a snap).
Or there's something "built-in" to the device that definitely does "something", and the script is the first,
or there's something that connects remotely, which will still send commands, also the script, not click anything...

So, either manually or automatically, applying the script is a snap.

Instead, I think leaving scheduled processes running "n" times is completely pointless.

Just as it would be pointless to check whether the firmware is up to date at every reboot:
If the auto-upgrade option is already set to "yes," it'll take care of that everytime...

1 Like
15

thank you, but your script need i setup every time to i need to update routeros…

if i schedule on startup this

:if ([/system routerboard get current-firmware] != [/system routerboard get upgrade-firmware]) do={
:execute {/system routerboard upgrade}
:delay 30000ms
:execute {/system reboot}
}

so , same this my original but with 30 seconds to delay…

if script is “broken” i have 30 second to disable it…

is more efficient?

thank you in advance

16

No. auto-upgrade=yes is more efficient, and safer approach.

Will it work, very likely. Is it an what I'd "recommend", also no... but I'm not sure of your workflow so hard to say.

17

but

auto-upgrade=yes

if already setup on yes….

my problem is

update routeros

wait time to reboot…

when start i check routerboot and ask me a clean reboot

so i need to reboot again…

wait time to reboot…

when start i check routerboot and is ok…

so if i plan to reboot automaticallly i check only once…

thank you

PS. best is a flag developed by mikrotik to autoupgrade and reboot to apply upgrade to routerboot… :slight_smile:

18

What you could do: set auto-upgrade=yes and let ROS do the routerboot upgrade. But if you insist on automatic reboot, you could check if there's a comment in /system/routerboard/print saying that reboot is necessary.

Currently on my device:

[user@mikrotik] > /system/routerboard/print  
                ;;; Firmware upgraded successfully, please reboot for changes 
                ;;; to take effect!                                           
       routerboard: yes                                                       
        board-name: hAP ac^2                                                  
             model: RBD52G-5HacD2HnD                                          
     serial-number: 8FDE09EE9E2D                                              
     firmware-type: ipq4000L                                                  
  factory-firmware: 6.42.3                                                    
  current-firmware: 7.19.6                                                    
  upgrade-firmware: 7.20.7

A side note: as I already wrote, rebooting after routerboot upgrade is "cosmetic" in most cases. I've upgraded my device 25 days ago and I don't see any need to do the reboot. routerboot was upgraded, it'll be "activated" at next reboot ... which might be due to power blackout (if my power company decides to make it longer than around 15 minutes which is the actual autonomy of my UPS system).

But, as @rextended already wrote: if you're really anxious about running latest firmware and you don't like reboots, upgrade firmware prior to upgrading ROS. He already indicated the way of doing it (it's quite a few steps on at least two devices - ROS device being upgraded and management machine - and I'm pretty sure it can be scripted somehow. If you do it, then single reboot (the automatic one, executed by upgrader) will also activate the new routerboot.

19

I use an other approach. In bash at this time.

Use a local repo where npk are stored, downloaded and checked.

A bash script push the npk on selected devices.
and after reboot is triggered.

I can easily downgrade by the same way.

It also create an config export/dump and pull it locally.

All actions and steps are done manually. No way to kill all at the same time.

20

I'm wondering how you do it...
Is there a script that checks and applies automatically,
or do you connect one device at a time, issuing commands via GUI or CLI?

In all three cases, it's a snap to send the script commands along with the rest of the commands...