[quote=pe1chl post_id=1101301 time=1727977762 user_id=80589]
[quote=infabo post_id=1101269 time=1727969515 user_id=177714]
And even if it would exist: you would need to press button or power off. hahha
[/quote]
Well, at least we could plan that as a task to be performed during other visits to each location in the months before the upgrade.
[/quote]
Mikrotik could make these device mode properties available in 7.16.1 already. 7.17 final release is months away.
Let me remind you that you guys are adding both fixes and features in RouterOS 7 at a fast, steady pace (for which we are grateful). That “some need” for switching between partitions is because new versions can test out fine in the lab or on a couple of field devices, but introduce breaking changes elsewhere in the field, some of which we may not notice for days or weeks. Switching back to the previous partition gets us back to a known state (version + config) quickly.
As for unplugging a router for just ONCE in it’s life:
Let’s look at my mountaintop CCR2116 as an example. We can get there relatively easily from June to October. That’s only five months out of the year. Even then, it’s a four-hour drive one way. And, for obvious safety reasons, we only go up and do our work during daylight hours. You are suggesting we will have to set aside 9-10 hours one day and bring down a critical portion of the network for a few minutes in order to keep existing features active, should we choose to update the software (which we usually do to take advantage of bug fixes). Not only is this expensive (fortunately we usually have multiple reasons for going up), but customers don’t often like services going down during daylight hours.
For the gear that is more reachable, I’m (I’m a one-man business) going to have to drive around my network, remotely log in, and within 2 minutes power-cycle about 40 additional CCR2116’s, RB5009’s, RB4011’s, etc. to keep an existing set of features working. That all has to be done during maintenance windows, which are mostly between 2:00 a.m. and 4:00 a.m. Most of my site routers are on customer rooftops, with power coming from inside the home. (Are you seeing where this is going?)
Can you at least pretend to understand the situation(s) some of us face, show a little sympathy, and offer constructive suggestions, instead of treating us like idiots? The fact that millions of devices and users won’t be affected does not diminish the fact that the remaining hundreds of thousands will, and that there is a tangible cost (in this case a loss) associated with your development decisions.
Agree 100%. But using channels to upgrade/downgrade when facing a potential bug is also very quick too ;). But unfortunately that has problems here too, with the “downgrade=no” device-mode.
Know it’s an early beta. But there is logical problem with default downgrade=no device-mode once 7.17 become “stable” i.e. there be no channel to use for downgrade without a “long-term” or other channel to pick for a potential downgrade… For productions system… the last stable is no doubt a better choice when facing potential bugs, than the “testing” channel…but “downgrade=no” block even manual package copy (and double-whammy if you were diligent and already used partitions).
Personally I don’t care about the definition of “long-term”, or what the channels are named… but the lack of having V6’s “3 channels” to “try” when facing a potential bugs has been noticeable in now years since V7 was released. The whole package manual package download+copy to downgrade V7… sucks compared with picking a channel in winbox, and rebooting to quickly see if a particular version broke something. Can we at least get a new “previous-stable” channel if there is not going to be a long-term? - this already be useful outside the beta.
Someone made the point that current stable 7.16 release chain could have options to “prep” for this change - that’s not a bad idea. I like the concept of device-mode, but it has to be controllable for automated/mass deployments.
Anyway… some add’l thought needs go into the “device-mode” scheme for dealing with at scale IMO. Either “downgrade” or “partition” are going bit quite a few folks as it stands.
I support this idea 1000% - because I use “previous-stable” version on production devices myself in its’ last version i.e updated all to 7.14.3 when 7.15 came out and did next updata to 7.15.3 when 7.16 came out. This way it would be easy to maintain this channel as well because it is updated only when next “major” release comes out.
At my work many years ago, I did setup several Wifi links on mountain tops. Some times they just stopped working or we just like to reboot them.
So found a solution. Using a power adapter that was controlled by ping. If it for some reason lost ping to an IP (eks remote site) for some time, it would remove the power, wait a fixed time, and put the power back. Site always comes up after that restart. If we like the remote mountain top device to restart, we could just use web access to the device and restart it, or remove remote IP so it restarted it self.
PS do not remember the name or product, was 20 years ago.
Developers of Mikrotik
There are so many AP AX that are unusable in 5G because of SA query timeout, and you have just reword this?
Are you serious?
Do not complain that for the market share of Ubiquiti in Wifi… unacceptable for months not to be able to connect my business laptop to wifi
Also seeing this. Tried with 7.17beta2 on both cap and capsman - would not work. Same with 7.16 on capsman and 7.17beta2 on cap.. timeouts.
Please tell me your mikrotik suppor ticket number and I will see if there is any progress in your case.
There is no need to do this at all. What makes you think that?
[quote=pe1chl post_id=1101268 time=1727969136 user_id=80589]
[quote=normis post_id=1101264 time=1727968955 user_id=5]
You can set this option today in 7.16, and it will remain after upgrade.
Existing config is not affected by device mode limitations.
[/quote]
/system/device-mode/update partition=yes
expected end of command (line 1 column 28)
you cannot. 7.16 does not know about device-mode “partition”.
[/quote]
Are you serious? I am directly answering your question about bootloader settings.
If you are not interested in real answers, only trolling, you are welcome to join some other online community instead.
If you enforce “advanced” mode for existing devices without this mode or apply new non-existing features, then it is breaking things.
For example you have feature you may want use occasionally so it is not configured but, but you can always do it now.
After the change you cannot do it until going physically to reboot the device.
So effectively you are enforcing people to go physically reboot already installed boxes. That can be thousands.
For me the “partition” feature is a breaking point. I do on upgrades:
So if something is wrong after upgrade and I cannot login back to the device, then it is reverted back to original version on backup partition.
This may help to resolve some issues without need of physical access to the device and this is now broken.
I like this idea of someone here:
For devices currently running <= 7.16.x which currently have device-mode = “enterprise”, an upgrade to >= 7.17 will switch the mode to “advanced”, but with the extra features still enabled (except for container, unless it was already enabled under the older version). The extra features, however, can each be switched to “no” once (by running the commands) without requiring physical access. Further switching, as well as changing the device mode, will require physical access.
This thread highlights some very interesting workflows we never even imagined https://xkcd.com/1172/
Why do you switch the partition after upgrade? Can you not simply create a second partition, or update it, if upgrade is successful? And if not successful, boot from the backup? That will not require any device mode changes.
Yes, automating upgrades that include creation of backup partitions during upgrade, will certainly require a button press once, before such automations can continue. But this is certainly not your typical way to use partitions. Partitions are created and then only used when device fails to boot.
EDIT: I am reading your post again. The last step, why is it necessary? Your workflow is not affected by device mode, if you don’t manually switch to backup partition. Why is this needed?
I am not bmann, but I can imagine some reasons why he uses the described workflow. The key quote is “I cannot login back to the device”. The device can successfully boot up. But at the same time not accessible anymore. Wireguard/ovpn tunnels do not establish anymore or other reasons. The last resort: rollback. Rollback is maybe the most powerful tool anyone working in IT can have. Because there is no standardized way in ROS, people come up with their own solutions. And it’s not a spacebar heater…
…and refering to the xkcd comic on using spacebar to overheat cpu. Well, this is - no shit - one thought I had in the last few days on this device-mode topic. “How can I simulate power loss for ROS without actually power off or press the reset button”. People get creative. Maybe someone finds a sequence of commands or a state of configuration which leads reproducible to a “device rebooted. possibly power loss” log message. This “knowledge” of ROS bug could then be used to confirm device-mode changes. It is like having the 0-day exploit at hand - and keep it like Golum’s ring.
that is the exception. i’m asking why he is doing that every time after upgrade.
if your tunnel is down, you can’t switch partitons anyway. you need access for that.
The scheduler script does that. It is configured to run e.g. 5min after startup. It does switching partition. If bmann can log in, he just disables the scheduler. All good.
[quote=normis post_id=1101384 time=1728023525 user_id=5]
[quote=pe1chl post_id=1101268 time=1727969136 user_id=80589]
/system/device-mode/update partition=yes
expected end of command (line 1 column 28)
you cannot. 7.16 does not know about device-mode “partition”.
[/quote]
Are you serious? I am directly answering your question about bootloader settings.
If you are not interested in real answers, only trolling, you are welcome to join some other online community instead.
[/quote]
I think several people here agree that YOU are the one here that is trolling.
As someone else says: you are treating us like idiots.
When we ask you something, you switch to another topic.
And worst of all: when we ask to keep an existing capability, you are not positively trying to get a solution, no you go to the lame
“why would you want that” direction. It has already been established that we want it, the discussion is about how to achieve it.
pe1chl, why is this so hard to understand? your complaint is about routerboot settings, that you can’t switch to “try-ethernet-once-then-nand”. You can, switch now and upgrade later.
about partitions, their purpose is to reboot into backup, when device fails to boot. this works without any device mode changes or settings. if you have such a setup, nothing has to be done after upgrade. you can create partitions, copy active partition to backup partition etc. and it will fallback to backup, if device fails. no button press necessary.
infabo is right on my setup.
so clarification:
This is rollback in case there is something wrong - for example PPPoE client does not connect to server, problem with routing, firewall, vpn tunnel etc. It may happen due to some bug or other issues.
I do this because the device is remote and not easily accessible and this reduce the need to physical access to device.
Because “try-ethernet-once-then-nand” switches itself back to “nand” afterwards. pe1chl can change that one time on 7.16 when upgrading to 7.17. Afterwards he won’t be able to do that anymore. Except: allow “bootloader” in device-mode which involves physical access.
@normis
I think pe1chl, many user else and I use partitions not only as an automatic fallback, but as a backup if the new version doesn’t work as expected.
By the way, this method of using the partitions is also described on the MikroTik help page.
https://help.mikrotik.com/docs/display/ROS/Partitions
“This can be used as an interactive backup where you keep a verified working installation and upgrade only some secondary partition. If you upgrade your configuration, and it proves to be good, you can use the “save config” button to copy it over to other partitions.”
Wouldn’t it make sense to add an option to set the new device mode parameters via file when updating from version 7.16 to version 7.17? This would give the standard user the secure configuration desired by MikroTik and the advanced user can plan the update process and set the parameters as needed.