Turris OS 4.0 alpha2 is out!


#1

Dear Turris users,

We are pleased to announce a new version of Turris 4.0 - alpha2, which has been released today. We would like to hear feedback for Turris MOX, also we are interested in feedback on Turris Omnia, but there might be a few issues, which are mention in the second post. Currently, Turris 1.x is broken because of kernel issues and that’s why we don’t advice you to test it on it! We are working on it.

Most interesting changes in this release are:

  • Based on latest OpenWRT 18.06.2
  • A New Updater configuration (requires updater reconfiguration!)
  • Packages lists cleaned up and some unmaintained ones were dropped
  • A new version of Foris with new backend bus based on MQTT
  • Upstream versions for some primary packages were backported
  • Fixed compilation for most of the packages
  • And other small fixes in a lot of system utilities

Update for Turris MOX owners should be smooth. However, in some special situations, there could be some issues and in that case, we think that using medkit should be helpful.

If someone wants to give it try on Turris Omnia:
We suggest to plug USB flash drive to your router and create snapshot, so you can rollback or restore your configuration very easily. This can be done in CLI:

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

Assume snapshot number 166 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


Turris MOX přichází ...?
Turris MOX availability for retailers?
#2

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

  • No support for SFP port
  • No LED support (rainbow does not work)
  • 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

mSata LED konfigurace
#3

I am going to give a full try on weekend and give some feedback.

I am thinking of switching branch to hbs and then upgrading. Is it possible?
Because I want to save (and then just update) kernel modules for the usb modem.

What about lxc package? Was it dropped? I am scared to give a try now before saving a snapshot. Definitely I am curious how does it work even in alpha state.


#4

No it is not possible. I would suggest you to use medkit from hbs. Update path is not tested and there are known issues such as different switch configuration. If you don’t want to have to wipe everything then you can just update factory version with new enough schnapps (something like >1.5) using schnapps import -f omnia-medkit.tar.gz and do factory reset. This preserves your old system as snapshot and you can rollback to it.

It is still there and is in version as provided by upstream.


#5

Does this imply that not all 5 LAN ports are functional, or can you still use them albeit slowly?


#6

It means that speed between CPU and all devices connected to LAN ports is 1Gbps. It affects only communication to WAN port or services that are running on Turris. Speed between LAN devices is untouched.


Longterm support and buying advise
#7

That takes the joy/fun right out of it for any device being dependent on that functionality, incl. those with (x)dsl modems in that port.

The development pace with the understaffed development team focussed still on M, that is considering the time frame between the (pre)alpha releases and the commits in master/hbd, makes one wondering whether TOS4.x stable/production for T & O will really see the light before this year’s end.


#8

I really hope that development will gain some traction as forum is now full of complaints for obsolete package versions and refresh from LEDE is long time overdue.

Please update alsa library, shairport-sync and pulseaudio to version 12 during refresh and make sure that also pulseaudio-daemon-avahi is compiled, not just only pulseaudio-daemon. I started to recompile packages from upstream myself already as I was not happy with the current status of it.

I would like to test TOS 4 on Turris 1 as soon ass possible but need working LXC of whatever version.


#9

I wanted to contribute of updated packages from upstream, unfortunatelly it seems like NIC’s github is impenetrable fortress for me.


#10

The OpenWRT LXC version 2.1.1 (outdated and not maintained) is available in the TOS4.x feeds.


#11

alsa library, shairport-sync and pulseaudio to version 12

Thank you for the suggestion. These packages are maintained by upstream not by us. Generally, Turris OS 4.x is designed as a patchset for OpenWrt with our own feed mostly with our packages and with few patches.

I have been able to look, which versions are used in OpenWrt 18.06.02 (HBS, HBT, HBK are currently based on it) and if you want to try OpenWrt master (HBD).

OpenWrt 18.06.02 (Turris OS 4.0 alpha2) | OpenWrt master (Turris OS 4.0 branch HBD):
alsa-lib: 1.1.6-1.0 | 1.1.8-1
alsa-utils: 1.1.6-2.0 | 1.1.7-1
shairport-sync-openssl (as well mini variant): 3.1.6-1.0 | 3.2.2-3
pulseaudio-{daemon,profiles,tools}: 11.1-2.0 | 12.2-1

There is a planned OpenWrt 18.06.03, so if you want to have these packages updated, you can suggest them to OpenWrt maintainers to update there from their current master or somebody (even you) may try to send pull request to upstream and see if it will be accepted.

need working LXC of whatever version.

As @n8v8r said, there is LXC version 2.1.1. See our reply here and also Github issue in OpenWrt packages: https://github.com/openwrt/packages/issues/7694

I wanted to contribute of updated packages from upstream

I have already replied to your pull request in OpenWrt. Similar as you do this, you can send us a pull request to our repository on Github, which is our mirror from Gitlab. - currently: test branch is for Turris OS 3.x and master for Turris OS 4.x. If you want to contribute on Gitlab, I suggest you read our documentation for contributing.


#12

Uhm, that is not working so well at the moment


#13

It’s working on Turris MOX and I spoke to my colleagues if they are using it Turris OS 4.0 HBD on Turris Omnia, and one of our colleague is using it on daily basis. But I would kindly ask you and also others that this thread is for Turris 4.0 alpha2 and feedback about it and avoid off-topic if it is possible. If you want to discuss other things, create a separate thread for it. Thank you.


Tos4.hbd experience on TO
#14

Sure, and I did evidently. I only mentioned it here since you suggested HBD to a T user and not a M user…


#15

Thank you for quick reply I suggested those audio related packages as I use my turris as network speakers and airshare receiver which is imho very cool things, I peronally compiled those packages from upstream too, but I think other people without knowledge how to compile openwrt packages would like to use it too and for now there is alsa 1.0 and pulseaudio 8 (current is 12) .

I was able to make make for in openwrt github even it was complained about signature and few other things that I had not time yet to figure out but for NIC github, I failed miserably with trying to replicate same steps as for openwrt github. I read the documentation for contributing but it is just very brief without step by step instructions and git commands.


#16

Been running hbs on my omnia for a few days now and it seems to be rock solid. Sure, I can see a few kernel warnings in dmesg, and it was missing a few packages that are installed by default on 3.x (storage modules, plugins etc) - but none of these impact my overall usage. Good job, everyone!


#17

I believe there’s supposed to be module support for bluetooth audio sink functionality under TurrisOS 4.0 in conjunction with a USB bluetooth device. Is that likely to be operational in the alpha build?


#18

I installed the medkit.tar.gz using a manual btrfs subvolume send | receive operation to the emmc and it is working well.

Only problem was the 5GHz radio didn’t work on previous channel and worked only when I selected ‘auto’.

I think the btrfs filesystem is the biggest plus of the Omnia over other router solutions imo.

What enthusiasts need is a very plain Openwrt variety with just btrfs and any drivers for the hardware ie led etc and stay close to upstream.

Don’t make life difficult for anyone. Foris etc are all okay but imo are not the prime motivation. Keep it simple and stay close to mainline upstream. That will keep many people happy.

Just a quick question - what is the ‘hbs’ stream and how does it compare to the other hb* streams?


#19

Don’t forget schnapps, which is in my eyes THE key functionality.


#20