Turris OS 4.0.3 is released!

Community office
, , , ,
1

Dear Turris users,

We have just released Turris OS 4.0.3 from HBT(Testing) branch to everyone. You should be updated to this version automatically and if you are using approvals, you can check Updater tab to approve it.

This release contains security fixes for libvpx, git, and as well some bug fixes for kernel, tvheadend.

Release notes for this release :
• Merry Christmas!
:bell::bell::bell:
• kernel: updated to version 4.14.158
• foris-controller-subordinates-module: limit custom name length
• tvheadend: ensure the first setup works
• libvpx: fix CVE-2019-9232, CVE-2019-9325, CVE-2019-9371, CVE-2019-9433
• git: updated to version 2.16.6, fix CVE-2019-1348,CVE-2019-1349, CVE-2019-1350, CVE-2019-1351, CVE-2019-1352, CVE-2019-1353, CVE-2019-1354 , CVE-2019-1387

Some of you were asking if Turris OS 4.x will be available for Turris 1.0 and Turris 1.1 routers. Those routers were given mostly to Czech people during the research project and we would like to announce experimental support in this release if you are booting from microSD card using BTRFS that you can try it! We hope you will enjoy it and if anything appears, please discuss it in the separate thread, which will be created.

image

How to have and configure your router from scratch to Turris OS 4.x on Turris 1.x routers?
You need to do five things. First, at all, you need to download medkit from HBS branch and you can check checksum. Then, you will import it to the factory, rollback to factory snapshot and reboot your router.

wget https://repo.turris.cz/hbs/medkit/turris1x-medkit-latest.tar.gz
schnapps import -f turris1x-medkit-*.tar.gz
schnapps rollback factory

And that’s not all. We have prepared a christmas package for Turris Omnia and Turris 1.x routers.
You can shine with your router like Christmas tree. More details on how to enable it can be found in community documentation Christmas package [Turris wiki] and if you are interested in source code, let’s take a look here.

We wish you a Merry Christmas!

2 Likes
3

any news and planned date when Omnia users will be able to migrate to TOS 4.0?
It was told by the end of this year earlier and the year is over soon :slight_smile:

4

reForis tabs still not working.

5

MOX .5GB, WiFi, simple config (Data Collection, SSH Honeypot, LuCI extensions, Internet connection speed measurement).
Didn’t request reboot, after forced reboot by Foris didn’t come to life for more than 5 minutes :frowning: thus powered out.
Seems OK.

6

So it is still not recommended to reflash my Omnia for this version? Not stable enough as old 3.x?

7

In this update, there were no updates for redesigned Foris (reForis), which is still in the development stage. It would be mentioned in the changelog.

ReForis is not the default interface, yet. Most of the bugfixes appear in development branches. Those were not backported to HBS, yet. It works for me in the HBS branch. The latest development versions of reForis can be found in HBL/HBD branches.

Without providing additional details (os, browser, etc), we don’t know why it does not work for you and even diagnostics counts.

1 Like
8

It is working in “sandbox” environment since mid of this year. We are still ironing out some issues. You can see updates here: Migration from 3.x to 5.x (#344) · Issues · Turris / Turris OS / Turris OS packages · GitLab

The main blocker before we release it for public testing are some hacks in updater (lists/migrate3x: Add provides and virtuals to pass migration (!59) · Merge requests · Turris / Turris OS / Turris Build · GitLab).

Secondary, automatic migration (meaning not triggered by user) is going to come with Turris 5.x rather than 4.x because of missing samba4 in 4.x.

It is recommended. Just know that it won’t be without issues (but migration won’t be either). I think that currently some stuff are even more stable on 4.x+ over 3.x. Don’t get confused by reports of issues to something that is not yet part of core system (reForis is only experimental). Note that some features are and will be missing. Data collection is not yet fully done but dynamic firewall is present. Ssbackup and mobile app are no longer supported with 4…x. Kernel changed a lot and some hardware can (including on board switch chip) are supported differently. On the other hand regarding stability it is an improvement I would say.

1 Like
9

Thanks.
What do you mean by automatic migration without user intervention? does it mean we may still have a button to press to upgrade also in 4.0?
Do we have an approx. release date for TOS 5.0 for migration?
What happens if someone reflash 4.0, when he had a NAS configured previously?

10

Turris OS 5.0 is based on OpenWrt 19.07, which is currently in RC2. According to OpenWrt mailing list or IRC channel #openwrt-devel on Freenode, there is still ongoing discussion when they will release it, but there are some blockers. If there is anything new, we will let you know in the dedicated thread about Turris OS 5.0.

It depends how you have it configured. By re-flashing you will start from scratch, which means you will need to configure mount points, install or edit configuration file for sharing applications like minidlna/samba3 and so on.

11

Hi there,

I came from 4.0.2 and got the message about 4.0.3.
From there the horror began. The update ran forever, then the memory ran full and even a restart didn’t work.
Roll back to the last snapshot, everything went again and second try. Now I have deactivated the DDNS service and it worked. But it also took a long time until I got the message that I should restart.
Today I got this message:

Updater failed:

runtime: [string “requests”]: 395: [string “utils”]: 427: URI download failed: Couldn’t resolve host 'repo.turris.cz’

The package manager in LuCi says the following:

Collected errors:
opkg_conf_load: Could not lock /var/lock/opkg.lock: Resource temporarily unavailable.

I also observe a high CPU consumption over the entire runtime. Netdata says for “system” 40-45% and “user” around 10-15% permanently. That wasn’t before either …
that seems too high and doesn’t explain itself to me, does someone else have it too? Or is it due to sqm?

what should I do or could he temporarily not resolve?
Everything else now seems to be working.

Best regards

12

I would definitely like to try it on my blue Turris 1.0. But I got a lot of functionalities working on my current TOS 3 like LXC, pihole, My first question is is there LXC working with debian PPC ? Is CGROUPS and other options included and compiled into kernel for LXC ? Without LXC I could not use PIHOLE and bunch of other packages that I run on debian containers.
Second question how to try it safe way ? Should I rather take SD card out and make copy of it and run test on copy to prevent any damage of my working system.

I tried schnapps import -f turris1x-medkit-*.tar.gz and first get some error message that says no factory snapshot then I run same command again and then it say factory was imported and I was even able to mount it with schnapps mount factory. Even schnapps list does not show factory snapshot. Are there any other more “hidden” snapshots created by default ?

How to do migration the best way ? My plan is to export opkg list-installed to file and delete versions in excell file and add opkg install command for each line, then run it as script on booted TOS 4 to make sure all packages will be installed that I had on TOS 3. Then copy everything from original TOS 3 folder /etc/config/* to new system with also few other configs from /etc that are not covered by openwrt /etc/config. Will it be sufficient ? Or what other approach is recommended ?

To get back to TOS 3 is just schanpps rollback to TOS 3 snapshot enough ? I suspect that full migration will take me some time so I will need to switch between TOS 3 and TOS 4 for some time untill I am happy with all the working configuration on TOS 4.

Which packages are not on TOS 4 ? Noticed that you abandoned CUPS ? How about shellinabox ? I use it a lot to access my Turris and I was not able to compile it on openwrt master for x86 due to some problems with new version of OpenSSL.

Will it be also possible to compile TOS 4 and cherry picked packages on newer distro like debian buster that I use ? Or is still something archaic necessary ?

13

Hello,

Unfortunately, the DDNS package isn’t correctly packaged in OpenWrt and there are some issues with postinstall script and it seems that updater might run for some time, but it waits till the process timeouts before it kills postinstall script. More details can be found in this issue:

Did you receive the notification just once? I ask if you had a temporary Internet outage. Updater checks every 4 hours if there is a new update available.

Can you check if the Updater isn’t running in the background?

14

If you have running LXC container on your router, I suggest doing backup. It should work to bring the existing once from Turris OS 3.x to Turris OS 4.x, but I didn’t try it as I am not using LXC on Turris 1.1 router anymore. I had it for Tvheadend, but I compiled it for OpenWrt.

Otherwise, to setup a new one can be problematic as powerpcspe were removed from Debian ports.

Thread in Czech section:

Anyway for more details why it was removed you can read e-mail from Debian maintainer of powerpcpse Re: Removing powerpcspe from Debian Ports

Here is kernel configuration on Turris 1.1, which is running Turris OS 4.0.3.

root@turris:~# zcat /proc/config.gz | grep CGROUP
CONFIG_CGROUPS=y
CONFIG_BLK_CGROUP=y
# CONFIG_DEBUG_BLK_CGROUP is not set
CONFIG_CGROUP_WRITEBACK=y
CONFIG_CGROUP_SCHED=y
CONFIG_CGROUP_PIDS=y
# CONFIG_CGROUP_RDMA is not set
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CGROUP_CPUACCT=y
# CONFIG_CGROUP_BPF is not set
CONFIG_CGROUP_DEBUG=y
CONFIG_SOCK_CGROUP_DATA=y
# CONFIG_NETFILTER_XT_MATCH_CGROUP is not set
CONFIG_NET_CLS_CGROUP=y
# CONFIG_CGROUP_NET_PRIO is not set
CONFIG_CGROUP_NET_CLASSID=y

More options will be enabled in Turris OS 5.x according to this pull request, which I have on review. Once it is merged, it should be quite easier to have/run Docker on Turris Omnia, Turris MOX.
Not sure, if they will be backported in Turris OS 4.x. Most likely I doubt.

Package shellinabox wasn’t and still isn’t part of Turris OS / OpenWrt. If you would like to have it in OpenWrt, you will need to send a pull request to packages repository. In the morning, I take a look, why you couldn’t compile it. You are right that it is related to a new version of OpenSSL, but there is a year pending pull request, which was not accepted nor reviewed by developers of shellinabox and the guy who sent the PR is taking care of OpenSSL in OpenWrt. So, you just need to download it as a patch and put it to patch folder inside shellinabox.

About CUPS, it is complicated. More answers later…

15

Edited:
Did a clean installation of 4.0.3 on my MOX (modules P,A,B with installed WLE900VX and external antennas) and WiFi on module B is not working after some days of uptime (see –>post below).
I didn’t manage to get SDIO-WiFi working yet (see other threads on this topic).

former post

Did a clean installation of 4.0.3 on my MOX (modules P,A,B with installed WLE900VX and external antennas) and it works as expected.
Still not working: SDIO (see other threads on that topic, as it is firmware issue, not OS itself).

16

By flashing firmware to OS 4.0.3 I was not able to restore the user settings saved under OS 3.x. Doing this caused LAN ports without any local connectivity, so I needed re-reflash and doing the complete configuration from the beginning. Using the guided configuration is easy and quick. Nevertheless for advanced configuration it seems a lot has changed, especially in the Luci Interface. Most of the changes are fine for me. But the vlan/switch configuration got some changes, so I was not able to recreate my old settings. For example the WAN port is now assigned to “eth2” (was before eth1, while eth0+eth2 were on LAN side). Also the menu entry for the switch configuration disappeared in Luci, it was helpful for creating additional VLANs. Now adding VLANs is only possible via SSH editing the /etc/config/network file. With that the menu for the switch settings also comes back, but always with warning of improper switch config. Also the WAN port doesn’t appear there. All this is much more complicated and so it has failed for me yet, maybe because new VLAN settings seem to conflict with the given pre-configuration (perhaps interface option “_turris_mode ‘managed’”, likely others too).

Would it be possible either to give back the easy opportunity of Switch/VLAN configuration via Luci and/or would you provide a example for the /etc/config/network file? The description from the turris team at howto/vlan_settings_omnia does not work with the Turris OS 4.0.3 and should be updated.

17

There are some threads in this forum with regard to VLAN configuration in TOS4+.x (cue DSA).

The TOS documentation is not yet reflecting the changes [1] and LuCI support is only partial [2] (lacking support for bridge related VLAN commands)

[1] https://gitlab.labs.nic.cz/turris/user-docs/issues/22
[2] https://github.com/openwrt/luci/issues/2798

2 Likes
18

Thanks for the quick answer. As the issue of missing vlan config in Luci is sustaining, I would appreciate the turris geeks could provide an example for the manual configuration of vlans in etc/config/network, for instance tagging of port “LAN4” with 2 or more tagged vlans.

Nevertheless, I just tried some things and found an easy possibility for a simple vlan tagging: In Luci Interface under “Network/Interfaces” just “add new interface” of type “unmanaged”, and assign this to a new interface (“cover the following interface → create new …”); in my case as “lan4.3”, that establishs a new tagged vlan “3” on the lan4 port, in addition to the existing untagged. Then I was able to assign or bridge this new dummy-interface, in my case to a new created wireless network. grafik
My purpose was providing an external network (which is not originated in turris router) by the wireless devices of the Turris router. This works fine now.

My workaround did only work for one single tagged vlan, not for more taggings on the same port. So I’m still hoping for advice for network settings via ssh…

20

Can someone please explain, why @anon50890781’s post got hidden?
There is actually no detailed documentation site about DSA handling in turris wiki or am I mistaken?
Therefore the link @anon50890781 posted adds definitely value to this topic and he is right in what he is stating…

21

Yeah, I agree with that. Those posts shouldn’t be hidden, but the author (@anon50890781) flag his post and the other one as off-topic and that’s why they were temporary hidden.

Proof:

image
image815×414 39.6 KB

On the other hand, those two posts might be off-topics and can be moved to separate thread.