Turris OS 4.0 beta9 is out!

Dear Turris users,

We would like to inform you that we released a new beta version of Turris OS 4.0. In this release, there are a few changes. Most noticeable one is that we fixed a issue with Foris, which some of you experienced and reported to us in previous beta version. There are also a security fixes for golang and squid, which we sent to OpenWrt as well.

Full release notes for this release are:

  • golang: fix for CVE-2018-1687{3,4,5}, CVE-2019-6486
  • squid: update to version 3.5.28
  • foris: fix AttributeError password_set

When you are using previous Turris OS 4.0 beta8 release and if you are not using approvals, you should be updated to this version automatically. If you do, there will be waiting for you a notification in Updater tab to approve the update.

If you would like to try this release instead of Turris OS 3.x release on Turris Omnia and start from scratch, you need to download medkit to USB flash drive, which will be formatted on EXT2/3/4. Don’t extract it and plug it to the Turris Omnia router and by using re-flash method (4 LED), it will erase all the data from the current operating system including and write there a new operating system Turris OS 4.0.

We appreciate any feedback for this release.

4 Likes

Updated without problems (system on SSD, LXC, USB Z-Wave dongle).
Firewall for OpenVPN clients still does not work.

Since I had beta8 and no access to Foris and had set to approval needed for update installation I updated to beta9 via ssh and “pkgupdate” and afterwards “reboot” , worked without problems. I have access to Foris again. VPN client with policy based routing also working.

1 Like

So beta9 doesn’t have any known issues anymore? Just thinking… if I should migrate to this now same time as I convert my Omnia to use SSD as it’s boot media. Beta8 thread just looked pretty bad.

Right, there are still two known issues. Same as in previous beta version.

The first one is specific only for Turris Omnia.

  • It’s about missing support multi CPU in kernel DSA subsystem. We are waiting for upstream Linux developers to decide what is an appropriate approach to support multiple switch links. There are few patches, but none of them are final and nothing we are going to apply in short terms. There are 2 ethernet controllers on CPU connected to switch but works only one. In the standard setup, it does probably mean nothing. WAN / SFP ports together with all LAN ports are working.

The second one is for Turris 1.0 and Turris 1.1.

  • We advise anyone, who has Turris 1.0 and Turris 1.1 do not test this release, yet. It is not working.

I’m running 4.0 beta on SSD since beta4 or beta5.
It runs stable.
Only problem I have is with firewall for OpenVPN clients - routing does not work, I had to create script filling iptables with required rules because of bug in fw3 (OpenWRT firewall program).

1 Like

Today I realized that it is related to the updates.

After each update and night restart the router is dead at the morning. Completely not reachable and LED is off.
Turn off and on the power plug and everything starts fine.

@Pepe If more details needed there exists ticket for different issue but nothign has changes since that time - #004879

Part of your mesasge is related to thread, which was created yesterday - Reboot doesn't work. I will try to respond to your ticket today, which we got in monday afternoon today.

After updating to beta9, foris works again. In general update went smooth, no issues so far. openVPN, Nextcloud, all working fine.

1 Like

that is great thanks!
Is there a way to see the open bugs you have? So for example I could have checked there instead of opening a support ticket.

Thanks

Thanks for reply. I assume VPN issues are with some specific configuration, as there have been also mentions of VPN working. Is it just that VPN clients can’t access “the interwebs” over VPN connection? Local area access works fine? Did I understand correctly?

Is there any documentation how to config uboot back to use emmc as boot media? If I could just keep 3.x series on emmc, as a backup, in case of fatal failure with beta series.

it should be simple via ssh fw_setenv bootcmd 'env default -f -a; saveenv; reset', after that reboot

“OpenVPN clients” means client instances on my router that connect to some other networks.
That networks are available from router, but not from lan machines. That works only after some tweaks to generated iptables ruleset.
Reverting to mmc You have one post above. I’m running 4.0 from SSD, but also have 3.x on MMC.

Still have issues with connecting with PPPoE to local ISP with VLAN6 on the WAN port to NTU.
Mox classic, this is what foris tells me about the WAN section.

&

Currently testing forthcoming adblock 3.8.0 with latest beta9 on turris omnia. As soon as I type /etc/init.d/kresd reload (or start/restart) I’ll receive the follwing error:

root@turris:/etc/init.d# /etc/init.d/kresd reload
syntax error. Last token seen: +
Garbled time

culprit is the last test in ‘run_instance’ in /etc/init.d/kresd …

run_instance() {
	[...]
	[ \! -x "$(which at)" ] || echo "/etc/init.d/kresd test_ipv6" | at +2

Thanks for letting us know. There is created an issue on our Gitlab.

This issue was fixed in one of our Turris OS 3.x release, where is a newer version of Knot Resolver and there was some refactoring, but it didn’t get to Turris OS 4.x release, yet.

But AFAIK it should be harmless. @paja Can we fix that in Turris OS 4.x as well?

I would really like it if the Turris Omnia OS would support GRE tunnel creation/failover properly. Aside from site-to-site tunnels, things like Zscaler (full disclosure: my employer) use GRE tunnels for forwarding traffic to the service.

I managed to get omnia upgraded to 4.0beta9 and SSD at the same time. But rpcd keeps on crashing, forcing me to run service rpcd start to get luci working again. Any ideas why this keeps happening? Or how to debug it?

Luci’s fail message is the normal:
/usr/lib/lua/luci/dispatcher.lua:230: /etc/config/luci seems to be corrupt, unable to find section 'main'

Also with this fresh install, NextCloud just throws “503 - Service Not Available” when trying to navigate to it. No idea where to start debugging.

Is it clean install, or You moved config files from 3.x?