Turris OS 4.0 alpha4 is out!

Dear Turris users,

We have released a new version of Turris OS alpha4. We would appreciate any feedback regarding this release for Turris MOX and Turris Omnia. There are still known issues, which you can find in my second post in this thread. We don’t advice users/owners of Turris 1.0 and Turris 1.1 to test it due to kernel issues.

Changelog

Our changes prepared by @cynerd:

  • Fixed compilation of Tvheadend and Asterisk that were missing in alpha3
  • Fixed problem with notifications containing _() if no language was installed
  • atsha204 fix for potential security issue

OpenWrt packages branch: openwrt-18.06 changes:

  • php7: update to version 7.2.16
  • mosquitto: update to version 1.5.8

When you’re using Turris OS 4.0 release, you should be updated to this version within a few hours automatically.

If there is someone who would like to give it try on Turris Omnia:
You may want to plug USB flash drive to your router and create snapshot before you start, so you can rollback anytime and/or restore your configuration very easily.

You need to proceed these two commands in CLI:

$ schnapps create pre-4.0 backup
$ schnapps export 168/mnt/backup

Assume snapshot number 168 was created and your USB flash is mounted on /mnt/backup

Then you can take another USB flash drive and put there rootfs, which you can download here and by using 4 LED (re-flash) method described in our documentation you can flash it to your router and start testing Turris OS 4.0.

We hope that you will enjoy it!
Turris Team

Known issues:

Turris MOX specific

  • Mail notifications trough Turris servers are not supported yet, you have to use your own server for now.

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.

Turris 1.x specific

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

That was fun, updated from TOS3.11 to TOS4.0a4 on an omnia and the Guide crashed while transitioning to the updater item. (I had to set DNS to CZ.NIC tls, since I wanted DNSSEC to work). NOw everytime I try to log into foris I hit the same error page, luci & shell access however work. No complaint, just a report (I also send the html report to tech.support@turris.cz, but I expect no urgent response, after all it is an alpha :wink: )

Ha, ssh’ing in and editing /etc/config/foris ‘option finished’ to one got me over the stuck wizard, black magic that :wink:

That is foris work, except if I navigate to the updater page I get the same or a similar error report. Happy to help, if I can; I note that the rest of the system just works, including routing.

1 Like

I am sorry, but I just responded to you. We’ll look at it in the morning. :wink:

//EDIT: It will be fixed in upcoming release.

1 Like

My insights for this version with Turris Omnia:

  1. The kernel module “kmod-usb3” is not installed by default when NAS + Print server is enabled. I have to manually install.
  2. “luci-app-rainbow” package not included by default and must be manually installed.
  3. The “Rainbow” function does not work to set the WiFi LED colors and the user LED settings are missing.
  4. The “Firewall” function is not in the Czech language by default. I need to manually install “luci-i18n-firewall-cs”.
  5. Switch to ath10k-ct firmware? Personally, I have tried and can only confirm that …- CTs are unstable, clients are still disconnecting and there are errors in the log. Sources: https://forum.openwrt.org/t/why-the-switch-to-unstable-ath10k-ct/27258 and https://eko.one.pl/forum/viewtopic.php?pid=217765 - it depends on what you use.
  1. The kernel module “kmod-usb3” is not installed by default when NAS + Print server is enabled. I have to manually install.

You don’t need to have it at all as it is enabled in the kernel. You may check it from usb.mk and as well in kernel config for 4.14.

  1. The “Firewall” function is not in the Czech language by default. I need to manually install “luci-i18n-firewall-cs”.

Will check that. If I would be able to reproduce it, I will fix it.

  1. Switch to ath10k-ct firmware?

It was a decision made by OpenWrt. According to OpenWrt mailing list and also from their IRC channel #openwrt-devel, it seems that newer version of ath10k-ct should be backported to 18.06 soon. However, if you experience some issues with ath10k driver, let me know and I will try to communicate it with upstream, but in that case, I’d need some outputs and if possible on which devices did you try it.

I’m checking answers for 2. and 3.

Hi, i have same problem “Remote Exception: Incorrect output.”. Upgrade TOS an omnia 4LED step. Guide wizard almost step was ok, but at a updater step he crash. Now, all Foris configuration page is working, but updater page still crash, So omnia dont update. Luci also work.

Is it possible to update from alpha 2, just like a normal update? I don’t want to configure all the settings again.

Btw, as far as i have tested LXC systemd does not boot with starting of a Ubuntu LXC. I will try to create a debian LXC and see if that does work. Maybe you guys could update the LXC package to he latest to see if things do change.

1 Like

Just updated from 3.11.3 to 4.0 Alpha 4. Turris OS 4.0 install was working without issue. I created a backup using Doris before and restored it afterwards in Turris OS 4 without a problem.

The network interface are named as lan# - not eth# anymore - hence it was required to add the lan interface to the corresponding network group.

Issue that I recognized:

  • Foris Updater is not working and shows error. Tech Team is already informed.
  • WAN menu in Foris is not working when it is not connected.

It is really nice to see that something is happening and people are testing TOS4.0.
Are there alist of packages with available version number in the new release? I read somone wrote there is systemd already. It would be nice if someone would copied it over, e.g. what NFS version will be available there?
Will we have WPA3 and Wi-Fi 6 in TOS4?

Your best bet would probably be to check the turris packages repo, eg, https://repo.turris.cz/hbs/packages/omnia/ - just check the Packages file in each sub-dir to see what version each package is at.

As for Wi-Fi 6, I’m not sure there’s any wifi module (the very few that exists so far) that has open source drivers - I could be wrong about this, but I haven’t found any. So we’re probably some ways off before we have proper Wi-Fi 6 support.

1 Like

Hi,
thanks but that link is for the current TO packages if I am not mistaken. I would like to know the package versions available for the next TO 4.0

Af for Wi-fi 6, we have already 2 wifi module, do we really need hardware wifi module upgrade for that or is it enough to have software upgrade.
About the WPA3 part at least I am lamost sure that software upgrade would be enough to have better security.

The hbs branch is for TOS 4.0 alpha 4 (currently), so that link is for the packages currently in there. If you’re looking for what packages will be available when TOS 4.0 is finalised, I don’t think such a list exists.
The packages for the current stable build, 3.X, can be found here: https://repo.turris.cz/omnia-stable/packages/

Wi-Fi 6 is very different from Wi-Fi 5 and will require both new hardware and software. It’s not expected to be fully deployed until late 2019, so I wouldn’t expect them to be supported any time soon.

WPA3 on the other hand is, as far as I know, just a software upgrade, so that should be possible to implement. But I think vendors need to receive some kind of certification to be able to use it, and I don’t expect that will be any different for the Turris devices.

Sorry, you are right, I did not know what hbs was, and I checked NFS version there, and that seemed to be the similar version I have currently. 2.1 vs 2.3. But there must be some special openwrt versioning here, since 2.1 should be NFS3, so 2.3 could be NFS4.x, which would be good.

About WPA3 certificate, I think you only need it if you want to use that sticker on your product. You can still support it without any sticker :slight_smile:

There were not many changes between alpha3 and alpha 4, but it’s recommended to update always from the previous version to the latest. In any case, if you don’t want to lose any configuration, I’d suggest you create configuration backup in Foris and/or create a snapshot. Snapshots are created before and after the update, but they are regularly deleted. More details in our documentation for Schnapps.

About LXC, we’ll see. It was already discussed here: Why the "Print server" package is now marked as OBSOLETE? and cross-link reference to issue in OpenWrt packages: https://github.com/openwrt/packages/issues/7694.

Are there a list of packages with available version number in the new release?

There are many ways, how to check it.

  • You can check it in repo.turris.cz as @HomerSp said. But you will need to be carefully, which branch do you want to check.

Currently, HBD is OpenWrt master, HB{S,T,K} are OpenWrt 18.06.02. Also in each branch in folder packages/target (= omnia,mox,turris), there is file git-hash, where you can check hashes of each repository, we’re using for that release and track each change.

./findpkg.py -fp netdata -pc

It will give you this amazing output:

image

I read somone wrote there is systemd already.

That’s would be good use it as April joke! However, in OpenWrt, there’s no systemd as they’re using procd, libubxo, ubus and hotplug2. You may check it here: [OpenWrt Wiki] OpenWrt – operating system architecture

Will we have WPA3 in Turris OS 4?

WPA3 including WPA3 SAE has been already implemented in OpenWrt master together with LuCI, however, iwinfo doesn’t currently handle WPA3 correctly. It’s very unlikely that will be backported to OpenWrt 18.06.xx as there were plans to release final OpenWrt 19.03 in April according to OpenWrt mailing list, but it seems that it will be delayed. As said previously, you may try HBD branch, but it may and will break regularly as it just for testing. See our workflow.

2 Likes

EDIT: READ THE MESSAGE AFTER THIS ONE!!

Hmm…that is strange, as i following your advice of at least have a backup of my configuration, i saw a update pending at the updater. I was on TOS 4.0 alpha 2.

I found it very strange, but just went along and decided to approve the update and let it install. I then saw this with my notifications

## News from 2019/03/31 20:25:35

 • Fixed compilation of Tvheadend that was missing in alpha3
 • Fixed problem with notifications containing if no language was installed
 • atsha204 fix for potential security issue

The first line was talking about tvheaded that was missing in alpha3, so i was thinking does that mean i am updating to alpha4 with the updater?

Logged in to SSH and this is what i got…

BusyBox v1.28.4 () built-in shell (ash)

      ______                _         ____  _____
     /_  __/_  ____________(_)____   / __ \/ ___/
      / / / / / / ___/ ___/ / ___/  / / / /\__ 
     / / / /_/ / /  / /  / (__  )  / /_/ /___/ / 
    /_/  \__,_/_/  /_/  /_/____/   \____//____/  
                                             
 -----------------------------------------------------
 TurrisOS 4.0-alpha4, 32b2c8fddd
 -----------------------------------------------------

I thought or ASSUMED there was no auto-updater for TOS4.0 yet or was i wrong to assume/think this?

Boys and girls,

Listen to grandpa Big_Boss, DO NOT USE THE AUTO-UPDATER.

I have to use the medkit bring IT back from among the dead.

Edit: Another thing lads, remember, saving your configuration does not mean you have saved your configuration. It just saves the most basic and most used configurationsettings (wifi, network, etc. etc.), but you have to manually install the packages you installed, you have to manually configure your mount settings again. What i mean by this is, the directory that i created to use it as mount point, it needs to be recreated again etc. etc.

Funny thing is i am not even that mad about everything dying and reinstalled/configured some of the things. Now you see the strength of a LXC. Most of what i am doing is all installed and configured on the LXC.

What are the consequences of the known issue on Omnia - only one working ethernet port from CPU? Does it mean the list of ethernet interfaces as seen by ifconfig will change? Or does it affect just the switch chip config? Does it also mean communications slowdown in some situations?

In addition to that it seems WiFi 6 will need M.2- connector (at least currently announced cards only provide M.2). That would be really sad, as TO only provides miniPCIe…
But maybe there will be a WiFi 6 module for MOX available in the future - which would give me a reason to buy MOX :thinking: