Turris OS 4.0 (Here be dragons)

Turris OS 4.0 will be the big release based on OpenWRT 18.06. Currently it is in early Alpha state so we don’t recommend to use it and actually we are not interested in feedback either at this point. We know that it is quite often quite broken. But some of you are eager to try the latest and greatest stuff, so we want to let you take a look under the hood. But do that at your own risk.

What is known not to work for sure:

  • migration - we haven’t even started on that one
  • SFP on Omnia
  • only one CPU port is available in switch on Omnia
  • Turris 1.X still uses switch-config, no DSA at the moment
  • Turris 1.X is only supposed to work on Btrfs and MicroSD

Apart from that any update might completely break your setup as builds are automatic and don’t undergo any tests at all till developers actually wants to test something.

Backing up your current setup on Omnia

To backup your current setup and your working configuration you would need a flash drive, preferably with ext4. Insert it into USB port and mount it. For example:

mkdir /mnt/backup; mount /dev/sdg1 /mnt/backup

Now you can use schnapps to backup your current system:

$ schnapps create pre-4.0 backup
Snapshot number 166 created
$ schnapps export 166 /mnt/backup

This way you just created a medkit on your flash drive with your current setup. Any time you want to return to this working configuration just plug the flash drive into your router and perform 4 LEDs factory reset.

Backing up your current setup on Turris 1.X

Before installation, take out your Micro SD card and create a backup of it in
your Linux machine:

dd if=/dev/mmcblk0 of=$HOME/turris.backup

To restore, take out your MicroSD card again and restore it using your Linux machine:

dd if=$HOME/turris.backup of=/dev/mmcblk0

Installing 4.0

Turris OS 4.0 can be installed on Omnia via 4 LEDs factory reset. Simply download omnia-medkit-* from https://repo.turris.cz/hbs/medkit/ (based on OpenWRT 18.06, for OpenWRT master use https://repo.turris.cz/hbd/medkit/) and put it on ext4 formatted flash drive. Now insert the flash drive to your Turris Omnia and press and hold reset button on the back till 4 LEDs including power one are lit. Then release the button and after a short while, your router should be reflashed with Turris OS 4.0 and reboot itself. From there on, you can start testing and configuring it.

On Turris 1.X, migrate to Btrfs, then take out the MicroSD card and replace the rootfs partition with content of rootfs tarball that can be found on https://repo.turris.cz/turris-hbd/ (based on OpenWRT master). Also make sure to copy the kernel to the vfat partition on yous MicroSD card.

Highly experimental

All the builds are highly experimental and we provide no support at all. Try at your own risk.


Which are worse: dragons or lions ? -:wink:

1 Like

Dragons, definitely, they are bigger and can throw up fire. Lions are mere cuddly kittens in comparison :wink:

1 Like

And in symbolic way?

Stable version as X-mas gift or later? :slight_smile: Should I include it in my Santa letter? =)

1 Like

If Santa will come and join our team, then maybe beta. We will announce once we will think it is beta testable and once we will have at least some migration ready, but after that, as it is a big step, it will require quite some time spend in testing…


@miska … in relation to this upgrade … it’s great to hear you guys working on this … is there any flexibility on your side to make any new feature requests for this release?

Since connecting an external SSD to my Omnia via USB 3.0, I have the ability to have the “Storage” section working and configured on the device.

However there is a lot of work required to ensure that all of the other Omnia service actually make use of that SSD, It requires manual reconfiguration for each service.

Is there any opportunity to explore an option on the Omnia, that if the external storage is detected, then it will “automagically” actually use it … for storage of logs, for proxy cache, for samba drive, etc…

I’m proudly alfa-tester on my blue Turris 1.0

Good job, guys! :slight_smile:


Brave man!!!
(Could samebody remove the bloody 20 char condition?!? Its overdue :frowning: )

1 Like

Thanks! :slight_smile:

Most of it works fine … FORIS, LUCI, SCHNAPPS, WiFi

Spoiler of new feature, which is available in nightly and also in Turris OS 4.0.


Looking at the folder tree (in each trunk) I am curious about the package maintenance


It looks like that the same old scheme that packages are provided still only by TO and not from the OpenWRT repo?

1 Like

There is a difference between binary package and package source :wink: do not mix these two together.

Meaning, care to elaborate?

I assume this is only for alpha-stadium?

Same as currently, packages are build by us and available form our site, but also as in current 3.X release most of the packages come directly from the upstream - OpenWRT. What changes is that OpenWRT now makes it easier to follow what their stable release, so we wouldn’t have to cherry pick fixes and updates, but can follow them more closely.

1 Like

For one not all packages available in the OpenWRT repo are available in the TO repo, plus a lot of packages in the TO repo are way behind the upstream versions, notwithstanding the permanent reasoning that TO has not the resources for keeping up the pace with upstream realeases, being busy otherwise etc…

Is this the concept of TOS 4.0, that incl. package updates are only pushed with an increment of TOS as it is with 3.x?

Why would you do that? Why would you not directly take the upstream package resources?

All the packages that were available for 15.05 are available for 3.X as long as they build and we even updated and added quite some that are not available.

Since it is now much easier to track upstream now since the changes in upstream workflow, we hope that upstream will also provide some maintenance in their stable branches.

And yes, in stable channel updates will only appear with minor versions. But as it is now, you can switch to unstable rolling release if you think you know what you are doing and you can handle it.

Building packages takes only resources on our build farm (not the human resources that are much scarce) and not that much of them. But building everything locally ensures that it builds in same compatible way. OpenWRT build system misses quite some important checks so there is no way to ensure that packages will work against each other if build on systems with different configuration. There is a high chance that it would work most of the time, but if we build it, the chance is much higher.

Ok. So you will use the very same package source code as upstream openWRT for building the packages?