I installed Turris OS 5.0 dev on my omnia yesterday.
Mostly working, the issue I found is that NFS server is not working anymore.
Today I did pkgupdate and after boot can’t login with neither ssh nor LuCi interface. Forris interface is working. But setting password for advanced administration seems not work. I have tried both having “use Forris password” and “use other password”.
I confirm. After the switch and a further update that required a reboot, I can no longer access via LuCI or via ssh. Even if I set the password in Foris, the situation does not change.
Did you delete the browser cache and try after that again? That helped me in similiar situation on native openwrt 19.07-rc2.
Yes, I tried. Also access via browser tab in incognito. But it doesn’t change. I can enter both Foris and ReForis. I can’t do it in LuCI or in ssh. I tried to change my password or choose the same password for Foris and LuCI, but I still get a password error in both LuCI and ssh. It looks similar to this https://forum.openwrt.org/t/ssh-not-working-after-upgrade-to-18-06-0-from15-05/18019
But not being able to access LuCI I can’t try that solution.
My bad, didn’t read carefully. In my case I didn’t have problems with ssh.
Edit: do you use password or public-key authentication in ssh?
I use only the password. I would like to avoid resetting again.
Hey folks,
I’m wondering about release of v.5.x because I missed stable v.4.x. Did I miss something? Is there a safe way to upgrade from 3.x to 4.x?
We are working on automatic migration from 3.x to 4.x and it depends on your configuration. Since Turris OS 4.0, we have a different workflow which provides us new ways and possibilities. Because of that, we can provide you builds of OpenWrt RC, master daily snapshots and so on without doing re-flash and losing all your settings each time with tool switch-branch.
@Pepe Do you think it is possible that with an update the impossibility to access SSH and LuCI will be resolved or should I reset / use failsafe mode / etc? Can you reproduce the problem?
WPA3 settings is not available.
MOx clasic, ,5 MB, WiFi
Unfortunately stil errors, see
inconsistent: Package sentinel-dynfw-client requires package python3-zmq that is not available.
+ echo 'Updater execution exited with error. Please see previous output to know what went wrong.'
Updater execution exited with error. Please see previous output to know what went wrong.I tried to switch a dragons again. It happened again on Omnia. This time, however, I activated ssh access via public key and turned off the other methods. This way I can access ssh even after the update. But the problem with LuCI remains, even after clearing the browser cache. Maybe it’s something related to password management. However Foris works normally. If you need some logs I am available. Thank you for your work.
Yes, we are able to reproduce the issue, which is described here. This is going to be fixed by this PR
There was no deafening or continuous silence. You can take a look at time when you wrote those two messages. It doesn’t make sense to write it multiple times as you are making thread confusing and longer.
For Turris MOX, there is still an issue about missing python3-zmq, we aware of it, there’s an issue created on our Gitlab. We are investigating it and most probably we most likely have a solution, but currently, it’s being reviewed by me. When python3-zmq is compiled successfully, we will let you know.
I also want to point out that the external storage function on USB cannot be activated by Foris on 19.07 (hbd). In fact, an error is returned in Foris notifications. However, you can enable it on another branch and then switch to drangons and the configuration is correctly stored.
Why would have the crypto functions been disabled in the first place? Passwords on my node are salted with SHA512 and now it is impossible to log into device via ssh and LuCI and thus the node cannot even be updated any more…
I noticed another bug: whichever server is chosen in the DNS tab will still be used the ISP one, although the green message appears that the configuration has been successful.
They were not disabled intentionally by us. They were disabled intentionally by upstream to save on storage space.
I set CZ.NIC as forward resolver in Foris and it correctly set configuration for kresd in /tmp/kresd.config with:
policy.TLS_FORWARD(
{{'193.17.47.1'
,hostname='odvr.nic.cz'
,ca_file='/etc/ssl/certs/ca-certificates.crt'
},{'185.43.135.1'
,hostname='odvr.nic.cz'
,ca_file='/etc/ssl/certs/ca-certificates.crt'
},{'2001:148f:ffff::1'
,hostname='odvr.nic.cz'
,ca_file='/etc/ssl/certs/ca-certificates.crt'
},{'2001:148f:fffe::1'
,hostname='odvr.nic.cz'
,ca_file='/etc/ssl/certs/ca-certificates.crt'
}}))})
Thank you for the clarification and taking care of the matter. upstream must be loosing their marbles when they are now starting to sacrisfy security for space. They probably have to realise at some point that it will not be possble for the distro to cater indefenitely for devices with scarce storage space.
The same thing for me
root@turris:~# cat /tmp/kresd.config
--Automatically generated file; DO NOT EDIT
modules = {
'hints > iterate'
, 'policy'
, 'stats'
, predict = {
window = 30 -- 30 minutes sampling window
, period = 24*(60/30) -- track last 24 hours
}
}
hints.use_nodata(true)
hints.config('/tmp/kresd/hints.tmp')
trust_anchors.add_file('/etc/root.keys')
net.bufsize(4096)
net.ipv4=true
net.ipv6=true
cache.open(20*MB)
table.insert(policy.special_names, { count = 0, cb = policy.all(
policy.TLS_FORWARD(
{{'1.1.1.1'
,hostname='cloudflare-dns.com'
,ca_file='/etc/ssl/certs/ca-certificates.crt'
},{'1.0.0.1'
,hostname='cloudflare-dns.com'
,ca_file='/etc/ssl/certs/ca-certificates.crt'
},{'2606:4700:4700::1111'
,hostname='cloudflare-dns.com'
,ca_file='/etc/ssl/certs/ca-certificates.crt'
},{'2606:4700:4700::1001'
,hostname='cloudflare-dns.com'
,ca_file='/etc/ssl/certs/ca-certificates.crt'
}}))})
But try using dnsleaktest.com or ipleak.net and you will see the real result. At least for me the server of my ISP
Same result also on hbl. Immune hbs, hbt and hbk are found.
