Schnapps is just a frontend for btrfs. The magic is there and when you truly understand the filesystems mechanics then amazing things are possible like the multiple rootfs type setup on btrfs that the Omnia has. One would think all distributions should be like this.
It’s a very practical way to do things and is very true to the open source way by keeping options open for the user. Huge thumbs up to Turris team for this. I make btrfs read only snapshots of my systems and send them via ssh to a remote backup server as a subvolume ready to be deployed whenever needed. btrfs makes it simple and staying in the btrfs toolchain lets you keep all file attributes intact which to me is a major advantage in the sort of file integrity that can be important in applications.
I believe this sort of device is the key to good networks and network models coming into existence in a much bigger world of technology in the future. Machines like these that are fully open source and in the hands of a capable admin will be the backbone of good networks. They allow a higher level of privacy and service in a world always competing for greater and greater efficiency and diminishing returns.
Thank you. So this alpha2 is a true “hbs” then?
I’m so far happy with it’s stability. I have it behind a Mtk edge router. It is presently acting as a secondary router for my test wifi and server network. This Omnia zone is a wild west with zero firewall - total DMZ in itself and for outward access (inward relies on port forwards from the mtk). I’m familiar with zone based firewall abstraction from my ubnt experience but haven’t really implemeted anything on Openwrt yet so a learning curve ahead.
My main core router is pfsense with zfs and I would really like to see Openwrt get to pfsense level polish as the pfsense system is very reliable overall.
I’ll keep working on the Omnia to get it to better integrate with my network toys here in my homelab.
I don’t know where reports on stability should be but I have found two issues.
LXC containers LUCI appears to not create containers successfully. The wheel spins when you press create and no container is created.
The ath10k driver appears to be prone to crashing. I have in dmesg…
[44102.296745] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[44102.304085] ath10k_pci 0000:02:00.0: dropping dbg buffer due to crash since read
[44102.311520] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[44102.318916] —[ end trace a21c13a3e1de5642 ]—
[44102.323640] ath10k_pci 0000:02:00.0: removing peer, cleanup-all, deleting: peer ed0d9400 vdev: 0 addr: 04:f0:21:31:d9:81
[44102.452543] ieee80211 phy0: Hardware restart was requested
[44102.458085] ath10k_pci 0000:02:00.0: failed to set beacon mode for vdev 0: -108
[44102.465437] ath10k_pci 0000:02:00.0: failed to set dtim period for vdev 0: -108
[44103.513946] ath10k_pci 0000:02:00.0: 10.1 wmi init: vdevs: 16 peers: 127 tid: 256
[44103.531508] ath10k_pci 0000:02:00.0: wmi print ‘P 128 V 8 T 410’
[44103.537604] ath10k_pci 0000:02:00.0: wmi print ‘msdu-desc: 1424 sw-crypt: 0’
[44103.544778] ath10k_pci 0000:02:00.0: wmi print ‘alloc rem: 26384 iram: 26852’
[44103.629149] ath10k_pci 0000:02:00.0: device successfully recovered
[44104.513491] ath10k_pci 0000:02:00.0: dropping dbg buffer due to crash since read
[57343.755859] ath10k_pci 0000:02:00.0: dropping dbg buffer due to crash since read
[57410.757158] ath10k_pci 0000:02:00.0: dropping dbg buffer due to crash since read
[124581.039722] ath10k_pci 0000:02:00.0: dropping dbg buffer due to crash since read
[124584.039840] ath10k_pci 0000:02:00.0: dropping dbg buffer due to crash since read
[124585.039859] ath10k_pci 0000:02:00.0: dropping dbg buffer due to crash since read
[124757.045787] ath10k_pci 0000:02:00.0: dropping dbg buffer due to crash since read
keeps repeating last message.
Hi, so I would like to understand your current build-from source process.
Are you using
- a fork of the upstream 18.06.02 feeds and source code, with your own patches?
- a pure 18.06.02 feed and source, with your own set of feeds to add functionality?
- a custom source tree that includes the 18.06.2 feeds, but does not inherit from it?
We are developing on top of Turris 4.0, and the alpha2 state does not bother us at all, but being able to rapidly keep pace with you is of concern. Up until now, we have built our packages with pure 18.06, and installed them on top of your boot image (medkit). We would like to transition to building our own medkit image with all our packages (MUD controller, SPIN, some custom hostapd stuff) already installed.
I think you can be interested in our WORKFLOW, and how to generate_medkit for Turris OS 4.x. If you have any questions regarding medkit or Updater, you may ask @Cynerd. If I’m not mistaken, by default the documentation for medkit counts with only our servers.
We’re using the second opinion, which is a pure 18.06.02 feed and source, with your own set of feeds to add functionality, but also with patches. The patches are different for OpenWrt 18.06.02 and for current OpenWrt master. Some patches are just backporting a new version of some package from their master to 18.06.02, others are work in progress, brandings, to-upstream (some of them are waiting to be merged) and so on.
When the branch is compiled, there is git-hash, which you can find in https://repo.turris.cz/hbs/packages/mox/git-hash also you may check feeds.conf in turris-build v4.0 for feeds and their tags. OpenWrt doesn’t release very often and sometimes it happens that they’re packages with missing dependencies, so it gets backported, but it’s not released. So, if there’s anything new in openwrt-18.06, we would have it.
Nice! So in the future the TurrisOS will follow upstream faster (automatically) and some special feeds for Turris specific stuff will be a topping.
Personally I like some of the TurrisOS functionality. Especially the updater but more up-to-date packages from upstream is also a plus.
Like that it will allow us to benefit from the both repositories. Great solution I think. When the TOS4.0 will reach RC I am going to switch and test.
What about LED support? There is this commit that suppose to add it:
Also make sure to include brand new, beautiful theme for luci:
@AreYouLoco we are working on Omnia leds support and I hope that you can expect it in alpha3, same as sfp support.
Hello Turris Team,
SFP and LED support are already done for OpenWRT. Maybe u could take a look in this:
It would be great, if u could work on full bridge support and hw-crypto support for the next releases, which i think, are more important.
I think you seem to be interested in details about LED and SFP support for Turris Omnia in OpenWrt and upstream kernel. These two things are still work in progress and they can not be accepted in OpenWrt as it is!
I see that in this thread is mentioned Klaus Kudielka, again. Even I appreciate what he has done about SFP and LED, but unfortunately, it wasn’t merged to OpenWrt. One of the patches, which he sent to OpenWrt mailing list was directly pulled from our repository. In the same mailing list, you can see that what was suggested could be a temporary workaround and that he was asked to get the LED driver accepted in upstream first. This is also said in the thread, which you mention. We’d like to have LED support also in the upstream kernel, so there wouldn’t be additional patches among all GNU/Linux distributions and we’d like to do it as it should be.
Anyway, LED support is a little bit complicated. I can suggest you read: https://lists.gt.net/linux/kernel/2976188 together with commit messages from these patches in our repository turris-build 1, 2, 3. They’re still work in progress.
Unfortunately, I don’t know much details about SFP as I don’t use it. Hopefully, colleagues will tell you more. If you’d like to discuss more details upstreaming together with SFP, LED, I will move this discussion to separate thread.
Longterm support and buying advise
I’m still using 4.0 a2
The “Network -> Switch” menu is gone and I have tried many ways to get a VLAN working but settings never get applied before the 30s timeout and the rollback doesn’t work - I need to get in via ssh and restart the network to get it functioning again.
Is there a guide on how to enable VLAN with the new 4.0 a2?
Also can I perform an in place upgrade with a2 or do I need to wait until the next alpha or beta is released to do another medkit upgrade?
I would love it if there were a vagrant style easy cross compile setup so I could try building it myself and keep the advantages of Btrfs.Are there any guides on how to do this?
i’m not sure which file to get for the Omnia it self. Am i suppose to just take the mox medkit which you direct to, that is based on TOS 4.0 A2?
SFP on Omnia in 4.0 is supported by kernel but problem is in device tree. Currently we “solved” support of SFP by providing you with two device trees (for phy and for sfp). You have to manually switch between those. In future we are thinking about u-boot glue code that would choose correct device tree or some kind of daemon that would overlay device tree in runtime (but for that we need new kernel).
Anyway, current support of sfp in hbk and hbd branches is in form of two device trees and you have to change link in
/boot/dtb to sfp one if you want to use sfp.
(Note that on Omnia we have known issue in hbd and hbk that if was wan cable is plugged in then kernel panics)
In 4.0 DSA is used to configure switch (not switch-config as previously). If you try to configure switch with swich-config then it fails and weird stuff happens. Don’t do that.
DSA configures switch from netlink configuration. That means that to create vlan you have to just connect netlink interfaces to their own bridge. If you need tagged vlan then you have to use driver-level tagging (https://openwrt.org/docs/guide-user/network/vlan/switch_configuration#creating_driver-level_vlans). DSA should correctly configure switch with such configuration. I wasn’t able to test this all in OpenWRT yet so I am not sure if it is going to go smooth but there seems to be no Luci way of tagging.
When we release new release it is going to be automatically installed according to updater configuration. You can also use
switch-branch to move your router to different release cycle (hbs=stable, hbt=testing, hbk=openwrt stable, hbd=openwrt master)
Read README and
Do not use Mox or Turris 1.x medkit on Omnia!
TurrisOS 4 roadmap
I have just flashed my Omnia using the medkit.
When enabling NAS from Package list of Foris, following error is issued:
## Error from 2019/03/15 XX:XX:XX Updater selhal: inconsistent: Requested package kmod-ata-ahci-platform that is not available.
My Omnia has SSD drived installed.
Anybody with SSD installed is experiencing the same issue?
Thank you, I have been able to find where is the issue. Thank you for your reporting.
According to this commit from OpenWrt
The package kmod-ata-ahci-platform is not available anymore as it’s not needed, because it was enabled directly in kernel config. I checked it and indeed we have them enabled. This is just a leftover in our NAS list. I will remove it from there.
Yes, i have the same error.
Is it normal that there is no more menu of being able to mount your existing partitions. In floris it gives me the possibility to “format & set”, but offcourse i am not planning to do that as i have a complete LXC installed on it. sda1 partition is for majordomo, sda2 is completely for Linux Ubuntu 18.04 LXC and sda3 for swap. The rest i on purpose did not partition to extended the life of the SSD.
EDIT: Nevermind, blockmount has been superceded by ubox. After so many years spent on learning how Linux work, you just gotta love it…TEH TERMINAL!!
Device Description Filesystem UUID
sda ATA Samsung SSD 860 (931.5 GiB) sda1 Size 2.0 GiB btrfs 3555df35-6ee8-444f-803d-9c292a45ef50 sda2 Size 900.0 GiB btrfs afb77402-f3f7-42c9-9534-1e416c519843 sda3 Size 16.0 GiB
Hi Turris Team,
i switched from alpha 2 to alpha 3 on Turris Omnia. Had problems with keepalived, thats why i changed to newest TurrisOS 4.0-alpha3 578b379021 / LuCI branch (git-19.077.01380-621a264 - https://repo.turris.cz/hbt/medkit/omnia-medkit-201903180413.tar.gz). Keepalived had segmentation fault in alpha 2, i think the package is just too old, the error was “Keepalived_vrrp exited due to segmentation fault (SIGSEGV)”. Keepalived cannot be installed in alpha 3, it gives error while trying to install it.
Installing keepalived (1.4.4-1.0) to root…
Not downgrading package kernel on root from 4.14.105-1-2bd1ddeb6ddc805b82eff0a1a2123143.0 to 4.14.99-1-2bd1ddeb6ddc805b82eff0a1a2123143.0.
- opkg_install_cmd: Cannot install package keepalived.
Could you please change it to newest release 2.0.13? It would be nice, if you could also also update conntrackd (2017-09-27-eefe649c-1.1). Except those errors the alpha is very stable. I am using 2 TO routers and want to use them in wan-failover setup with 2 internet providers and as a wlan-mesh. Mesh with wpad runs smoothly. Keep up the good work!
Thank you for your message. I have checked and in OpenWrt 18.06.02, there’s version 1.4.4 like you mention. In one of the upcoming version of Turris OS 4.0, I will try to backport it from OpenWrt master, where we upgraded it to version 2.0.10 as it contains fix for security issue. If everything will work as expected, I prepare pull request to OpenWrt to branch 18.06 so it may get to 18.06.03 if it will be released.