The "mikrotik" account does not belong to a MikroTik user but to "someone" who used that name
Regarding your question, why should they do it for you?
No one is stopping you from reading the machine name in the script and inserting it.
1 Like
In standalone mode it works, thanks, but if used as CAP WiFi LEDs doesnāt work ( this behaviour was also before v7.22rc1)
These dināt make it in 7.22 yet?
You might have to set the LEDs by yourself in system/leds
In rc3 there are significantly more sector writes than in rc2.
With rc2, I had just under 5,000 sector writes in about 5 days.
Now, with rc3, there are already more than 9,000 sector writes within 7 hours.
I also found a supout.rif from version 7.21.2. On the same device, with an almost identical configuration, there were only 201 sector writes in approximately 9 hours.
How can I determine why there are so many more sector writes in 7.22rc3?
Could this be caused by containers?
edit: found out, that a specific container (step ca) is causing these writes. root-dir is on an usb disk, but apparently the healthcheck cmd (default-healthcheck-cmd=CMD-SHELL,step ca health 2>/dev/null | grep "^ok" >/dev/null) seems to cause this. The healhcheck calls are logged in the /container/log. Every time a log entry appears, sector writes increase a little. When the container is stopped, the sector writes do not increase anymore.
Actually I did not know ROS had container healthcheck support until now. Could it be something new?
What's new in 7.22rc3 (2026-Feb-26 10:37):
*) app - added health check for apps, which automatically rewrites the composed YAML;
Not using the app menu here. But apps are based on container. Does it rewrite a config file on every healthcheck interval? This could explain the increase in the sector writes between rc2 and rc3.
4 Likes
- winbox - added route ISIS tab;
Where can I find this? Canāt see a submenu ISIS under Routing. (tested with winbox 4.0.1 and 3.43)
After disabling the container with the health check, the sector writes were at 10087.
Now, about 10 hours later, the sector writes are at 10156. This indicates that container health check is the issue.
The fix should now be implemented before the final release.
update:
uptime: 1d5h13m24s
version: 7.22rc3 (testing)
build-time: 2026-02-26 08:37:18
cpu: ARM
write-sect-since-reboot: 80828
write-sect-total: 720410
What the happened? The container was stopped. Went away and now 80k writes out of the nowhere. this is more than 10% sector writes of total writes. And this device is several years old. Holy moly. Something is very wrong with this rc3.
Finally disabling healthcheck has stabilized sector writes:
/container/set healthcheck-cmd="" [find]
Only ~100 writes in the last 11hours after disabling healthcheck.
2 Likes
[SUP-209892]: LTE not working SIMCOM_SIM7600CE-T
broken again in rc3
rc2 working
@EdPa , is there any chance to stop making fun with MT users ?
Its called beta and RC for a reason.
Hopefully, they have a best practices and standard QC test folks, that look at each error and put in place processes to eliminate future errors. OR, maybe they just have 5 guys coding in a room eating pizza having a good laugh at your feedback.
1 Like
...:
after 3 pcs of RIF, testing different versions and messaging with support, they break it AGAIN
so, no, It's not funny
I am attempting a Netinstall on a cAP ax to upgrade from 7.21.3 to 7.22rc3 using the following command:
./netinstall-cli -e -v -a 192.168.88.3 routeros-7.22rc3-arm64.npk wifi-qcom-7.22rc3-arm64.npk
The device successfully updated, but the default configuration was applied anyway. After re-flashing, the device becomes inaccessible via Winbox on the ether1 port. After connecting through ether2, I can see that the default configuration is present despite using the -e flag.
Could someone please test the '-e' parameter on your device?
It seems like the '-e' switch is being ignored.
Check that you have the line:
Will apply empty config
in the output.
See:
Could it be that you also need the "-b" parameter?
I got a message in the Linux TTY terminal saying that an empty configuration will be applied. Iāve never used the -b flag or any kind of branding for several years.
Can you check this on a spare device on your side with netinstall-cli 7.22rc3?
A release candidate (RC) [ā¦] is a beta version with the potential to be a stable product, which is ready to release unless significant bugs emerge.
36 changes in rc3 tell me that a MikroTik RC is not even close to being a release candidate. It is beta at best. Even worse MikroTik seems to have a habit breaking existing functions in stable releases. IMHO they should review their software development practices.
3 Likes
Above the linked Wikipedia article, there is an image of a Windows 2000 Corporate Preview CD. That alone already suggests that the concept being discussed is somewhat outdated.
I have stopped trying to point out the formal definitions of software development phases. And this issue does not concern MikroTik alone. Even Microsoft, the company that produced the CD shown in the image, now releases stable updates that in earlier times would likely not even have qualified as an alpha preview for distribution on CD-ROM.
Software development cycles have become much faster. Costs are reduced, and it is widely accepted that software will contain bugs. Users are already accustomed to the fact that no software is completely free of defects. So from a business perspective, many companies no longer see a strong incentive to go the extra mile.
I think it is not so much about development practices or release names, it is about regression testing.
Before shipping (any) release, it should be tested in-house with a collection of configurations created over time. Each time some interesting/complicated bug occurs, there should be a test added and it should be run again before every release.
This is to ensure that installing an rc version (or even beta) to try out some indicated new or fixed functionality will not leave you facing a problem in existing functionality. A good example is the BFD problem introduced in rc1 (and fixed in rc3) due to a completely different change. BFD has been problematic in the past, so it should be part of the set of standard configurations tested before release, so such issues will be detected by the developers.
The āautomatically created certificateā is the result of the previous ACME/LE certificate migration to a new ACME client.
If the migration fails, a new attempt will be made on the next reboot.
Is that possible to clean up the failed certificates generated as part of this process? Because the www service is normally disabled on my routers, and the FW blocks the port by default. I think many people also have such configuration where they only temporarily enable the service and the port when then decide to invoke the renewal themselves (I have a script that handles that process).
In older versions RouterOS also tried to renew the certificates when the expiration approaches, and those automatic attempts naturally also failed. But only an error message was logged, and no bogus certificates pilled up in the certificate list.
It would be less disruptive if the router cleans up the failed certificates, and only logs the failed attempts, like previously.
from the corollary to Rule #10 (JFYI) :
[10] Translated from Mikrotikish, Beta means pre-alpha, RC means early Beta, stable means RC, rinse and repeat on a newer version, now you know. (if it ain't broken, don't fix it)