- In Turris OS 6.1.0, we introduced VLAN support for WAN interface, but it seems that in some cases, the LAN page is not working. Bug report:
MOX A+D 6.1.0 → 6.2.0
No hiccups, reboot worked fine.
Thank you team!
5 posts were split to a new topic: Turris MOX does not start
After update Turris 1.x works without problem.
But kernel is always 5.10.161.
Yep… it will stay on Linux kernel 5.10.x for some time until the PHY issue with WAN is investigated and narrowed down. Sorry!
The configuration problem with Nextcloud remains. Syncthing now installs, but the service is not automatically activated and after activation I don’t know how to log in. What would be the credentials? I see that the syncthing user is created.
There wasn’t mention of anything related to Nextcloud in the release notes for this release. Was it? I am so sorry to tell you this, but we are not going to address all issues at once in releases. That’s not even possible. And we are not going to increase the priority for the issue, which you have already reported to us if you are going to spam every thread. What I can reveal now is that we will release another Turris OS release in such a short time, where we fixed the regression caused in Turris OS 6.1.0 related to the LAN page and nothing else.
If you want to look under the hood, please check the response from my colleague, which he replied to you here:
TL;DR: The issue is not confirmed. The issue it lacks some details which would help us to reproduce it.
Ok, I will take it from the end.
Not every process is running under the root and that’s the case with syncthing. The process has its own user under which is started.
credentials / how to log in to syncthing:
For the syncthing, there are two ways, how you can access the own web interface.
The easiest way is to access http://yourrouterip/syncthing/ and it will ask you for your root credentials. Similarly, as it is done for Transmission WebApps. We will later convert this to Turris Auth integration, but that’s will most likely be done in one of our feature releases to split those changes into small releases instead of one huge update.
If you want to avoid our WebApps integration, then it is just fine, but you need to change the gui_address in the config to get this working.
What you should do is to configure the syncthing interface once accessed.
the service is not automatically activated:
You want to configure the service first and then enable it. That’s the OpenWrt behavior for this package: packages/syncthing.conf at ce0679b61a5927ffdbc8a1505ce52756c6c394d4 · openwrt/packages · GitHub
Turris Omnia, Upgrade from 6.1.0 to 6.2.0 - works as expected.
Minor issue observed:
Default landing page of web user interface was showing no web apps once the Omnia was restarted.
Issue was resolved by reloading the page (Mac, Safari 16.1).
I thank you for your response. It was not meant to be a complaint. I am perfectly fine with the development and I always thank your team for their helpfulness over the years. I just wanted to let people know what is still wrong, not because I expected it to be fixed already. But indeed it was unnecessary repetition. I will pay more attention to it
Syncthing finally installed. But the user experience of a fresh install is really bad.
http://127.0.0.1:8384address from the config work (when accessing it from browser as http://<ROUTER_IP>:8384). I played a bit with it and finally,
option gui_address 'https://<ROUTER_LAN_IP>:8384'works. But still, the webapp link is broken. When I tried
option gui_address 'https://<ROUTER_IP>/syncthing', it did not work. What am I supposed to do to get the syncthing appear on
https://<ROUTER_IP>/syncthingand work from the webapps?
/Syncshows an error that it cannot be created. That’s right, because no such path exists on the router and
/has no write permissions for the syncthing user. Deleting this folder and setting up a proper one works okay, but wouldn’t it be better to right away create a data folder in
/srvand set that one as the default one?
Turris 1.x, update ok, but Syncthing failing to install with:
Updater execution failed:
inconsistent: Requested package syncthing that is not available."
I will provide the package as virtual for Turris 1.x, so the update can proceed and you don’t get this notification every day.
Thanks, didn’t catched that. However - sad news for 1.x Still looking for painless way how to sync/backup part of data on a turris hdd to some cloud…
Can’t you run Syncthing in an LXC container?
If I understand it correctly - for Turris 1.x - no, because of golang dependency, which is not available for ppc platform (generally as I understand). Same thing is rclone.
@Pepe what is that PHY issue is there some bug report on GitLab?
Turris 1.x, update 5.4.4 ->6.2.0 blocked by package python-pip, after removal of that package ok, except:
all LEDs bright blue, both CLI nad GUI tools for controlling the LEDs failing
rainbow reset reader_loop: bad jump: 8388608 Aborting...
luci-app-rainbow - 2.2-2
rainbow - 0.1.3-3
rainbow-animator - 0.1.3-3
rainbow-button-sync - 0.1.3-3
turris1x-rainbow-backend - 0.1.3-3
See also Turris OS 6.0.2 is now released - #20 by skorpil_cz
Edit: The solution is:
mv /etc/config/rainbow /etc/config/rainbow_old
After that, it is possible to genetate a new config via GUI.
reboot because restarting the rainbow service doesn’t work.
It is then also possible to adjust brigtness but some errors persist:
rainbow brightness 1 Command failed: Not found Command failed: Not found
6.0.4 → 6.2.0
Looks everything is working like in 6.0.4, only WLAN LED is not flashing/lighting. But it was not working also on 6.0.4. All other LEDs works fine and it is possible to change color by Rainbow in LuCI. The LED is not damaged, during boot or after rollback to TOS 3.11 it works
That affects only Turris 1.x routers running LTS kernel 5.15 and yes, there is such issue, where we are tracking it, but it is not public right now.