Hello,
this night some "RB3011UiAS" chnaged by script to 7.3 - after that all "RB3011UiAS" with an SFP "S-35LC20D" on it were hanging in an boot-loop. Only with pulled out SFP the "RB3011UiAS" came up. We rolled back to 6.49 and there everything is fine. I think that 7.x is not already out auf BETA !!
Grüße Stefan

Sounds like auto upgrade...correct?

Have you missed the WARNING: Do not use this version on RB3011 devices which has SFP port connectivity.?

viewtopic.php?t=186567

Sounds like auto upgrade...correct?
Have you missed the WARNING: Do not use this version on RB3011 devices which has SFP port connectivity.?

Yes, our Auto Updates on so much devices do read before working. Would be nice to include such "not working" breaks in the Update itself.

Why not wait some weeks or to first read forum before blindly apply an update just released without testing it first on some spare parts?

Sounds like auto upgrade...correct?
Have you missed the WARNING: Do not use this version on RB3011 devices which has SFP port connectivity.?

Yes, our Auto Updates on so much devices do read before working. Would be nice to include such "not working" breaks in the Update itself.

I don't think it is a good idea to do automatic upgrades using the "stable" channel, you should always be prepared for stuff like this.
Or maybe do the schedule once per 2 weeks or so, so that there is little chance that it updates the same night after a new release.
Unfortunately, "stable" releases are not always stable. Or actually, "stable" refers to the release schedule, not to the software stability.

Why not wait some weeks or to first read forum before blindly apply an update just released without testing it first on some spare parts?

In this case we learned: stable may be stable, it maybe only testing or lab, maybe buggy for only one device and some use it after weeks ... so stable is also QA by customer.

@SWISSSNOW, unfortunately you're not alone to be lured into a false sense of security that the "stable" release channel is actually quality tested and good enough for automatic updates (which it isn't in reality!)

If aimed for production my advice is to wait at least two weeks but preferable four weeks before updating to a new version and but of course tested in a pre-production lab. Some more about this subject in: "Software life cycle and release management (re: auto upgrade)"

My suggestion is totally different, until some critical security flaw do not come out, today I'm slowly deploing 6.48.6 on my network,
previous version are 6.46.8 and just on 8P, 16P and 24P models I have 6.47.10 for the bug on SNMP voltage...
Now all CCR / CRS / 8P / 16P / 24P are on 6.48.6 and working flawlessy. I'm deployng 6.48.6 on the remaining networks devices and on the CPEs.
Until now I do not have any single problem on this way, except one CPE turned off during update (04:00 of night...)
And when I update, I also update the RouterBOOT (BIOS) at the same time, I do not wait update and another reboot for that.

1st. I would start that if you have an issue with ports not working. That your hardware page may need to say that. see URL
https://mikrotik.com/product/RB3011UiAS ... -downloads
When clicking on download it shows no issues that a port will stop working it just downloads 7.3 direct. With no warning.

2nd. Can we SSH in and fix this with a config or do you have a hot fix to make the port work again?

It seems the way to make it working is to bring down the SFP link (unplug module or only the fiber), then the bootloop stops and you can downgrade.
Of course when you had followed my advice and partitioned the router (2 partitions) before the upgrade and copied the old version to second partition before downloading the upgrade, you could just have waited for the router to automatically enable the 2nd partition when it entered a bootloop.
But it seems many users like to live on the edge and do not like safety measures...

But it seems many users like to live on the edge and do not like safety measures...

Yes. Thats the right way. Unplug und rollback. And plan using fall-back !

But: undicussed here - where is the solution with using "stable" und why is this harware (an some others, see bug reports) still not fit with 7.x + SFP ?
A short reply (of couse not forum gurus) from Mikrotik with a view in the future to get a better calculation of using this harwdare would be very nice !

See it like this. Everyone has his own experiences with hardware und firmware. It's not good to pray "best practice" and see others lost with the way they stay on the track. Everyone has his own enviroments, 1 or maybe 3000 routers to manage. Best Practice with home-using may be more scripting an simple hands-on - but in other cases every roll-out can take days and sometimes you calculate to loose 2 or 3 routers. In our case it was the first time a mikrotik stayed in boot-loop - when i think of using Cisco there were more big bugs and bricked hardware in the middle of nowhere with prooved und pre-labed IOS and with fall back in register. So Mikrotik does a very good job here at all.

Well, I think most of the confusion comes from use of the word "stable".
In the channel names "long-term", "stable", "testing" and "development", it seems that the difference is mainly the release frequency.
"testing" gets regular new versions, people try them, and at some random moment the testing version is promoted to "stable".
That does not mean that the software is stable and does not crash or have other important bugs, no it means it is put in a channel with a lower release frequency.
So it is stable in terms of changes, not in terms of software stability.
"long-term" has an even lower release frequency, so less changes. but it is not a version especially prepared for that, it is just the previous "stable" after some .x updates.

But unfortunately, people read "stable" and think "that means my router will provide me stable service when I install that".
But that was never claimed, I think.

Now of course all software can have bugs. But when there already are different channels target to different kinds of users expecting different things from the router (i.e. being testers or having newest features, or having a stable router providing network service and not being involved in testing), there should be a better defined way of promoting testing versions to "stable".
Testing versions should have been tested for a while, at some point being labeled as "release candidate" inviting more rigorous testing, and at some moment a release candidate that has been up for at least a couple of weeks and received no critical bug reports can be promoted to stable.

Instead what appears to happen is that at some point in time someone says "we need a new stable version" and at that time the current state of development, which is not even the current rc that has been up for 3 days, but also includes the changes made in those 3 days, is suddenly declared "stable".
That now lead to disaster, and it has done so several times in the past. But it seems MikroTik learn from that only very slowly. There was a claim that they look into it, but they are already looking into so many things that I do not expect immediate change.