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.
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
Whilst just started testing this seems quite a bit of a quantum leap compared to the alpha 5 release
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.
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.
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.
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 (Yes, I am that impatient )
(Yes, I am that impatient