Turris OS 3.10.1 released!



The update installed automatically. But since then my VPN connection (as client) to ExpressVPN doesn’t work anymore… I didn’t change the settings

TLS Error: TLS handshake failed


pkgupdate fails with

inconsistent: Package nut-common requires package nut that is not available.

i cannot upgrade to 3.10.1 or install nut


Thanks for reply, yep, registration code exisist and password for cloud backups is in /etc/config/ssbackups.

I can create,delete backups, but cant keep them in forris. I dont try restore from cloud backup


No in general it works, I’m using UAS with a drive I have connected to my Omnia at home. Other thing might be that in 4.4 kernel your drive is wrongly matched as known to be faulty. I’ve seen some discussions that some hardware manufacturers don’t bother bumping productId when they release a new chip and that some product were on the other hand too broadly banned in kernel.

So probably the easiest answer would be to wait for Turris OS 4.0 which will come with kernel 4.14



Didn’t you update from 3.9.x?


@miska: Okay, I’ll wait then :wink:


I took no action. I don’t know if I updated from 3.9.x. My device is unattended, yet still has these problems. Why doesn’t the Turris team test against an unattended device?

We are trusting you to push us safe, well-tested updates and this is not the first time problems like this have occurred. Luckily the consequences this time are an error message and nothing more serious.


I have same problem…

Press return to continue, CTRL+C to abort

INFO:Executing preupdate hooks...
INFO:Unpacking download packages
INFO:Checking for file collisions between packages
line not found
line not found
line not found
line not found
line not found
line not found
[string "transaction"]:317: [string "transaction"]:146: Collisions:
• /usr/bin/updater-wipe.sh: updater-ng (existing-file), updater-ng-migration-helper (new-file)

I haven’t the package updater-ng-migration-helper installed.

root@turris:~# opkg remove updater-ng-migration-helper              
No packages removed.

Turris 1.1, v3.9.6


Did you try to start it in luci>system>startup? Since that solved it for me the last time…

Best, Dikke


3.10.1 still spams the log with those annoying “sit: non-ECT from…” kernel messages. Unfortunately it’s an upstream problem from the mainline kernel, read this thread at OpenWRT if you want to know the details:


Workaround: add the line

echo N > /sys/module/sit/parameters/log_ecn_error

to /etc/rc.local . I suppose that Turris’ autoupdate changes the files under /etc/modules.d, so this will survive kernel upgrades, unlike supplying parameter directly to the module.


Today at 12:31 AM my Omnia which was upgraded to the latest firmware 3.10.1 yesterday sent me the following email:

##### Update notifications #####
Updater selhal:

unreachable: https://repo.turris.cz/omnia/lists/honeypot.lua: No OCSP response received


DDNS was working fine before 3.10.1, now:

2018-06-09 15:36:04 warning ddns-scripts[18791]: myddns_ipv4: Service section not configured correctly! Missing 'domain' - TERMINATE
2018-06-09 15:36:04 warning ddns-scripts[18791]: myddns_ipv4: PID '18791' exit WITH ERROR '1' at 2018-06-09 15:36

 150926       : ************ ************** ************** **************
 150926  note : PID '7090' started at 2018-06-09 15:09
 150926       : ddns version  : 2.7.7-6
 150926       : uci configuration:\nddns.myddns_ipv4.cacert='IGNORE'
 150926       : verbose mode  : 0 - run normal, NO console output
 150926  WARN : Service section not configured correctly! Missing 'domain' - TERMINATE
 150926  WARN : PID '7090' exit WITH ERROR '1' at 2018-06-09 15:09\n



Thank you.

Yesterday, I sent you PM and I’m glad that you have it working.

We’re working on it and it will be fixed in Turris OS 3.10.2.


I’m also having the same issue trying to upgrade from 3.9.6. Was there something you shared in the PM that helped @BrozikCZ? (Or @BrozikCZ can you share what you did?)


Thank you very much :).


From terminal:

opkg-trans -r foris

That works for me. Thanks @Pepe

Updater fails on new Omnia

That did it, thanks!


I had to change settings in luci to get it working again.
I had to put the host name also in the domain field and In advanced settings, I selected network and provided the network (Lte).
Nevertheless, luci still shows in advanced tab wrong interface (eth0)


Since the upgrade the HaaS honeypot is unreachable on port 22 despite being up and running and being reachable on port 2525.

/etc/init.d/haas-proxy restart produces

iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.

Removing/reinstalling HaaS does not cure the matter.
Restarting first the firewall and then HaaS is no remedy either.

HaaS does not log [WORKAROUND]

I can confirm it, honeypot dont runing on port 22
but with command /etc/init.d/haas-proxy start

haas proxy started