Turris OS 4.0.3 is released!

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:

reForis tabs still not working.

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.

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

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

It is working in “sandbox” environment since mid of this year. We are still ironing out some issues. You can see updates here: https://gitlab.labs.nic.cz/turris/turris-os-packages/issues/344

The main blocker before we release it for public testing are some hacks in updater (https://gitlab.labs.nic.cz/turris/turris-build/merge_requests/59).

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

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?

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.

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

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 ?


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?

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 https://lists.debian.org/debian-powerpc/2019/05/msg00128.html

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_CGROUP_BPF is not set

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…

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).

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.

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


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…

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…

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.


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

There is no need to create an unmanaged interface for each tagged/untagged port. Just scroll to the bottom of the list you screenshotted (Bridged interfaces in Physical settings of corresponding interface) and add e.g. lan4.3 in the custom field at the bottom of the list. You can add as many tagged/untagged ports as you wish (as long as it is possible of course) :slight_smile:

1 Like

It was my opinion that those posts are off-topic (4.0.3 release) and should be split/moved to one of the existing DSA related threads and thence invoked the flag in order to notify a forum moderator to take a look (however the flag function does not allow to state a reason/suggestion when invoking a flag).
Because now this thread seemingly turns into another DSA related discussion whilst covered elsewhere already.

As of today:

Brief summary about the current state.

  1. UCI | LuCI does support parsing:
  • ip l a l ${interface name} n ${interface name}.{virtual extension} type vlan id [numeric value]

which always creates a virtual interface that is 802.1q tagged. It can be leveraged with the node’s upstream and downstream interfaces. Removal of such virtual interface also works.
Managing tag/untag state with related VID/PVID of existing downstream interfaces does not work with the ip command by design [3].

  1. UCI | LuCI does not support parsing:
  • ip l s dev ${bridge name} ty bridge vlan_filtering [ numeric value 0 | 1]
  • echo [ numeric value 0 | 1] > /sys/class/net/${bridge name}/bridge/vlan_filtering

either of which is leveraged to toggle VLAN filtering (for bridge isolation) on or off.

  • bridge v a dev ${interface name} vid [numeric value] [options]
  • bridge v d dev ${interface name} vid [numeric value] [options]

used for the management of 802.1q tag/untag state and related VID/PVID of downstream interfaces (lan and bridge) and does not create any virtual interface.

Currently it requires a script coded by the user to retain VLAN tag/untag states with VID/PVID between node boots, respectively a hotplug script for dynamic VLAN state management. And reading from [2] this is not going to change anytime soon.

Just as an example

config interface 'vlan1'
	option ifname 'lan4.1'

and add whatever else is required as remainder, e.g.

option type 
option bridge_empty 
option proto 

[3] https://www.linux.org/docs/man8/ip-link.html