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
Hello,
Didn’t you update from 3.9.x?
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.
1 Like
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
DIE:
[string "transaction"]:317: [string "transaction"]:146: Collisions:
• /usr/bin/updater-wipe.sh: updater-ng (existing-file), updater-ng-migration-helper (new-file)
Aborted
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
1 Like
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:
https://bugs.openwrt.org/index.php?do=details&task_id=1541&order=id&sort=desc
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 receivedDDNS 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'
ddns.myddns_ipv4.enabled='1'
ddns.myddns_ipv4.interface='Lte'
ddns.myddns_ipv4.ip_interface='3g-Lte'
ddns.myddns_ipv4.ip_source='interface'
ddns.myddns_ipv4.lookup_host='****.duckdns.org'
ddns.myddns_ipv4.password='*password*'
ddns.myddns_ipv4.service_name='duckdns.org'
ddns.myddns_ipv4.use_https='1'
ddns.myddns_ipv4.username='****'
ddns.myddns_ipv4=service
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\nHello,
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 :).
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.
1 Like
I can confirm it, honeypot dont runing on port 22
but with command /etc/init.d/haas-proxy start
haas proxy started