- opkg (I don’t even know about updater-ng)
- I get some info on packages that are already installed and none for packages in the repos.
Sounds like you didn’t run opkg update before trying to get the info?
Good idea but I have checked that and it is not the case.
1 Like
By this I mean that I definitely did run that before checking for package info.
opkg info tcpdump gives me some info after all the error messages for the other packages.
opkg info netdata only generates the errors
Try with pkgupdate --reinstall-all or opkg update ; opkg --force-reinstall
RC6 version of Turris OS 5.0 is released now!
Changelog:
- removed procd-seccomp from hardening package list
- improvements for transmission seccomp support
- dovecot update to version 2.3.10.1
- adblock update to version 4.0.5
- nano update to version 4.9.3
and many other changes.
2 Likes
Mox Classic, TOS 5.0.0 branch HBK Kernel 4.14.180
simple config with WiFi
Foris, reForis & LuCi - OK - all tabs working.
This thread is about HBT, not HBK.
Not HBL but HBT 
Maybe I don’t understand it well, I thought that all updates are at first tried in HBK and later passed to HBT… I apologise if I’m mistaken.
Exactly! You are right.
1 Like
But this thread isn’t about HBK.
I somehow missed there was a release in progress, so decided to try RC6 today.
Switched to hbt from hbs (4.0.5) on a Turris Omnia. I got some errors during the upgrade process (non-fatal), not sure if these are useful without the entire log of switch-branch hbt, which I have saved. @Pepe where/how can I submit the log?
My Omnia has a few custom configurations (LAN4 set to VLAN trunk, additional “untrusted” internal network on VLAN, custom kresd config, RIPE Atlas SW probe installed). Everything seems to be working so far, apart from the Atlas probe – atlas.ripe.net is showing it as disconnected. I get the following from service atlas log after doing a service atlas restart:
06/01/20 21:28:36 net-try
06/01/20 21:28:39 net-ok
06/01/20 19:28:39 reg-init
06/01/20 19:28:41 ctrl-init
Note the weird times, looks like net-* is printing local time (CEST) and the rest UTC? Since that wasn’t too helpful, I enabled option log_stdout in /etc/config/atlas, re-started the probe and here’s what I see in /var/log/messages that looks relevant:
Jun 1 19:28:36 turris ATLAS[12110]: enough space free, no need to do anything
Jun 1 19:28:36 turris ATLAS[12110]: buddyinfo: can't open '/proc/buddyinfo': No such file or directory
Jun 1 19:28:36 turris ATLAS[12110]: buddyinfo: can't open '/proc/buddyinfo': No such file or directory
Jun 1 19:28:36 turris ATLAS[12110]: RESULT 9000 done 1591039716 d858d7001c52 STARTING ATLAS system ini
tialized (reboot count 0)
Jun 1 19:28:36 turris ATLAS[12110]: RESULT 9000 done 1591039716 d858d7001c52 STARTING TELNETD LOCALLY
Jun 1 19:28:36 turris ATLAS[12110]: buddyinfo: can't open '/proc/buddyinfo': No such file or directory
Jun 1 19:28:36 turris ATLAS[12110]: buddyinfo: can't open '/proc/buddyinfo': No such file or directory
(dump of interfaces follows, which I’m omitting for privacy, followed by)
Jun 1 19:28:36 turris ATLAS[12110]: perd: in my_exit (exit was called!)
Jun 1 19:28:36 turris ATLAS[12110]: Aborted
Jun 1 19:28:36 turris ATLAS[12110]: eperd: in my_exit (exit was called!)
Jun 1 19:28:36 turris ATLAS[12110]: Aborted
Jun 1 19:28:36 turris ATLAS[12110]: buddyinfo: can't open '/proc/buddyinfo': No such file or directory
Jun 1 19:28:36 turris ATLAS[12110]: RESULT 9006 done 1591039716 d858d7001c52 no reginit.vol start regi
steration
Jun 1 19:28:36 turris ATLAS[12110]: /usr/libexec/atlas-probe-scripts/status/reginit.vol does not exist
try new reg
Jun 1 19:28:39 turris ATLAS[12110]: And we are done
Jun 1 19:28:39 turris ATLAS[12110]: Ping works
Jun 1 19:28:39 turris ATLAS[12110]: start reg
Jun 1 19:28:39 turris ATLAS[12110]: ATLAS registeration starting
Jun 1 19:28:39 turris ATLAS[12110]: unknown keyword 'REG_WAIT_UNTIL' in CON_INIT_CONF (1)
Jun 1 19:28:39 turris ATLAS[12110]: REGHOSTS reg03.atlas.ripe.net 193.0.19.246 2001:67c:2e8:11::c100:1
3f6 reg04.atlas.ripe.net 193.0.19.247 2001:67c:2e8:11::c100:13f7
Jun 1 19:28:39 turris ATLAS[12110]: buddyinfo: can't open '/proc/buddyinfo': No such file or directory
Jun 1 19:28:39 turris ATLAS[12110]: ssh -i /usr/libexec/atlas-probe-scripts/etc/probe_key -p 443 atlas
@2001:67c:2e8:11::c100:13f7 INIT
Jun 1 19:28:41 turris ATLAS[12110]: unknown keyword 'REG_WAIT_UNTIL' in CON_INIT_CONF (2)
Jun 1 19:28:41 turris ATLAS[12110]: Got good controller info
Jun 1 19:28:41 turris ATLAS[12110]: cat: can't open 'known_hosts_controllers': No such file or directo
ry
Jun 1 19:28:41 turris ATLAS[12110]: check cached controller info from previous registeration
Jun 1 19:28:41 turris ATLAS[12110]: NO cached controller info. NO REMOTE port info
Jun 1 19:28:41 turris ATLAS[12110]: Do a controller INIT
Jun 1 19:28:41 turris ATLAS[12110]: buddyinfo: can't open '/proc/buddyinfo': No such file or directory
Jun 1 19:28:41 turris ATLAS[12110]: Controller init -p atlas@ INIT
Jun 1 19:28:41 turris ATLAS[12110]: 255 controller INIT exit with error
Jun 1 19:28:41 turris ATLAS[12110]: buddyinfo: can't open '/proc/buddyinfo': No such file or directory
Jun 1 19:28:41 turris ATLAS[12110]: buddyinfo: can't open '/proc/buddyinfo': No such file or directory
Jun 1 19:28:41 turris ATLAS[12110]: condmv: not moving, destination '/usr/libexec/atlas-probe-scripts/
data/out/simpleping' exists
Any ideas?
Reported upstream with a fix at https://github.com/RIPE-NCC/ripe-atlas-software-probe/issues/38, but Turris OS 5.0.0 will need an update to the atlas-sw-probe package for this to be fixed.
1 Like
Would you mind to share any outputs? You can update and look at the package info how do you want even that it shows some warnings. Those are harmless.
root@omnia:~# opkg info netdata
Package netdata version 1.22.1-1 has no valid architecture, ignoring.
Package foris-controller-hotplug version 1.0.13-3.7-1 has no valid architecture, ignoring.
Package turris-diagnostics version 12.0-1 has no valid architecture, ignoring.
Package sentinel-proxy version 1.1-6.48 has no valid architecture, ignoring.
Package foris-controller version 1.0.13-3.7-1 has no valid architecture, ignoring.
Package logd version 2019-06-16-4df34a4d-3.0 has no valid architecture, ignoring.
Package: netdata
Version: 1.12.2-1.36
Depends: libc, zlib, libuuid, libmnl
Status: unknown ok not-installed
Section: admin
Architecture: arm_cortex-a9_vfpv3
Size: 1497725
Filename: netdata_1.12.2-1_arm_cortex-a9_vfpv3.ipk
Description: netdata is a highly optimized Linux daemon providing real-time performance
monitoring for Linux systems, applications and SNMP devices over the web.
If you want to use Python plugins install python3, python3-yaml and
python3-urllib3root@omnia:~# opkg info python3
Package netdata version 1.22.1-1 has no valid architecture, ignoring.
Package foris-controller-hotplug version 1.0.13-3.7-1 has no valid architecture, ignoring.
Package turris-diagnostics version 12.0-1 has no valid architecture, ignoring.
Package sentinel-proxy version 1.1-6.48 has no valid architecture, ignoring.
Package foris-controller version 1.0.13-3.7-1 has no valid architecture, ignoring.
Package logd version 2019-06-16-4df34a4d-3.0 has no valid architecture, ignoring.
Package: python3
Version: 3.6.10-3.6-1.0
Depends: libc, python3-light, python3-unittest, python3-ncurses, python3-ctypes, python3-pydoc, python3-decimal, python3-multiprocessing, python3-codecs, python3-gdbm, python3-xml, python3-sqlite3, python3-logging, python3-email, python3-distutils, python3-openssl, python3-cgi, python3-cgitb, python3-dbm, python3-lzma, python3-asyncio
Status: install user installed
Section: lang
Architecture: arm_cortex-a9_vfpv3
Size: 1088
Filename: python3_3.6.10-3.6-1_arm_cortex-a9_vfpv3.ipk
Description: This package contains the (almost) full Python install.
It's python3-light + all other packages.
Installed-Time: 1591097844root@omnia:~# opkg install atlas-sw-probe
Package netdata version 1.22.1-1 has no valid architecture, ignoring.
Package foris-controller-hotplug version 1.0.13-3.7-1 has no valid architecture, ignoring.
Package turris-diagnostics version 12.0-1 has no valid architecture, ignoring.
Package sentinel-proxy version 1.1-6.48 has no valid architecture, ignoring.
Package foris-controller version 1.0.13-3.7-1 has no valid architecture, ignoring.
Package logd version 2019-06-16-4df34a4d-3.0 has no valid architecture, ignoring.
Installing atlas-sw-probe (1.0.1-1.0) to root...
Downloading https://repo.turris.cz/hbs/omnia/packages/turrispackages/atlas-sw-probe_1.0.1-1_arm_cortex-a9_vfpv3.ipk
Installing sudo (1.8.28p1-1.20) to root...
Downloading https://repo.turris.cz/hbs/omnia/packages/packages/sudo_1.8.28p1-1_arm_cortex-a9_vfpv3.ipk
Installing atlas-probe (2.1.1-1.2) to root...
Downloading https://repo.turris.cz/hbs/omnia/packages/turrispackages/atlas-probe_2.1.1-1_arm_cortex-a9_vfpv3.ipk
Configuring sudo.
Configuring atlas-probe.
Configuring atlas-sw-probe.You might notice that I am downloading packages from HBS branch and I did downgrade from HBK to HBS. This does not happen at HBS at all. This is present in Turris OS 5.0.0 caused by changes in upstream. If you don’t want to have these warnings, you can reinstall the packages as it is suggested in the issue, which was mention to you.
Buddyinfo is only supported on HW probes and on RIPE Atlas probes v3 & v4. So basically buddyinfo in SW Probes is not supported and by default, it is disabled since version 5020. In all Turris OS versions, while I don’t count Turris OS 4.0, there is version 5010. I have good news before Turris OS 5.0 gets into feature freeze, we updated it to version 5020, so it will be in upcoming HBK build and in the next RC!
You can see in the logs rows like this, but it is harmless.
buddyinfo: can't open '/proc/buddyinfo': No such file or directory
Before I will be able to confirm your observations, I need to be more careful. I with @ja-pa are looking into it. For now, it is not easy to tell why it works in some cases or not. For example in HBS and not even in HBT/HBK/HBL, it says that my probe on the RIPE website is offline while according to logs it was doing something. It could be a different issue at all. Once I installed version 5020 it was working a few minutes. On the other hand, my probe installed on Turris 1.1 (Turris OS 5.1/HBL) is online for a month, which does not make it easy for debug! A more detailed answer on this one will come later.
Sending it to Technical support, which is available on tech.support@turris.cz is a good way!
Thanks. I think we may also need the extra fix for REG_WAIT_UNTIL which got committed upstream here: Forgot REG_WAIT_UNTIL in one place (thanks to Martin Lucina) · RIPE-NCC/ripe-atlas-software-probe@0d30e89 · GitHub.
I know it’s harmless, but prefer to keep my logs free of things that look like failures, otherwise it’s hard to tell the noise from the signal.
It may be that something changed on the RIPE side, and the servers started returning REG_WAIT_UNTIL responses in situations where the probe wasn’t expecting them. Hard to say, the code is very hard to follow.
Before I applied the fixes described here and in the upstream issue, the behaviour that I saw was similar to what you’re describing – the probe was running but continually failing to register due to not handling the REG_WAIT_UNTIL response:
Jun 1 19:28:41 turris ATLAS[12110]: unknown keyword 'REG_WAIT_UNTIL' in CON_INIT_CONF (2)
followed by
Jun 1 19:28:41 turris ATLAS[12110]: Controller init -p atlas@ INIT
Jun 1 19:28:41 turris ATLAS[12110]: 255 controller INIT exit with error
As far as I can tell, the error is due to reginit.sh getting its variables confused by the parse error so $CONTROLLER_1_PORT and $CONTROLLER_1_HOST are unset.
After applying my fixes, the successful registration looks like this:
Jun 1 20:50:24 turris ATLAS[21361]: start reg
Jun 1 20:50:24 turris ATLAS[21361]: ATLAS registeration starting
Jun 1 20:50:24 turris ATLAS[21361]: there is WAIT, REG_WAIT_UNTIL , now is 1591044624
Jun 1 20:50:24 turris ATLAS[21361]: REG_WAIT_UNTIL expired go re-reg 1591044564 now 1591044624
followed by:
Jun 1 20:50:26 turris ATLAS[21361]: Do a controller INIT
Jun 1 20:50:26 turris ATLAS[21361]: Controller init -p 443 atlas@ctr-fsn01.atlas.ripe.net INIT
Jun 1 20:50:27 turris ATLAS[21361]: initiating KEEP connection to -R 54087 -p 443 ctr-fsn01.atlas. ripe.net
Hope this helps. Do you have a tracking issue for this? Probably easier to discuss there rather than in an already long forum thread.
Done.
This time, we are releasing a new lucky 7 number (RC7) of Turris OS 5.0. As said earlier Turris OS 5.0 is being in feature freeze, which means that no features are going to be included in this release and they will be introduced in Turris OS 5.1.
In this version, there is an updated Ripe ATLAS SW probe to its latest version 5020 and updated reForis to version 0.8.1, which brings updated translations.
Upstream changes:
- mosquitto updated to version 1.6.10,
- gstreamer updated to version 1.16.2,
- pigeonhole: updated to version 0.59
- luci-app-https-dns-proxy: add Cloudflare Family/Protect
This version should reach hopefully Stable soon.
2 Likes
/reforis/package-management/packages → click Save →
An unknown API error occurred.
EDIT: Foris can do the same fine and not everyone will experience it; we’re working on the issue now.
All of my SW Atlas Probe (Turris 1.x, Omnia and MOX) are offline since update running.
This seems to be related what has been discussing here, I will write it to mailing list. We should do it earlier, but it happened and it would happen anyway. But in my case the probe was was offline for a few minutes and in some special cases it took hour or two and maybe more, but it gets connected. Would you please check it later? I know that it is not good as it should be, but this seems like something not happening on our side.