Turris OS 6.2.2 is out!

Dear Turris users,

We released Turris OS 6.2.2 from the testing branch. We prepared this version primarily for Turris MOX owners as there is a fixed USB 3.0 port on module A, and we also looked at SDIO card as well. However, for the SDIO card, there still applies Erratum. Other Turris devices will enjoy this release, too as we updated Linux kernel, RIPE Atlas SW Probe, unbound, etc.

Highlights for this release:
:bug: Bug Fixes
• Fixed USB 3 port on Turris MOX module A
• Fixed SDIO card for Turris MOX

:pushpin: Updates
• Updater-ng updated to version 70.1.0
• RIPE Atlas Software Probe updated to 5080

We appreciate any feedback regarding this release.


Awesome, I can use one 5GHz and one 2.4GHz network on my Turris Mox again. Thanks for the update!

Just to shed more light on the sdio wifi fix: according to Draft: mox-support: Add hacky overrides for SDIO card (!1042) · Merge requests · Turris / Turris OS / Turris OS packages · GitLab , the fix is done by enforcing legacy_rates 1 config (which I understand as supporting 802.11b). If I got all the consequences right, this might result in a slight sluggishness of the whole wifi network as the AP forces all clients to broadcast “service traffic” on the slower rate that is understood by the 802.11b devices.

Also WPA3-SAE is forcibly disabled by this fix (it is downgraded to WPA2 PSK).

Tried recovery instructions, it blinked twice, but nothing happens. Not reachable via network, no WiFi, it’s dead. What now.

Why does this happen on every update?

//EDIT: Same as here Turris MOX does not start - #3 by bamf Boot loop, no longer reachable

//EDIT: Tried Unsecure SSH, also not working. Blinking five times, waited 5 minutes, no device on

Going to re-flash everything from scratch again. Like last time. Why does every update brick the device?

MOX classic, HBK branch, .5 GB, 2x WiFi, simple config
USB3 is working!
Unfortunately this is not case of SDIO WiFi - testing it I’m affraid it’s not working still, at least for me.
Diagnostics was sent to support, just in case.

TO 2016, HBS branch, 2 GB, 2x WiFi, HaaS, RIPE Atlas, Sentinel, lxc, simple config, all seems OK.

1 Like

I dont understand. What is going on?

Again today tried to update from TOS v5.4.4 to v6.2.2 and again i witness bright LEDS, Linux container is not visible anymore. Just like when i tried to update to v6.0. When i did a rollback back then one day it automatically pushed the v6.0 without me approving it first (which i have configured it like). Then i decided to turnoff the automatic updates until things were fixed.

Have i been missing something that you guys already have pointed out to fix first before updating to the latest firmware or i really have to just wipe EVERYTHING and update to v6.0. Then start configuring everything from scratch again?

1 Like

Your network, your rules/policy.
BUT generally trying to skip released versions hoping that some issue will be fixed in the meantime is a recipe for unhappiness. The way OpenWrt is developed is that backward incompatible changes are often accompanied by helper scripts that try to translate old incompatible config files into the newer working version, but such scripts are typically not carried indefinitely into the future.
The consequence is that when leaping over (multiple) versions one can end up with a situation where one needs to re-create the desired configuration from scratch.

That said, after a full reboot the LEDs are at full brightness although pressing the button shows that the internal brightness state was conserved. E.g. in my case I keep the LEDs at lowest visible brightness, after a reboot they are at full brightness, but pressing the button once turns them off completely and it takes another 7 presses (for a total of 8, a full cycle) to get the LEDs back to my desired brightness, indicating that the internal state was correct. Interestingly the set state seems to be conserved for most of the boot cycle, the “brighten-up fully” step happens only very late in the boot (actually at that point I can reach the omnia via both HTTPS and ssh).
Personally, I do not care much about this, as for me this is a cosmetic issue, but I understand that there are use-cases (like studio apartments where bright LEDs might disturb one’s sleep) where this is more annoying/problematic.

1 Like

For me also it is not a big issue (LED lights) and yes i know if i keep using the old version and going to a newer version that is much later version is asking for troubles. So i indeed am afraid that i just need to save all the settings and just do a factory reset on 6.2.2, and you are simply confirming it that that is the only way.

I have no evidence one way or the other, but I do suspect that by now re-creating the config is the best way forward.
Note to self, I am still carrying a config from the TOS4 days, and probably should look at re-creating it from scratch to remove all old cruft, but my motivation is low as most things work as desired :wink:

It is not that hard to be honest as i am a Linux engineer by profession, however it takes just a lot of time and i still have not fixed ansible playbooks for the Turris Omnia, so i guess i am being forced to start creating one. Thanks anyways.

Is there a command I could use to set the brightness? So that it would be possible to include it in rc.local to mitigate this? I am one of those who find it quite annoying that it reverts to max brightness with every reboot…

rainbow brightness {0-5}
0 is off, 5 is max.


Thank you. However, the command sort of works and sort of doesn’t. The value of 0 turns the LEDs off, but the value of 1 sets it to the 3rd lowest setting - after that I can click the HW button two more times to get to the lowest setting (other than off). I guess better than full brightness, but still not possible to get the lowest brightness. Also, for some reason it outputs this:

Command failed: Not found
Command failed: Not found

I can confirm everything you wrote. Various Command failed: Not found I find even if I run the wrap command service.

1 Like


# rainbow -h
Turris leds manipulation.

Usage: /usr/bin/rainbow [OPTION].. <OPERATION>...

  -p INT  Set priority to given led setting (in default 50 is used)
  -n STR  Slot name ('default' used if not specified)
  -l      List all available LEDs by name
  -x      Run in debug mode
  -h      Print this help text and exit

  reset       Reset rainbow state (wipe any runtime changes)
  brightness  Set upper limit on brightness of all leds
  all         Configure all available leds at once
  ledX        Where X is number (up to 12 on Omnia and 8 on 1.x)
  Configure specific led by name:
    power lan-0 lan-1 lan-2 lan-3 lan-4 wan wlan-1 wlan-2 wlan-3 indicator-1 indicator-2

Every operation has some additional arguments. You can list them by
passing -h option after specifying the operation.

# rainbow brightness -h
Usage: /usr/bin/rainbow brightness [OPTION].. <VALUE>
Set maximum brightness (the global modifier for all controlled leds).
The brightness has to be specified as number between 0 and 8 (or 255
if -p is used).

  -q  Query for current setting instead of setting brightness
  -p  Higher precission for brightness
  -h  Print this help text and exit

In your case, I assume, you would like to issue command
rainbow brightness -p 1

Note: sometimes there is warning message, which can be ignored

1 Like

Btw, i decided to start today with it and indeed much was changed when you would be talking about configuration etc. So just used the medkit and slowly compared the configuration i had with the one that came with v6.2.2. Everything is running fine including LXC (needed to set mountpoints again, directing the lxc folder to my mSATA ssd, recovering my old lxc-auto and worked just fine.

Perfect! Although I have to use -p 3 for the Omnia and -p 32 for the old Bluey, any number lower than that turns the LEDs off. Thanks!

6.2.1->6.2.2 update ok (no new problems introduced), no unintended cable/wifi or internet downtime. Restart needed.

Turris Omnia 2017, 1 GB RAM, dead eMMC, system running from mSATA SSD, original wifi cards. Storage plugin enabled, LXC containers, tor relay, USB HDD shared over samba4 and minidlna, SQM, Hardwario gateway + MQTT IoT bridge, OpenVPN, PPtP VPN, morce.

6.1.0 HBS ->6.2.2 HBS update ok (no new problems introduced), no unintended cable/wifi or internet downtime. Restart needed. For some reason, I had to manually restart kresd after the reboot to get DNS working for client computers. It was working correctly on the router itself.

Turris Omnia 2017, 1 GB RAM, dead eMMC, system running from mSATA SSD, original wifi cards, WAN via DHCPv4. Storage plugin enabled, USB HDD shared over samba4 and minidlna, OpenVPN, PPtP VPN, minipots, custom Turris Webapps on Node.js webserver.

6.1.0 HBS ->6.2.2 update ok

Thank you team!

1 Like