Turris OS 4.0 beta9 is out!

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?

It’s clean… only for /srv i copied old LXCs, pakon, rrd content. But / is totally fresh, didn’t move a single config.

For LXC under Luci, before I updated containers configs, it failed to show any existing containers. Now after updating configs of containers that subview are showing up. Need to see if fixing this fixed the rpcd crashing issue.

Have no idea what is wrong with rpcd, but I’ll try to help with other problems.
Check Your luci config:

/etc/config/luci

config core ‘main’
option mediaurlbase ‘/luci-static/bootstrap’
option resourcebase ‘/luci-static/resources’
option lang ‘pl’

config extern ‘flash_keep’
option uci ‘/etc/config/’
option dropbear ‘/etc/dropbear/’
option openvpn ‘/etc/openvpn/’
option passwd ‘/etc/passwd’
option opkg ‘/etc/opkg.conf’
option firewall ‘/etc/firewall.user’
option uploads ‘/lib/uci/upload/’

config internal ‘languages’
option en ‘English’
option pl ‘Polski (Polish)’

config internal ‘sauth’
option sessionpath ‘/tmp/luci-sessions’
option sessiontime ‘3600’

config internal ‘ccache’
option enable ‘1’

config internal ‘themes’
option Bootstrap ‘/luci-static/bootstrap’

config internal ‘apply’
option rollback ‘30’
option holdoff ‘4’
option timeout ‘5’
option display ‘1.5’

config internal ‘diag’
option dns ‘www.turris.cz’
option ping ‘www.turris.cz’
option route ‘www.turris.cz’

Also LXC config should be converted to new LXC version
Adjust bold sections to Your needs.

/srv/lxc/Debian/config

lxc.arch = armv7l
lxc.tty.max = 4
lxc.pty.max = 1024
lxc.include = /usr/share/lxc/config/common.conf
lxc.hook.start-host = /usr/share/lxc/hooks/systemd-workaround
lxc.rootfs.path = btrfs:/srv/lxc/Debian/rootfs
lxc.uts.name = Debian
lxc.net.0.type = veth
lxc.net.0.link = br-lan
lxc.net.0.flags = up
lxc.net.0.name = eth0
lxc.net.0.ipv4.address = 192.168.9.3/24
lxc.net.0.ipv4.gateway = 192.168.9.1
lxc.net.0.hwaddr = xx:xx:xx:xx:xx:xx

Also, take a look at this post: