Once it’s accepted there will be snapshots. So merging is the easiest way to get something widely tested given that it basically builds and runs, which it does.
Simply it use all hardware and is manufacturer default configuration, by general I understand manufacturer is who best know his hardware. But now I don’t know if is the best configuration, in my case:
-
eth1.1 - eth0.2 - Switch ports 0 - 4 (connected to PC, switch… The Switch port 4, of this router, connected to old router, wired part of it used as switch for connect to TV…) are bridged with WLAN (connected to mobile, tablet…) and with a LXC container (miniDLNA, Samba…)
-
eth0.3 - Switch port 4 (connected to old router, wireless part of it used as guest wifi) is bridged with a LXC container (Transmission, NSD…)
Basically next configuration:
config interface 'lan'
option ifname 'eth1.1 eth0.2'
option type 'bridge'
option proto 'static'
[...]
config interface 'dmz'
option ifname 'eth0.3'
option type 'bridge'
option proto 'static'
[...]
config switch_vlan
option device 'switch0'
option vlan '1'
option ports '0 1 2 3 5t'
config switch_vlan
option device 'switch0'
option vlan '2'
option ports '4t 6t'
config switch_vlan
option device 'switch0'
option vlan '3'
option ports '4t 6t'
I prefer have 2 VLAN’s and no 3 VLAN’s but I don’t know how to do it, at least using switch ports 0 - 4 and eth0 - eth1.
I know and that was the original idea, but it is working without troubles and I am thinking continue testing it and, if I can, add some packages.
Finally I had some time to dive into this.
I compiled rmounce’s “omnia-btrfs” branch and found it worling excellently. It is even possible to use the “schnapps” tool (just search for the schnapps.sh from the cz.nic repository) to create snapshots and do rollbacks with the reset button.
So it is very sad, that the LEDE devs do not want btrfs. I still think it has superb functionality with the onmia, you can really use the 8gb storage for this. Also no need for the failsafe I think, because you can rollback to factory or latest snapshot, fix the errors from there or rollback to another snapshot and just reboot. But I have to admit, I dont know if it is possible to destroy this somehow by doing some stupid stuff (it works even after rm -rf /*). But even then, just do a reflash with a medkit…
Any ideas how to get the LEDs working? I can do without RGB for now, but they are not even listed in the LED section of luci, yet they are contained in the dts file!?
1 Like
Now that I have narrowed down a separate issue with sysupgrade, I have compiled images that should be fairly representative of what how things will be if support gets integrated into LEDE.
A few other notes. The ‘omnia-btrfs’ branch exists only for my own reference, it is abandoned. If you want btrfs, I suggest staying with Turris OS. Personally I am only looking for a device with a fast CPU but otherwise behaving like a ‘classic’ LEDE router. While I do not object to the idea there is no motivation on my part to get btrfs into LEDE.
LEDs should be relatively easy, I think Xiche got them working but I have not tested.
See: https://github.com/rmounce/lede-source/commit/4bcbbc79b94bf8aa182a7cb5f8a5f6981dceb338
3 Likes
This is so exciting, thank you so much @ryan for working on this. Finally might be able to use this $200 brick for something now that it’s free of the turris garbage OS. Will give your builds a try.
edit: working great so far!
1 Like
Hi Ryan
quick question - have the LEDE group pulled or have you pushed these changes and if these patch’s are submitted to the stock kernel ?
would be nice to have turris support in the stock linux kernel !
Support is already in the mainline kernel. You can install Debian without any custom kernel, although there are still some tricks to the install process. https://wiki.debian.org/InstallingDebianOn/TurrisOmnia
The only kernel patches for LEDE support is a copy/paste of the device tree from upstream to the kernel LEDE are currently using (which won’t be necessary in the future), and a similar copy/paste type patch to enable the use of swconfig as used by LEDE/OpenWrt/Turris OS (rather than DSA which is supported upstream for the Omnia and used in other distros).
Basically, all of it is LEDE-specific and beyond this minimal kernel stuff comes down to the installation process, default configuration for network interfaces etc, and the sysupgrade process. I don’t think there’s much I have done that can benefit other projects, except they may be able to draw some inspiration from the way the installation process is being bootstrapped without requiring the use of a serial console, TFTP etc.
Although it seems, according to the Debian Wiki. that SFP modules are not supported.