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 Fixes
⢠Fixed USB 3 port on Turris MOX module A
⢠Fixed SDIO card for Turris MOX
Updates
⢠Updater-ng updated to version 70.1.0
⢠RIPE Atlas Software Probe updated to 5080
We appreciate any feedback regarding this release.
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.
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?
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.
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
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âŚ
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
# rainbow -h
Turris leds manipulation.
Usage: /usr/bin/rainbow [OPTION].. <OPERATION>...
Options:
-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
Operations:
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).
Options:
-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
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.
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.
Bug Fixes
Updates