Can confirm. bricked numerous devices after bootloader update with this “long-term”. Recovered with netinstall. STAY AWAY from this release
What I do not understand: why does MT not revoke this release or at least speak out an official warning? Instead they are silent and people keep bricking their devices? It is quite a month out now - there should be enough information collected to pin down: which platforms are affected by the firmware issues? And how to resolve. 1 month without hotfix.
upgraded multiple devices to 6.48.5 and 6.49 to test.
in 9 out of 10 cases got them bricked after firmware upgrade.
only NetInstall helps afterwards.
tested on
rb2011
rb911 hpnd
rb912
rb hex
ccr 1009
ccr 1036
rb 1100ahx4
I can only imagine horror of people having scripts for auto upgrade.
Wondering why I have not seen it on a single device… Possibly this does not happen with split packages (vs. bundle)?
I have updated 10 hap ac2s and a few hap lites, and didn’t have this problem with any of them. I’m using split packages on all of them.
I don’t use bundle package anymore with 16MB flash devices.
I use split packages as well but still on my hAP ac2 with only 4 packages for use as a wireless AP it fails to install RouterOS v7 “due to lack of space” 
Now I need to find if my install is somehow corrupted and uses too much space, or if this update will not work and requires netinstall for some other reason.
free-memory: 77.8MiB
total-memory: 128.0MiB
free-hdd-space: 2656.0KiB
total-hdd-space: 15.3MiB
Uploading OK, reboot and then it is back in v6 with an error message indicating lack of space…
I think selling devices with 16MB flash never was a really good idea…
Have a look at my topic about upgade path from split packages.
100% this.. I have been asking for this since way before there was a Long term channel. There needs to be a known stable channel where the last version that has been in the field some time with no instabilities or show stopping issues is kept. Only incrementing when the next actual stable version is detected.
Also that version needs to have the log show any bugs or niggles found with it since its release with what newer release addresses it so people know what to expect.
It is called traceability.
Bill
Surprised? Nothing has really changed since when we first got an RB532 and RB112 with Ros 2 , except they now reserve being rude to you in private and ignore you on the forum perhaps?
welcome to the world of bricked unrecoverable routers, got a stack of em here now..
Agreed, Pretty poor form when the 7.1rc5 firmware is more reliable than the supposedly Long Term and Stable bootcode..
I have gotten to the point where I am reluctant to upgrade my units because I cant afford to have vendor provided code put the router into a state that requires manual intervention and recovery, we shouldn’t be having this issue this far along, I’d prefer to wait longer for Mikrotik to properly test a release than be in this position again 
Kind Regards,
Jim.
This it not what I have seen from MT. They always tries to help out if you ask polite for help.
The issue with unavailable devices after 2nd reboot has been reproduced and it seems to be related when upgrading from 6.41.4 (or older) RouterOS/RouterBOOT versions. Our apologies for the caused issues, the fix will be included in upcoming releases.
So anyone using older than 6.42 RouterOS or RouterBOOT versions, please first upgrade RouterOS and RouterBOOT to 6.48.4 or 6.47.10, and only then use the latest version.
hi,
Do you have the ability to stop customers from upgrading the brick way? If not then withdrawing the release sounds a damn good idea as it is now over a month down the road.
Unless you can instruct distributors to accept free returns/swaps of bricked hardware for swap for the duration?
It is not a “caused issue”, it is turning your hardware useless, this is more than just an issue.
Where are the warnings in CAPS on the update firmware notes as stage 1?
Speeding up your response to this maybe a good idea as i doubt your distributors/resellers will be happy with the returns and angry customers.
Thanks
Can’t you just netinstall the device to recover it? Others were reporting that that was working.
Updated an edge router at a client from 6.47.10 to 6.48.5, didn’t show back up in VPNs (1 OVPN, 2 L2TP). Assuming it’s crashed or worse. Have a backup, but not quite up to date… Building is closed for the weekend, will still drive there (40min) and try my luck through the admin WLANs.
That’s what you get from updating sort of in a hurry on a Friday afternoon, I guess. Never had an issue remotely like this on the long-term branch though.
Before an upgrade:
- Remember to make backup/export files before an upgrade and save them on another storage device;
this version is a disaster…
I’ve update my 750GL (bad blocks 0.0% FYI) …so today with this firmware after it had v6.44.6 on and it completely bricked the thing…I always stick with the long-term releases
and after I re-loaded v6.48.5 on with netinstall it worked briefly and went dead again… looks like the device went into a continuous loop!!! …it went haywire!
I netinstall routeros-mipsbe-6.47.9 … I know that version works!!! already have it running on my routers without issues…
Thank God it wasn’t one of my live routers!!! and therefor a DEV router!!!
and netinstall also gave me issues on my win7 machine …error on the screen is…“bind() failed: An attempt was made to access a socket in a way forbidden by its access permissions (10013)”
run as administrator didnt work either…
I had to pull out a XP laptop for netinstall mission
and dont get me wrong… I’m not new Mikrotik!! been using Mikrotik since v4.12 and own many routers running… but today I’m not having a good day with Mikrotik and I’ve had days like this ages ago with Mikrotik bugs…
avoid v6.48.5 by all cost!!!
If you see the thread for 6.49 (which has the same issues), MikroTik found that this issue only happens when you are upgrading from a device that has a very old RouterBOOT firmware (6.41.4 or older). If the RouterBOOT firmware is newer than 6.41.4 it should upgrade without issue.
That would have helped me 0% here because the device got inacessible remotely. It still was responsive through the local net, though. All the bridges and ports failed to load after update reboot, so all the adresses and routes were of course inactive. I had seen that once before, at around 6.43 or so on current branch. Another reboot actually fixed it and the routerboot luckily also didn’t break, but I still downgraded to 6.47.10 to be safe. Also enabled ping watchdog, which might have caught this, but I generally try to avoid on big hotspot edge routers.
Also, backuping everything at every update becomes impractical quite quickly when updating hundreds of small devices. On an important edge router it might be sensible to do (again, wouldn’t have helped me here), but I don’t believe anyone really backups ALL their damn wAPs before doing every single update, on long-term branch no less.