Turris OS 3.8 is out!

Dear Turris users,

Turris OS 3.8 is here at last! It took us slightly longer to release it, but we worked hard on it and we think the wait was worth it, because 3.8 has lots of new cool features. Many thanks go to our devoted community for helping us test all the new functions – thanks for being with us!

This time the main changes and improvements include:

• Foris now gives you the option to set bandwidth limits for the Guest network.
• A new function in Foris is also the option to propagate client names into local DNS.
• One big joint step for Foris and the Updater are Delayed updates. You can have a look at how to use the Delayed updates function in our documentation.
• Russian, Danish and Lithuanian community translations have been added to Foris. You can turn these languages on in the “Updater” tab in Foris …and if you would like Foris to speak your own language, consider becoming a community translator ;-)!
• Userlists changes include trimmed down dependencies.
• Suricata has been updated to a new version with more modular configuration and helper packages.
• Php7 is now newly supported!
• A new package has been added: MariaDB.
• A big new feature is the support of Nextcloud – a popular home cloud solution! Support is still in trial operation and installation is mostly for experienced users [instructions can be found here] (https://www.turris.cz/doc/en/howto/nextcloud), but we hope to make simpler setup available through our web-based configuration interface Foris in the course of this year.
• Hardware feed – we added a few hardware related packages.
• We haven’t forgotten about our Turris 1.x users and we added Btrfs support for Turris 1.x. Have a look at the at the manual here.
• We’ve introduced basic NFS4 support.
• And last but not least a we now have a faster boot!

Have fun using the new functions and thanks for your support!

your Turris team

5 Likes
root@omnia:~# updater.sh
WARN:Script revision-specific not found, but ignoring its absence as requested
WARN:Script serial-specific not found, but ignoring its absence as requested
WARN:Request not satisfied to install package: dnsmasq
DIE:
inconsistent: Requested package lftp that is not available.
root@omnia:~# opkg install lftp
Package lftp (4.7.3-1) installed in root is up to date.
root@omnia:~#

remove LFTP:

root@omnia:~# updater.sh
WARN:Script revision-specific not found, but ignoring its absence as requested
WARN:Script serial-specific not found, but ignoring its absence as requested
WARN:Request not satisfied to install package: dnsmasq
DIE:
inconsistent: Requested package transmission-web that is not available.

remove transmission-web, upgrade.sh works after that.
sigh… :scream:

Russian UI is broken


Reverted to English.

+1

Especially since it is the guest wifi… Maybe there could be a link added to the foris wifi page (so leaving the config at the LAN page is fine, just add a “pointer” from the wifi page as well for all those expecting wifi controls on the wifi page :wink: )

I’m having some problems on one of my two Omnias.

root@turris_border:~# /usr/bin/updater.sh
WARN:Script revision-specific not found, but ignoring its absence as requested
WARN:Script serial-specific not found, but ignoring its absence as requested
DIE:
[string “planner”]:175: attempt to index field ‘?’ (a nil value)

Any ideas?

Did this break DNS for others as well? See 3.8 - forwarded DNS resolution not working - even though dig against ISP's DNS servers works fine

Our router seemed to lock up at around 21:00 BST while watching streaming TV, not responding to dhcp on wifi or lan. I powered it off and on and when it rebooted I discovered it was attempting to install this update.

I really do not want the router auto updating itself and potentially breaking during waking hours again as it is extremely inconvenient. (Currently it seems local host resolution, which was working before, is now broken.)

I had incorrectly assumed the automatic reboot being set to 3:30 would mean updates would be delayed too. Can this delay be implemented in a future update, please? It would be even worse breaking itself during the working day.

Many thanks.

Delayed updates are new feature implemented in the update your router is trying to install :wink:

Reading the documentation though it says it can be delayed by a certain number of hours which I interpreted to mean an absolute offset from whenever the router discovers an update is available, rather than delay until a specific time period.

I suppose I’d quite like to say: “delay at least 48 hours and only install automatically between 3AM and 6AM.”

1 Like

Yes, DNS broke for me. But disabling “Use Forwarding” in Foris fixed it for me.

EDIT: I had other issues listed here, but they were my own fault due to changes I had personally made in DHCP/DNS. Currently working through things, will report back if any other issues arise.

EDIT2: Everything seems to be working again for me. In my setup, I have had the resolver initscript disabled to forward DNS to a local server. The update to 3.8 reenabled resolver. Once I disabled it again, confirmed my settings, everything is back to normal. I can even enable “Use Forwarding” in Foris again and all is well.

1 Like

@Davey:
I have got same error. For me the solution was

root@turris:/etc/updater# cp auto.lua-opkg auto.lua

@miska:
Any idea why this was needed? Content of the files:
root@turris:/etc/updater# cat auto.lua
– A file with auto-generated Install commands. Do not edit.
Package “knot-resolver” { content = “file:///usr/share/updater/local-pkgs/knot-resolver_1.2.5-3_mvebu.ipk” }
Install "knot-resolver"
Install "kmod-usb-serial-ftdi"
Install "ser2net"
Install "netcat"
root@turris:/etc/updater# cat auto.lua-opkg
– A file with auto-generated Install commands. Do not edit.

1 Like

For anyone who was previously forwarding local domain DNS to dnsmasq, I replied in the linked thread with how I updated this following the 3.8 update. (I use quite a complex dnsmasq setup with CNAME and SRV records etc, which I wanted to keep, instead of switching to the new built in local domain resolution option.)

Strange behaviour here:

  • After update no 5GHz-wifi anymore. Restart brings back the 5GHz-wifi as expected (driver-update?).

  • trying to access the web-interface didn’t work - neither via WLAN nor via LAN (neither before nor after the restart).
    Updater logfile doesn’t show any errors.
    DHCP works, trying to restart kresd leads to:

    root@Turris:~# /etc/init.d/resolver restart
    Called /etc/init.d/kresd stop
    /etc/rc.common: eval: line 1: get_dnsmasq_dhcp_script: not found
    Called /etc/init.d/kresd start

Any suggestions on how to get back the webif-functionality?! (Because without webif I cannot adjust stupid update-behaviour - it’s been updated just before my girl-friends wanted to start her streaming-evening. WAF=0!)

I have the same experience. Updates turned off. Install them manually. One time, after electricity takedown, when router was restarted, unwanted update happen. I guess there are some startup scripts for updates…

For devs: Are there any changes on .lua syntax? For example, I have this user.lua:

Package “mysql-server” { content = “file:///root/upravy/packages/mysql-server_5.1.73-2_mvebu.ipk” }
Install "mysql-server"
Package “vncrepeater” { content = “file:///root/upravy/packages/vncrepeater_0.17-4_mvebu.ipk” }
Install "vncrepeater"
Install "mc"
Install "lighttpd-mod-redirect"
Install "collectd-mod-thermal"
Install "collectd-mod-memory"
Install "collectd-mod-wireless"
Install "collectd-mod-cpu"
Install "collectd-mod-openvpn"
Package “collectd-mod-cpufreq” { content = “file:///root/upravy/packages/collectd-mod-cpufreq_4.10.8-3_mvebu.ipk” }
Install “collectd-mod-cpufreq”

Will be update without problems? I have disabled automatic rewrites of config files by update, so It would be good to know beforehand.

Looks like you installled knot-resolver manually from lokal repo for some reason, no idea why.

There is a change in syntax (updater will tell you that), instead of space after keyword, it should be parenthesis around arguments, like:

Package("vncrepeater", { content = "file:///root/upravy/packages/vncrepeater_0.17-4_mvebu.ipk" })

But the current syntax still works, so don’t worry, you have time to migrate before we phase the old one out completely.

1 Like

Missing transmission-web (again) and luci-i18n-ddns-en packages.
Please add quickly at least transmission.
Thank you…

I suppose I’d quite like to say: “delay at least 48 hours and only install automatically between 3AM and 6AM.”

I’ve already reported that this is the problem. But nobody answered…

1 Like