Turris OS 4.0 beta4 is released!

Dear Turris users,

We are pleased to announce that we released Turris OS 4.0 - beta4! This release is for Turris Omnia and Turris MOX.


  • foris: fixed issue when English was the only language
  • php7: updated to 7.2.17
  • libxml2: updated to 2.9.9, fixed CVE-2018-14404
  • hostapd: fixed CVE-2019-949{4,5,6,7,8,9}, CVE-2019-11555
  • block-mount: fix restart of fstab service

When you are using our previous release Turris OS 4.0 beta3, you should be updated to this version within a few hours automatically.

If you would like to give it try from Turris OS 3.x and start from scratch, you will need to download medkit and move it to the USB flash drive, insert it to the Turris Omnia and by using re-flash method (4 LEDs), it will erase all the current data which are stored on the router and it will write there system image from the USB flash drive.

We will appreciate any feedback regarding this release.


Known bugs:

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.

Turris 1.x specific

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

Update went without a problem. Foris is accessible.

Update from beta2 fine.

Following Managed devices instalation:

Error from 2019/06/24 11:11:28
Updater selhal: Failed operations:

turris-netboot-tools/postinst: udhcpc: started, v1.28.4

udhcpc: sending discover

udhcpc: no lease, failing

Downloading 'https://repo.turris.cz/hbs/netboot/mox-netboot-latest.tar.gz'

Connecting to

Writing to '/srv/turris-netboot/rootfs/rootfs-new.tar.gz'

/srv/turris-netboot/ 100% |*******************************| 41713k 0:00:00 ETA

/srv/turris-netboot/ 100% |*******************************| 41713k 0:00:00 ETA

Download completed (42714725 bytes)

Downloading 'https://repo.turris.cz/hbs/netboot/mox-netboot-latest.tar.gz.sha256'

Connecting to

Writing to '/srv/turris-netboot/rootfs/rootfs-new.tar.gz.sha256'

/srv/turris-netboot/ 100% |*******************************| 98 0:00:00 ETA

Download completed (98 bytes)

Downloading 'https://repo.turris.cz/hbs/netboot/mox-netboot-latest.tar.gz.sig'

Connecting to

Writing to '/srv/turris-netboot/rootfs/rootfs-new.tar.gz.sig'

/srv/turris-netboot/ 100% |*******************************| 151 0:00:00 ETA

Download completed (151 bytes)

Cannot open file '/etc/opkg/keys//XXX' for reading

Generating public/private ed25519 key pair.

Created directory '/srv/turris-netboot/.ssh'.

Your identification has been saved in /srv/turris-netboot/.ssh/reg_key.

Your public key has been saved in /srv/turris-netboot/.ssh/reg_key.pub.

The key fingerprint is:

SHA256:XXX registration_key

The key's randomart image is:

+--[ED25519 256]--+

| .++ =o. |

| .o.*=+o.. |

| oo=+=oo |

| . o.+.o+ |

| S oooo o |

| Eo.o.+ o|

| ooo.= |

| . +=o.|

| ..+==oo|


rootfs-new.tar.gz: OK

Tampered tarball

keep up the great work turris team! :smiley:

found a small syntax bug when reloading kresd should i create an PR?

root@turris:~# /etc/init.d/kresd restart
loading file from ... /etc/resolver/dns_servers/99_google.conf
print_dns_config 99_google.conf Google 0 2001:4860:4860::8888    1 1
syntax error. Last token seen: +
Garbled time

There’s already created one:

ah didnt found it…

another question:
there are a few “mox netboot data config” -related packages
…can this be used for any netboot capable devices with custom netboot images?

Updated from beta3 without issues.
Mox A D sfp

Great work turris team!

It working really good.
In the meanwhile my provider enabled I a native ipv4 and ipv6 connection at the same time. Finally I could also resolved all ipv6 issues and it is working.

Thanks Turris Team for continuously improving the device.

What does this mean in real life? Lower throughput on not working ports?

If you don’t know what it’s about, I don’t expect you’d notice a difference. All external ports work, and 1 Gbit/s is still there.

Well, I actually wanted to find out. Care to share a short summary?

Also downstream VLANs can logically be assigned only to one CPU port. Switch configuration via LuCI is not available.

But, do VLAN’s still work if configured in /etc/config/network?

Not sure really with swconfig dev switch0 show priducing

Failed to connect to the switch. Use the “list” command to see which switches are available.

and swconfig list comes up empty

And what about kernel issue on Turris 1.x?
Will be solved?
If so, when?

Well, that is a bummer. Would the Turris team share their plans to fix this before the main release? I do need the VLAN functionality on the LAN ports…

It might be mistaken but it seems that the switch management/discovery has been moved to mdio-mi which in TOS3.x I think is not.

kernel log showing stuff like

mv88e6085 f1072004.mdio-mii:10: switch 0x1760 detected: Marvell 88E6176, revision 1
mv88e6085 f1072004.mdio-mii:10 lan0 (uninitialized): PHY [mv88e6xxx-1:00] driver [Marvell 88E1540]
mv88e6085 f1072004.mdio-mii:10 lan0: configuring for phy/gmii link mode
mv88e6085 f1072004.mdio-mii:10: p0: hw VLAN 1 already used by

OpenWRT switched switch config from swconfig to DSA which is used by Turris OS 4.0. Turris team member cynerd explained it here:

So VLANS should work but configuration changed completely…


that seems to be reflected by kernel log entries

DSA: switch 0 0 parsed
DSA: tree 0 parsed