Turris OS 4.0 beta1 is released!

Dear Turris users,

We are pleased to announce you that we have released Turris OS 4.0 - beta1. It is released for our routers - Turris MOX and Turris Omnia. We appreciate any feedback for this release.

Here are the release notes of our changes:

  • New version of updater-ng with completely rewritten network backend which
    dramatically decreases memory consumption during update.
  • Fixed problem in updater-supervisor which caused updater to behave as
    deactivated even if user set it otherwise.
  • Nextcloud updated to latest version (15.0.7)
  • Fixed crash on time tab in Foris on devices without Wi-Fi
  • switch-branch now reinstalls all packages on branch switch to mitigate problems
    when switching to and from HBD (OpenWRT master <-> OpenWRT 18.06).
  • Default setting of IPv6 in Foris is now DHCPv6
  • Fixed IPv6 prefix delegation in default installation
  • Foris now correctly displays steps in initial setup guide
  • Fix rainbow in Luci on Omnia
  • Do not use ath10k-ct on Omnia
  • Improved LXC support and fixes (some issues still remain)
  • System logs and lograte changed to limit logs size
  • Added basic support for Turris OS 3.x migration
  • Python3 updated to 3.6.8
  • Repository path on repo.turris.cz changed (in compatible way)
  • Production addresses for CZ.NICs ODVR including DNS over TLS support
  • EDIT: Foris e-mail notifications via Turris servers

There are also many changes in OpenWrt 18.06, which was done by @neheb! Thank you so much for them.

When you were using one of our Alpha releases, you should be updated to this version automatically within a few hours.

If someone wants to give it try on Turris Omnia router, which is running Turris OS 3.11.4 or any other operating system, then we have prepared some short notes about how to do it.

From scratch you just need to plug USB flash drive and put there rootfs, which you can download it here and by using the re-flash method, which is described in our documentation. If you want to have a backup, we suggest you create a snapshot using our tool - schnapps.

We hope that you will enjoy it!
Turris Team


Known bugs:

All platforms :

  • Honeypot as a Service requires manual intervention as it was connected with Data Collection. You need to have a registration on https://haas.nic.cz and generate the token, which you need to add to /etc/config/haas.

Turris Omnia specific

  • Second CPU ethernet port to switch chip is disabled, only one of two ethernet ports between CPU and switch is in use.

  • Old version of libmariadb when using Nextcloud from Turris OS 3.11.x. It will be fixed in the upcoming release.

Turris 1.x specific

  • Currently not working because of kernel issues. Please do not test this release on Turris 1.x

Did You try to run LXC with Debian Buster (and with network)?
If so, can You post example config?

We detected some problems with systemd based distributions. See: https://gitlab.labs.nic.cz/turris/turris-os-packages/issues/354
We had to add support to procd: https://gitlab.labs.nic.cz/turris/turris-build/commit/51ce917d98080609310d6e829e8098eb8e7678b2
Default network configuration was also migrated to new format: https://gitlab.labs.nic.cz/turris/turris-build/commit/51ce917d98080609310d6e829e8098eb8e7678b2
We haven’t tested Debian Buster per say (up to my knowledge) but we tested lxc as a whole (with opensuse I suspect).

Is there any chance, that container from 3.11.x will run in 4.0 or I should not waste time and start from beginning?

You can try that. My approach would be to create new container to test it if it runs. Then I would try to compare configurations.

Whilst just started testing this seems quite a bit of a quantum leap compared to the alpha 5 release :+1:

Missing from the release notes (known issue) is that switching to SFP still requires manual intervention, but after that SFP appears to be working well - even with the Allnet DSL modem in the port. :slight_smile:

Second CPU ethernet port to switch chip is disabled, only one of two ethernet ports between CPU and switch is in use.

Is somewhere explained what this means in a standard setup?

Well this is not an issue but rather degradation. We are not currently able to switch between sfp and phy at runtime without hacking kernel a lot. We have possible solution in mind with upstream kernel and with uboot but we are far from that. The current state where you have to change link is going to be there for some time. This is going to be part of final release notes together with other changes.

In standard setup probably nothing. If you are pushing Omnia to limits and you need the second line to have 2G throughput then it is problem but otherwise it is not. You are just limited to 1G between CPU and switch.

Upgraded, then downloaded new Debian Buster template (contains network config, thanks), but does not work.

root@Turris:/srv/lxc# lxc-start -F -n Buster --logfile /srv/lxc/Buster/Buster.log
Failed to lookup module alias 'autofs4': Function not implemented
Failed to lookup module alias 'unix': Function not implemented
Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted
[!!!!!!] Failed to mount API filesystems.
Exiting PID 1...
lxc-start: Buster: tools/lxc_start.c: main: 371 The container failed to start.
lxc-start: Buster: tools/lxc_start.c: main: 375 Additional information can be obtained by setting the --logfile and --logpriority options.

Logfine contains nothing more than messages above (maybe I should pass more parameters).
Diagnostics was sent to tech.support@…, maybe it will help in something.

Maybe I should start from clean TOS 4.0 beta1?

So no 3.11.5?
Straight to 4.0?

Are you working on this as it was not fixed when switching from alpha to beta state?

I’d really appreciate that!

We are preparing Turris OS 3.11.5 release. If you’re interested in release notes, I suggest looking to our Gitlab or to our mirror on GitHub, where you may find a changelog, but it doesn’t mean that changelog is final till we released a new final version from RC.

Turris OS 3.x and 4.x will co-exist for some time until we have fixed known bugs for Turris OS 4.x with tested automatic migration. This is gonna take while as we need to do still some things. We would like to catch as many bugs as possible to be able to establish the final release. Before we’re going to start to migrate all users.

1 Like

As mentioned in the changelog, some issues still remain and that is actually not working systemd based containers. We are working on that. 3.11.X containers should work eventually after we fix the current issue and after you migrate your container configuration.

Ok, so Debian in LXC is not working and checking this even in clean TOS won’t change results.
Let me know if You find solution, I’ll test it.
Currently I have two wersions installed (3.x on MMC and 4.x on mSata), so checking something requires only switching boot source in U-boot and some time available.

By the way: is there a way to do “env default -a” from booted system using fw_* utils?

And what about “Data Collection” funcionality?
It was added option “Data collect” to the Updater list menu in Foris, but there is not matching offer in Foris menu (after installing packages) for setting and configuring.

Is it possible to find user documentation for Sentinel?

No, we are not working on that actively. This is DSA implementation limitation. We are waiting for upstream Linux developers to decide what is appropriate approach for systems with multiple CPU-switch links. There are few patches on table but nothing final so nothing we are going to be applying in short terms.

Well. you can dump default configuration and then restore it. Setting defaults from utility tools is not possible. It is not aware of a default configuration.

ucollect is not available in TOS 4.0+ and sentinel is not yet production ready. We are running it on our routers but currently we don’t have registration done yet. The data-collect package list currently only contains dynamic firewall (which is not dependent on registration). Sentinel integration will be added with some future 4.x release (won’t be part of 4.0 most probably).


I have a request I would like to voice here, since it is related to upgrading 4.0a5 to 4.0b1, if this should be the false venue, please direct me to another place.

I would propose to add a button to the updater page in foris to start upgrade/update immediately :wink: (Yes, I am that impatient :wink: )

Best Regards & please keep up the good work!

Just click the button Save changes in Updater tab, no need to do any changes and it will run updater in the background.

1 Like

Excellent, could I propose to maybe add this to the buttons caption, like “Save & Update” or so?