Unable to access Forris web interface (even reboot).
In the screenshot of the unexpected error, I see there is a small description which says that you should download error protocol and send it to tech.support@turris.cz. The screenshot is not complete and I see just Incorrect output. Not sure why it is caused, but I would like to please follow those details which are there.
What SDK can be used with the new 5.0 version?
I would like to say the new 5.0 interfaces, both LuCI and Foris, seems faster to me. Thank you for the hard work getting this out.
After my adventures in upgrading, I thought I should post some issues I’m having with 5.0 and where I should report the errors.
First, from notifications:
Package luci-app-radius requires package freeradius2-mod-files that is not available.
freeradius2-mod-files appears to be available and installed.
It does appear that luci-app-radius is a package in the repo:
I don’t know how to tell if this is going to be available as an installable package or if it only existed for 3.x Turris/15.05 OpenWRT and isn’t going to be moved forward.
Second, LuCI statistics df module throws an error on the page:
/usr/lib/lua/luci/statistics/rrdtool.lua:319: attempt to index field 'data' (a nil value)
stack traceback:
/usr/lib/lua/luci/statistics/rrdtool.lua:319: in function '_generic'
/usr/lib/lua/luci/statistics/rrdtool.lua:559: in function 'render'
.../luci/controller/luci_statistics/luci_statistics.lua:170: in function <.../luci/controller/luci_statistics/luci_statistics.lua:114>
I’ll try spending some time troubleshooting this, but it’s not urgent to me.
Also LuCI statistics openvpn module doesn’t work, but it didn’t work before the upgrade, so I’m not particularly concerned about that.
Anyway, after I got the upgrade to go, I am very impressed with the upgrade so far given the complexity of making it.
This could be in some cases a little bit problematic. We don’t provide SDK and it has several reasons.
In turris-build repository, you will find in README documentation what you need to do to compile packages with dependencies, which you need to have installed and also you might find there is workflow. There’s a possibility to use OpenWrt SDK, which I don’t recommend. One reason was said here a few days ago. Somebody downloaded outdated SDK and tried to compile something, which has a dependency for OpenSSL, but in that SDK was outdated and on his router, it was running the latest one due to fixes for security vulnerabilities. Another reason is that we are using patches and we could have the latest versions of some packages, which we sent to upstream (takes time to review it and merge it), but it was not included in the SDK. For the stable versions, they build SDK once a new version is released.
If I am not mistaken, there are 3 commands what you need to have working tools to compile packages for Turris OS / OpenWrt (git clone, cd, compile_pkgs script). It depends on your PC, but usually, it takes less than an hour. In my case, I have it ready within 20-30 minutes.
Package freeradius2-mod-files is indeed not available. You were using Turris OS 3.x don’t you? Freeradius 2 is deprecated and end of life. I was able to found this commit:
Freeradius2 was not available to install in OpenWrt 18.06 (and Turris OS 4.0 was based on top of it). I would highly encourage you to use Freeradius3. See their homepage:
I am not able to find luci-app-radius in Turris OS 3.x and not even in OpenWrt feeds. Isn’t there a possibility that you compile it and installed it yourself?
Regarding the commit, which you found in turris-os-packages it is not used and the branch should be deleted. We are using test(for 3.x), master (5.0.x/5.1.x), develop (5.0/5.1/5.2).
That’s what I have been using with Turris 3.x, because there were packages I wanted to use, but were not available directly. And as you mentioned there were problems with versions that could lead to a serious dependency hell.
Currently, it looks like all I had to build myself is now available with 5.0.0, so this is not a big deal anymore.
Thank you for your answer.
Ah, thank you for that information.
I did indeed compile it myself for 3.x. It’s only some LuCI interface I think with a small database. Having seen it in the source repository got my hopes up.
Thanks again for the info, I’ll move on to Freeradius3 to see what that brings.
I found an annoyance, but it doesn’t seem to affect anything and seems at least related to my local repo:
Package lcollect-majordomo version 28 has no valid architecture, ignoring.
Package freeradius2 version 2.2.9-1 has no valid architecture, ignoring.
Package suricata version 3.2-3 has no valid architecture, ignoring.
Package samba36-server version 3.6.25-11 has no valid architecture, ignoring.
Package freeradius2-mod-files version 2.2.9-1 has no valid architecture, ignoring.
Package luci-app-samba4 (git-20.155.55664-f35803e-1.0) installed in root is up to date.
I removed my local repo files since they’re all out of date anyway and reran the “Update Lists…” and it still complains. I’m not sure where else to look for correcting this.
TLDR it is harmless and it is because architecture name changed in upstream.
1 Like
Hi, I have installed Turris OS 5.0 using the omnia-medkit-latest.tar.gz via a USB flash drive. Before that I was running the latest version of TOS 3.
After the set up I have two issues where I seek some support on:
- 2.4 GHz wifi card not working
Both wireless cards are displayed in Foris and 5G works just fine. In TOS 3 the 2.4 wifi card worked well.
lspci
02:00.0 Network controller: Qualcomm Atheros AR9287 Wireless Network Adapter (PCI-Express) (rev 01) 03:00.0 Network controller: Qualcomm Atheros QCA986x/988x 802.11ac Wireless Network Adapter
/var/log/messages
Jun 9 17:47:26 turris foris-controller[5707]: radio1(): Interface type not supported
- kresd file-descriptor issue
Configured using Foris:
- Use forwarding
- Enable DNSSEC
- Enable DHCP clients in DNS
/var/log/messages
Jun 9 16:27:24 turris kresd[17173]: [system] warning: hard limit for number of file-descriptors is only 4096 but recommended value is 524288
/etc/config/resolver:
config resolver ‘common’
list interface ‘0.0.0.0’
list interface ‘::0’
option port ‘53’
option keyfile ‘/etc/root.keys’
option verbose ‘0’
option edns_buffer_size ‘4096’
option msg_buffer_size ‘65552’
option msg_cache_size ‘20M’
option net_ipv6 ‘1’
option net_ipv4 ‘1’
option forward_upstream ‘1’
option prefered_resolver ‘kresd’
option prefetch ‘yes’
option static_domains ‘1’
option ignore_root_key ‘0’
option dynamic_domains ‘1’
option forward_custom ‘99_quad9_filtered’
config resolver ‘kresd’
option rundir ‘/tmp/kresd’
option log_stderr ‘1’
option log_stdout ‘1’
option forks ‘1’
option keep_cache ‘1’
list rpz_file ‘/etc/kresd/adb_list.overall’
Any suggestions / comments apprciated!
Thank you.
There should be no issues from that. It’s been like this forever, now upstream just added a warning that it’s not ideal, but for SOHO 4k is plenty anyway (according to my tests).
1 Like
did those branches change so quickly? When I tried switch-branch hbs (I’m using hbt now), it advised me installing ~200 packages.
or is there any reason to use:
pkgupdate --reinstall-all
when switching to branch with the same set of packages?
@fantomas here is a reason why this is done. It is primarily because of switch between HBK, HBL and HBD. Those branches can provide packages with same version but linked against different dependencies. Nothing like that should (and won’t) happen on switch between HBK, HBT and HBS. The simplest solution at the beginning was to reinstall all. Turris OS 5.1 is going to contain new version of switch-branch that detects this and plans reinstall of all packages accordingly. Why it wasn’t it implemented that way immediately can be seen from this MR https://gitlab.labs.nic.cz/turris/turris-os-packages/-/merge_requests/217. It just wasn’t easy to do and was a lot of work to do it right.
Turris OS 5.0 on hardware 1.0 -> data collection for project.turris.cz is not supported? I cannot find the settings to link the router.
Probably not.
Old data collection system (via https://project.turris.cz/) was replaced by Sentinel (https://sentinel.turris.cz/) since TurrisOS 4.0
Actually I used those stats mainly to see my IP v4/v6 stats. Sentinel is nice but its not personalized.
Yes, Sentinel is unfortunately still in development and experimental mode.
But many of its modules already work well.
This isn’t critical, but I was browsing my log messages and found this:
smbd[15716]: Unable to open printcap file /etc/printcap for read!
I noticed the old smb.conf.template had
load printers = No
printcap name = /dev/null
and the new one didn’t.
For someone who has a spare original Omnia (i.e. no configuration to preserve) what is the simplest procedure to install OS 5.0 HBT?