Note for upgrades from 2.9 to 3: We have reports of some 2.9.xx upgrades to v3 failing on upgrade on RB500 where the board becomes non-functional until Netinstall. We have not found any solution yet, it is advised to ensure physical access before upgrading.

when mikrotik says the rb500 gets non-functional what you really mean, because I have a few rb500 with the actual 3.2 and they works fine.

regards,

I have one rb535, two rb133c and one rb150 failing after the said upgrade.
These boards are not even accessible by netinstall anymore. I can boot 3 of the boards through netboot server over the ethernet. After that the netinstall program manages to erase the nand but the upload of the new packages (or even old versions) fails. So you understand, after that the nand is empty (formatted) so the boards are completely useless.
During the same week I ran into the problems with these failing boards I actually also upgraded over 70 boards, most rb133c, a handfull 532's and 112's, all in a production environment and they are all OK after the upgrade.

I had upgrades from several versions of 2.9.x into 3.2 and even two rb133c units from 3.0 to 3.2. Both had exactly the same config, both were update wireless and one failed afterwards while the other had no problem whatsoever.
IN the rest of the field I had several firmware versions running but like said, I hardly had problems.

All the 'field' units were updated by ftp over the wireless and as said, only one Client CPE rb133c failed after that.

So it looks to me it's not a common problem, but to high in occurance to call it a 'rare' event.
And one that doesn't make me too happy

I have had several suggestions from MT now to solve the problem but so far no luck. I'm expecting, and waiting, for their next moves.

I was lucky my boards were on my desk and only one in an easy accessible lproduction side.

Rudy

Ok Rudy,

I understand you. sorry about your boards.

I always upgrade my rb500s (532) via ftp. in this case I've upgraded just 4 units and those units have not failed. only one of them has the 3.3

Let's see what mikrotik does about that issue.

regards.

I have found the board failure rate (or otherwise issues with after upgrade) of about 5%

Yes, this is a painful number especially with many on towers. It is really the only downfall of this equipment. I have no answers either.

Scott

ensure that you have upgraded your routerboards' firmware before upgrading routeros, at least that is what worked for me

hello janisk,

there is something I don't understad so well. you said: "ensure that you have upgraded your routerboards' firmware before upgrading routeros"

upgrade Routerboard and upgrade RouterOS, where is the the quality of the differece or distinguishing feature between?

regards

firmware upgrades come included in some of the ros upgrade versions.
But by upgrading the ros the firmware doesn't get updated.

You have to manually upgrade the firmware in Terminal:

/system routerboard> print
routerboard: yes
model: "112"
serial-number: "0F4D01D51B08"
current-firmware: "2.12"
upgrade-firmware: "2.12"

If the 'current-firmware' is lower then the úpgrade-firmware' then perform the next:

/system routerboard> upgrade
Do you really want to upgrade firmware? [y/n]
y
firmware upgraded successfully, please reboot for changes to take effect!

Rudy

Well, I've had good success in upgrading the RB532 on production boards to 3.3...until I got to the one that was very inconvenient to access, and of course, that one failed. So, tomorrow it's up to the mountain on skis...with new RB600 in hand (backpack). So beware until MT gets this solved. (BTW, I didn't notice the warning on the d/l page until I committed the mistake.)

A question to MT - has this issue been narrowed to a RB532 BIOS (firmware) issue, or is this triggered by something in the upgrade process itself?

I did notice that the small number of RB532's I have in key places were running ancient BIOS (firmware) revisions, so I upgraded them and rebooted during a maintainance window. So I'm now at FW v2.12 and ROS 2.9.50 on them.

I've successfully upgraded nearly all of the rest of my network (a mix of hardware including WRAP2.C, RB112, RB133, RB411, and RB600) to ROS v3.3, and have generally been quite pleased (except for the Tranzeo CPQ issues). But I'm not going to play "Russian Roulette" with upgrading the RB532's currently in key locations and "hope" they go OK, so I'm looking for feedback or information about this issue and any workarounds that may be needed to make sure it doesn't strike here.


Brad

Well, it happened to me on one rb150, one rb532 and two rb133c's
I´ve been reading about guys having sort of same problems with rb112's but don´t know that status now. I´ve got 10 of these upgrade without any problems, like 50 other rb133's and 6 rb532A's

My failing units are send to MT. I hope they can find the problem.

What does struck me at times, when I configure new rb113's out of the box (they all have the same basic config) and I upgrade them in my usual routine;
- log in by mac telnet
- give IP on ether in same network as my laptop
- remove the preset IP
- log in by winbox on just set IP
- put full new package in the ´file list´ window in winbox
- reboot the unit
- after reboot check the unnecessary packages for de-install
- go to terminal and type ¨/system routerboard print to check the firmware
- if newer firware available type ¨upgrade¨
- typ¨Yes¨ and after confirmation of the upgrade type ¨/ system reboot¨ followed by yes to make the routerboard reboot,
they still behave different during this process.

I have done so now on my last serie of 10 rb133's direct from the manufacturers box (I buy directly) and sometimes the whole process takes only 4-5 mins, some units though seem not to take everything smoothly straitght away. Some units take almost 10mins to do the same because their reboots are very slow and sometimes I just need to unpower and repower them (I wait at least 15 mins!) completely to bring them back alive?

What could cause this?
Units are exactly the same,
upgrade packages are the same,
firmware is same and upgraded to the same,
proecedure is the same,

But still the differences?

Rudy

Ping.

Anyone have anything to report on this issue? My only remaining boards to be upgraded to v3.3 are RB532's, all of them are in fairly important places in my network, and only one of them is "easy" to access physically. I'm impressed so far with the increase in wireless performance (mainly CCQ), and would like to finish the migration.

Regardless, I will be ready to roll a truck should something go wrong, but my question revolves around what exactly triggers this issue, and how likely is it to happen (both on a v2 -> v3 upgrade, as well as v3.x to v3.x upgrades)?

For what it's worth, I've done about two dozen WRAP 2.9.50 -> 3.3 upgrades, and around 50 RB133, RB133c, and RB112 upgrades, and not bricked any so far. The RB112's were a little fussy, but once I pared it down to *only* what they needed to be running, they seemed to be OK. Oddly, I had *no* problems with any of the RB133c's being fussy after upgrade, and I was under the impression that they were the same as a RB112 from the hardware perspective.


Brad

A question to MT - has this issue been narrowed to a RB532 BIOS (firmware) issue, or is this triggered by something in the upgrade process itself?

I did notice that the small number of RB532's I have in key places were running ancient BIOS (firmware) revisions, so I upgraded them and rebooted during a maintainance window. So I'm now at FW v2.12 and ROS 2.9.50 on them.

I've successfully upgraded nearly all of the rest of my network (a mix of hardware including WRAP2.C, RB112, RB133, RB411, and RB600) to ROS v3.3, and have generally been quite pleased (except for the Tranzeo CPQ issues). But I'm not going to play "Russian Roulette" with upgrading the RB532's currently in key locations and "hope" they go OK, so I'm looking for feedback or information about this issue and any workarounds that may be needed to make sure it doesn't strike here.


Brad

Well, to give you some good ´vibes´. I have 5 rb532A's remotely updated from 2.4.49 to rosv.3.0 and later v.3.2 without any problems. On some I upgrade the firmware first, on some only after the ros upgrade. No problems.

These boards are already in production for almost a year and that would support the idea that we´ve had to deal with a series of minor R52H radio´s or minor boards?

The only thing I would be a bit care for is that when a package is updated over a wireless link it´s better to make sure the link is very stable and not a lot of other traffic is passing.
I lost one rb133c because it was not a very stable link and after I transferred the file (which came in the ´file´list, but that does not give a guarantee it is not corrupt somewhere) I rebooted the unit where after is stayed dead for ever!

I also make it a habit now to wait at least 10 full minutes to send any command to a board that is still somewhere in the booting sequence with the new ros family. It could be that I lost my other rb133c because I was impatient and tried to contact the board while it was probably still ´consuming´ its new ros..... who knows....?

Rudy

I tried to upgrade a RB192 from 2.9.48 (I think) to 3.6. I've done this on nearly 20 other boards (mostly 133, some 532A) with no problems. The 192 is now bricked.

I can talk to its BIOS (2.9), but I can't upgrade it to 2.12. See my post here http://forum.routerboard.com/viewtopic.php?f=3&t=3783 for details of the failed BIOS upgrade.

Using netinstall, I can send 3.6 to it, but the board complains about broken package and won't boot. Sometimes, I can get it to boot, but I hear a single "bird chirp" rather than the double beep. WinBox opens and then immediately closes, telnet answers but I can't login to it.

I wonder if the problems people are having with rb500 series really is also on the RB1xx series also. Also I wonder how a BIOS upgrade can fail? It's xmodem over a serial port and 2.9 says the upgrade was successful, but after a reboot, it's still at 2.9. Strange.

I'm afraid to upgrade any of my production routers, since they all require a truck roll and a ladder to reach them.

Here's an update on this.

I was able to netinstall just system and routerboard from 3.6, and keep it running long enough to upgrade to BIOS 2.13, just recently downloaded from routerboard.com.

I now get it to come up from the console as routerboot 2.13.

I ran netinstall (latest 3.6 version) on a freshly downloaded copy of ROS 3.6 (combined package routeros-mipsle-3.6.npk).

The console claimed it was successfully installed, but the system won't stay up long
enough for me to "Make Supout.rif". I can login from WinBox, but I can't get a terminal
window to open and after a few minutes, the console spews out pages of crash dump
data. I've forwarded the console data to support@mikrotik.com.

Anyone had any similar experiences with RB192 upgrades going so very bad?
Any suggestions? Anyone?