Turris OS 3.11.4 is released!



This update isn’t good. My LG TV can’t connect to internet throught wired connection, Lenovo tablet wifi drops quite often. Every change saved in the Fortis, crashes the interface see error after save of DNS changes.

Traceback (most recent call last):
File “/usr/lib/python3.6/site-packages/foris_controller/message_router.py”, line 117, in process_message
data = module_instance.perform_action(message[“action”], message.get(“data”, {}))
File “/usr/lib/python3.6/site-packages/foris_controller/module_base.py”, line 59, in perform_action
res = action_function(data)
File “/usr/lib/python3.6/site-packages/foris_controller_modules/dns/init.py”, line 45, in action_update_settings
res = self.handler.update_settings(**data)
File “/usr/lib/python3.6/site-packages/foris_controller/utils.py”, line 112, in inner
res = func(*args, **kwargs)
File “/usr/lib/python3.6/site-packages/foris_controller_modules/dns/handlers/openwrt.py”, line 71, in update_settings
File “/usr/lib/python3.6/site-packages/foris_controller_backends/dns/init.py”, line 110, in update_settings
backend.set_option(“resolver”, “common”, “forward_custom”, forwarder)
File “/usr/lib/python3.6/site-packages/foris_controller_backends/uci/init.py”, line 144, in exit
File “/usr/lib/python3.6/site-packages/foris_controller_backends/uci/init.py”, line 246, in commit
self._run_uci_command(“commit”, config)
File “/usr/lib/python3.6/site-packages/foris_controller_backends/uci/init.py”, line 173, in _run_uci_command
raise UciException(cmdline_args, stderr)
foris_controller.exceptions.UciException: [‘uci’, ‘-c’, ‘/etc/config/’, ‘-p’, ‘/tmp/.uci-foris-controller’, ‘commit’, ‘dhcp’]: command failed



It isn’t possible to save the report because of the foris crash only busy indicator is spinning , so there is nothing to send


And the story continues. Now no device can connect to Internet using Turris router and my household is completely cut off from the Internet - I’m writing thanks to my mobile hotspot. I tried to return to the previous router state before update but Schnapps is also corrupted

   root@router:~# schnapps list
mount: mounting /dev/mmcblk0p1 on /mnt/.snapshots failed: Invalid argument
    # | Type      | Date                      | Description
ERROR: cannot find real path for '/mnt/.snapshots/@33': No such file or directory
   33 | single    |                           |
ERROR: cannot find real path for '/mnt/.snapshots/@35': No such file or directory
   35 | single    |                           |
ERROR: cannot find real path for '/mnt/.snapshots/@37': No such file or directory
   37 | single    |                           |
ERROR: cannot find real path for '/mnt/.snapshots/@122': No such file or directory 

Really it was very bad idea from the NIC release the update just before holidays…


My Turris Omnia stopped to assing the IP numbers after the automated reboot. It was not possible to reach it over the wired connection.

The 2 LEDs reset did not resolved the problem.

The 3 LEDs reset solved the situation. But all the settings are gone obviously…


schnapps should have created a pre-update snapshot that could be rolled back to. And from there the update could be tried manually from the ssh cmd to see whether the update succeeded or to discover any errors in the process.


Not a single setting is gone - schnapps does a snapshot before rolling back. And there you can also have a look into updater logs (by mounting the relevant snapshot) to see what went wrong without having to run updater again…
But before rolling back one should try to assign a static IP to the PC that you try connecting to TO with to start troubleshooting. That way you save time if it would have only been a not running DNS :wink:


updated 2x Turris Omnia

issue with DHCP dates same as guys posted already

I offline soon :slight_smile: some devices already lost connection to the internet edit:- after reboot is ok


In my case the last update damaged DNS server, but also schnapps. I have no option to recover from this “spoiled Easter egg”


Good practice for disaster recovery is to export the last good known snapshot (mind you to export to /tmp in order to mitigate writes to the device’s eMMC) and download it to a client for safekeeping. It can then be used to restore such last good know snapshot either with 4 LED restore or with upload from client to the router and schnapps import


I did’t realized that schnaps on Turris is such unreliable. It’s big dissapointment for me. I hope that configuration backup stored on NIC servers save me some time.


I’m really sorry that happened to you, but everyone will sooner or later come across the definition of a backup:
The only thing that does reliably help you is making at least two (the more paranoid, the more) copies of your backup that are stored completely offline and completely separated from the productive environment at two different places and regularly tested for data integrity.
Buy two cheap USB-Sticks and export working backups as advised by @N8v8r .
I myself write down every configuration I do (and why I do it!) in a document to be able to completely rebuild such a environment from scratch if necessary.


I know concept of backup :grin:, my data are bakupped correctly. I’m really disappointed from reliability of Turris which is like Russian roulette.


During the entire time of the Turris router I used the recovery using schnapps 3 times. I usually caused the problem with my faulty settings. Now I put the backup schnapps still on the flash drive and then on Windows desktop. I have previously backed up some configuration files.


@Radovan_Haban I am sorry but I suspect that this is not a problem with update. The output you posted clearly fails to mount /dev/mmcblk0p1 which is root file system. That might be caused either by failed storage or some problems with kernel. I have to ask if this is after or before system reboot. You should reboot router after update if you encounter some problems.

candela tech. drivers are known to be unreliable and we had to switch away from them because of stability. If you encounter problems then you should switch back from them. Also if you are reporting problem with nonstandard configuration please start with that, you scare other users with formulation you used. Thank you.

It means that file wont be overwritten if it differs during update. Configuration files migration is not part of that and has to be done on per-package bases and in OpenWRT pretty much nobody does that so don’t expect that. In this case I suspect that comparing it to upstream it is clear that not having it set as configuration file was a bug.

I am sorry to hear that. If you did only factory rollback then all settings can be still accessible using schnapps. There is going to be factory rollback snapshot you can mount and access latest configuration. May I ask if you have any idea what happened? This seems to me like a common problem where users disable kresd and set dnsmasq to port 53. Updater later reenables kresd which prevents dnsmasq from starting and that way DHCP no longer works.

@BuloZB thank you for reporting. We already know about that and we reproduced it. It is nothing more than frontend issue. Special meaning value (zero) is interpreted invalidly as a time which is date you see.


There is clearly written that I speak about -ct drivers. I don’t follow what’s in a default installation now, or not. Thus, I cannot provide any additional information to your scared users.
If you provide solid non-ct modules, I will use them. But now, they are not usable for me at all.

My motivation to use -ct modules was caused by the buggy ath10k module, which crashes under the heavy wifi load.


I just waned to inform you about our experience with candela tech. drivers. It is weird because crashes under high load and with some specific devices was a reason why we don’t have ct drivers in default install. The only advantage why we want ct drivers is that using them we gain performance boost which is nice but with level of stability they provide currently we probably don’t want to have them as default. Can you please try standard ath10k drivers and see if you encounter any problems?

It was just a suggestion you don’t have be immediately offended. You clearly know that ct drivers is something you changed and that it is non-standard. I was just asking you to use next time different formulation. You stated that you are using ct drivers, I am not arguing about that. The problem is that you stated that as second sentence and in separate paragraph. Most quick readers won’t read that. Compare it with this kind of formulation: “I am running ath10k-ct drivers and 15 hours after auto restart 5g wifi died.” In this case reader as first immediately see that problem is with specific driver and not general problem.


after this update I have issue with 2x TO routers they rebooting in random time. I dont know how to debug it. I dont have any high usage CPU/USB storage aplications any hints how to debug it?.. also all logs are gone after reboot.

can someone hint me how to move all logs to the USB disc storage?
btw can we get this in luci or foris interface in future? more user friendly option where to store all logs?


To store logs on USB, edit /etc/syslog-ng.conf. First, add section

destination nas {
        file("/mnt/nas/data/omnia-logs/${R_YEAR}/${R_MONTH}/messages-${R_YEAR}${R_MONTH}${R_DAY}.log" create-dirs(yes) dir-owner(root) owner(root) dir-perm(0755) perm(0755) suppress(5) template("${R_HOUR}:${R_MIN}:${R_SEC}  ${PRIORITY} ${PROGRAM}[${PID}]: ${MSGONLY}\n") log_fifo_size(256));

Then either edit the existing log statment, or add a new one:

log {

You can then play with the filters so that it doesn’t write to the USB drive like hell. But if you only have it as a temporary solution for finding a bug, I think it’s okay to leave the default filter set.


Probably is better solutions to create a new file (something backup-hdd.conf) in Edit: /etc/syslog-ng.d/ whit this parameters inside.