I need to take back this statement. There seems to be a (new?) bug in LED configuration - with every restart of the router it is reset to /etc/config/system
config led
option name 'Auto-configuration for PCI1'
option sysfs 'omnia-led:pci1'
option default '0'
option trigger 'none'
config led
option name 'Auto-configuration for PCI2'
option sysfs 'omnia-led:pci2'
option default '1'
option trigger 'netdev'
option dev 'wlan1'
option mode 'link tx rx'
config led
option name 'Auto-configuration for PCI3'
option sysfs 'omnia-led:pci3'
option default '1'
option trigger 'netdev'
option dev 'wlan0'
option mode 'link tx rx'
I think this is default configuration of TO with 2,4/5GHz-card in mPCIe-slot 2 and a 2,4GHz-card in mPCIe-slot 3, right?
I changed this configuration because of bad position for 2,4GHz-card (see other thread for this) and now have default TO 2,4/5GHz-Card running in mPCIe-slot 1 and a WLE1216V5-20 in mPCIe-slot 2 with the following configuration:
config led
option name 'Auto-configuration for PCI1'
option sysfs 'omnia-led:pci1'
option default '1'
option trigger 'phy0tpt'
config led
option name 'Auto-configuration for PCI2'
option sysfs 'omnia-led:pci2'
option default '1'
option trigger 'phy1tpt'
config led
option name 'Auto-configuration for PCI3'
option sysfs 'omnia-led:pci3'
option default '1'
option trigger 'none'
Edit: my fault, this is not bug, but intended feature (see posts below).
Disabling LED-autoconfig-script solved my issue.
Did you found some solution (or is it already fixed)? I just rebooted my Omnia after updating TOS and in my case all fine. If you still have this issue, let me know what/where to check, maybe we can find some difference/fix.
Sorry for the late answer. I havent made any changes to the kresd. In fact I am trying to limit changes to bare minimum (e.g. reserving certain IP addresses for devices in DHCP). Thats why I am surprised to see that the updates are causing issues…
Thank you for your link. You can see that we are working on it. Right now it is in test branch, which doesn’t automatically means that it will make into the final release of Turris OS 3.11.5. It can be prepared but it is also possible that it could be reverted if it will break things in different configurations. It happens and it is really bad if you hype other users in things, which won’t be there after all. I suggest waiting for RC thread, where we will post release notes for it.
What I can tell you right now that Nextcloud 16.0.1 will be available in the upcoming version of Turris OS 4.x.
I use the Turris in the same way and even if I stick with these rules I had serious problems 3 times after update and once cca 2 months ago the update completely destroyed BTFRS and I had to completely reinstall Omnia from medikit. This is definitely not the behaviour and reliability I expected when I ordered Omnia. Mentally I’m ready to buy another router - probably the Synology one…