hmm aside from the update issue with my manually installed colliding package.
I noticed unbound not working after my ppp connection comes up, restarting unbound resolves the issue, but it still bothers me, espcecially since the omnia is still not getting more than 24h very often (random reboots are still there)
SQM is in default now (it was I think in previous release).
Is there any change, that our problems could be repaired by near future update or we should do OS reinstall from the scratch?
you ment chance?
i’d say yes, but flashing a medkit, and schnappsing while carefully
re-customizing seems to be the path of least pain.
Yes, I wanted to write “chance” 
It is always the best and the most secure to be on the latest version. We do not know about any common bugs on 3.5 for now.
I am really not sure what is happening yet. So I can’t say if it will be fixed. I am looking for evidences now. I really have to know what is happening when those problems starts.
As I see it now, everyone having problems interrupted update with reboot. After boot it starts recovery from journal and it seems like it might hang at some point. But it might also be that you did not give it enough time. And from log, I seen, it looks like problems some of you describe are then because updater recovery is running as part of initial boot, so standard reboot doesn’t work because boot isn’t finished yet. Opkg-trans has opkg lock and there is unfinished journal so even if you remove opkg lock updater halts on existing journal.
My experience with the 3.5 update was also not so smooth. Hopefully what I found will save some others some time:
For some reason, the time on the Turris Omnia was set to the year 2036. As I found out later, this resulted in DNS not working, since I had disabled using upstream DNS forwarders. (DNS began working when I re-enabled use of upstream DNS forwarders.) With the time being that far in the future, CZ-NIC certs were expired, so I got errors when attempting to opkg update.
In the middle of troubleshooting all this, I had used schnapps to rollback to a 3.4 snapshot. When trying to run updater.sh, things hung (for more than two minutes) with kresd or dnsmasq, I forget which, and I ended up killing the script.
Setting the Turris Omnia clock to my browser and enabling NTP got things back on track. I wish i had checked that sooner. I have since re-updated to 3.5 and disabled use of upstream DNS forwarders, since I want to use the working DNSSEC in Turris Omnia.
Has anyone else gotten user_notify emails sent from Turris Omnia and dated with year 2036? That was an early clue about my Turris Omnia having the wrong time.
Well I agree, but as I’ve said, I’ve tried several times to upgrade and it doesn’t work. If you have any suggestions I’d be happy to try them. Otherwise I have to wait until I have time to do a factory recover, upgrade, and then re-do my configuration, something which will take a few hours.
Does anyone have problems with wi-fi client-to-client connectivity? It seems that new drivers have “client isolation” enabled and I don’t see any option to disable it.
You could try adding “option isolate ‘0’” to wifi-iface sections in /etc/config/wireless and then restart wifi services or reboot.
This update not only fixed a bug in PPPoE, but also in PPtP VPN (both clients and servers), where MSCHAPv2 authentication tokens were computed incorrectly. Now it’s completely possible to run PPtP VPN server on my Omnia, yay!
2 Likes
This topic is no longer a banner. It will no longer appear at the top of every page.