Hi,
Been working on this for some time now and can not figure it out.
If you issue this command from a command prompt …
/system routerboard upgrade
it replies back with
Do you really want to upgrade firmware? [y/n]
Is there a way to supress this message
Eg /system routerboard upgrade /y or /system routerboard upgrade < “y”
I realise that if you paste this directly into the terminal
/system routerboard upgrade
/y
it works, but just not when it is part of a script.
thanks in advance
if it’s a part of a script, it should not ask for confirmation
at least ‘/system reboot’ works fine in scripts =)
Now /system reboot requires confirmation too.
We can’t automate much of anything without the ability to bypass confirmations and password requests.
This is a big pain
The biggest issue here, The real pain, is MT change in syntax, without any notice, between ros versions. We use autogenerated script to all our system, but is forced to have to manny versions. 1 to 3x. 1 to 4x 1 to 5 x etc, is ok, but when we need to have 10 different, to different 3.x versions, it is a pain.
I agree that small changes in syntax break everything. Each release, even a point release, requires careful testing of each and every script. It is a real pain.
/system routerboard upgrade
y
/system reboot
y
This is how I do it.
Have you tried this on 5.21? I just tested and ROS does not like it, says that y is a bad command and it still prompts me for confirmation. /system reboot used to work but then at some point the confirmation was added and started to cause scripts to fail.
Have you tried this on 5.21?
No. I have not. 5.19 is latest I have running.
/system scheduler
add name=schedule1 on-event="/system reboot" policy=
ftp,reboot,read,write,policy,test,winbox,password,sniff,sensitive,api
start-date=nov/16/2012 start-time=13:27:00it rebooted router successfully
second test:
/system script
add name=script1 policy=
ftp,reboot,read,write,policy,test,winbox,password,sniff,sensitive,api
source="/system reboot"
/system scheduler
add name=schedule1 on-event=script1 policy=
ftp,reboot,read,write,policy,test,winbox,password,sniff,sensitive,api
start-date=nov/16/2012 start-time=13:32:00and guess what? successful reboot!
And how about:
/system routerboard upgrade
in ROS 5.21?
That doesn`t work for sure…
I don’t have a routerboard to test, but… what about ‘/system make-me-a-coffee’?.. why the heck do you need ‘upgrade’ in scheduler?!? %)
Lol!! Thanks for the laugh 
We are trying to completely automate the inbound testing, configuration, reboot cycling and firmware upgrade of routerboards. Much easier said than done when you need to repeatedly cycle boards, upgrade firmware etc. Especially when tools like FlashFig don’t work properly with the version of ROS that new boards come with (5.11). With hundreds of boards to configure, doing all of this manually is just impossible.
We would really prefer to use standard PXE boot and have a normal vmlinux boot image that we could run from rather than use FlashFig. Mostly because this is known to work well and it can be started at boot time so you don’t have to manually kick off the server. NetInstall is fine for a single board, but for mass production it is insufficient.
Anyway, so the only way that we were able to get /system reboot to work properly from a script import (/system script import blah) was:
Suggestion: When scripts are run from the import command, disable all confirmations.
We have tried many different ways to get /system upgrade to run from a script and nothing works. This requires manual execution due to confirmations. We have tried running from import script, run script and scheduled script. None works.
We would also like to be able to import password protected certificates (openvpn, ssl, etc), but there is no way to script the password field. Of course we would not ship out passwords to the certs once installed, but for mass production this also would be helpful.
So far our process has weeded out about 10-15% of incoming boards as defective directly from MT. The problems are either perpetual rebooting (seems like a boot loader failure of some type) and cannot be reset (since there is no serial access to the board), or bad NAND with failed blocks. 15% doa is really bad, but if we can catch them on inbound receipt, at least they don’t go out to customers and we can get replacements from the distributor rather than going through the incredibly slow RMA process.
Hi, that is not that much funny… I need any possible way of upgrading bootloader from script in a lot of RBs (similarly as DogHead wrote). For last week I was writing emails to your support and yesterday they wrote me, that upgrading bootloader is most likely impossible from script/scheduler/or whatever in ROS 5.21. And in scheduler just because, bootloader upgrade can by done after ROS upgrade, so after reboot, so put “/system make-me-a-coffee-and-cake” into a script which will run after that reboot makes sense, I guess…
P.
add a scheduler with
/system routerboard upgrade
not ask yes or no.
But that doesn`t work in ROS 5.21…
P.
We figured out that the way to make reboot work was to import a script that created a script and added a scheduler event that was a minute or two later than when you ran the script. Also have it run on startup another script which disables the scheduler that runs the reboot. Really messy.
We do the same type of thing with system upgrade to get the bootloader updated. This works about 50% of the time. We can’t really trouble shoot it. Debug log and script log don’t give any clue about why it works sometimes and sometimes not.
Anyway, yes, you can reboot from scripts but not if you import them or run them from command line.
Yes you can sometimes run upgrade from script, but it only works about 50% and you can’t do it from an import or run from command line.
i know for sure that in 5.21 and 5.22 /system reboot and /system routerboard uppgrade if ran by script is non-interactive and does not require the press of ‘y’ to accept the changes. As these definitely where changed to work for API as API does not bode well with anything interactive and same way to work using scripting as that also is non-interactive environment.
edit: running script form command-line does invoke interactive mode.