I got this error every time I started a clean system from hbt medkit and ran pkgupdate before switch-branch (which tried to downgrade it to TOS 4).
This is known problem with error reporting in code that downloads updater configuration scripts. There should have been error reported but to assemble it a wrong method was called. This is the result. ("It is not allowed to call path on scheme https)
Issue is here https://gitlab.labs.nic.cz/turris/updater/updater/issues/293
This is already fixed but not yet released as it is part of significant updater rewrite that should land in Turris OS 5.1 (not yet present in either branch).
4 Likes
This time, we are releasing another RC of Turris OS version 5.0. It is RC5 now.
It brings you a security update for bind and package updates for syslog-ng and sslh. There is a disabled seccomp support, which means that some packages like transmission and umdns should be able to start. If you would like to try transmission, donât forget to configure it for the first time and enable it.
There might be an improvement in cases when ath9k driver could not be probed. If the issue persists, we would like to have output from cat /proc/meminfo once this issue happens. Also, if the issue is gone, please let us know.
No more ath9k errors for me 
But umdns do no start:
# grep umdns /var/log/messages
May 23 22:34:05 procd: /etc/rc.d/S80umdns: Command failed: Request timed out
May 23 22:34:23 procd: Instance umdns::instance1 s in a crash loop 6 crashes, 0 seconds since last crashI just updated to the newest RC (kernel 4.14.180) and the ath9k vmalloc issue is indeed fixed - both cards are working fine again and no vmalloc error is visible in dmesg, many thanks for fixing this!
I have been on hbt for a while. pkgupdate no longer works:
root@turris:/etc/updater/conf.d# pkgupdate
INFO:Target Turris OS: 5.0.0
WARN:Request not satisfied to install package: wpad
WARN:Requested package luci-i18n-rainbow-en that is missing, ignoring as requested.
WARN:Requested package luci-i18n-sqm-en that is missing, ignoring as requested.
line not found
line not found
line not found
line not found
line not found
ERROR:
inconsistent: Requested package procd-seccomp that is not available.
Thatâs caused because of enabled hardening package list. We will remove it from there. Thank you for spotting this issue out.
Hi,
the Problem was Fixed. Thank you!
Both WLAN are active.
pkgupdate reported âumdns timeoutâ
Syslog reports after reboot: turris procd: /etc/rc.d/S80umdns: Command failed: Request timed out
MOX hangs after update.
I take it there is an outstanding problem in setting VLAN on the WAN port - using PPPOE, my ISP requires me to use a VLAN of 101, I try setting eth2.101, as i was told to do and the whole thing fails. The system does work without the VLAN, just at half the D/L speed it should, which isnât good - I believe this is a fault, but how to get it recified?
NB it may be that VLAN is not working elsewhere, however In this case I can specifically see the results of the change and assess its actions, for other conditions I wouldnât have a clue!
It does not make sense to post it in almost every thread. We are not using any magic to say⌠In this update the router Turris MOX is not going to boot, but in this one it is! This happens randomly and we dont have any control about it. There is an issue about it MOX reboot stalls (#82) ¡ Issues ¡ Turris / Turris OS / Turris Build ¡ GitLab and our guys is still working on it.
Can you please post me an output of zcat /proc/config.gz | grep -ri "SECCOMP"? This will tell me if the SECCOMP support is set or not.
Did you use switch-branch or the update was applied to you while you were using HBT branch? If you were using HBT branch, it could happen that seccomp was not disabled to you and it is going to be applied with the next update of kernel or you need to reinstall package, which disables it.
I was already on hbt when I get the update.
# zcat /proc/config.gz | grep -ri "SECCOMP"
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
# CONFIG_SECCOMP is not set
root@turris:~# zcat /proc/config.gz | grep -ri âSECCOMPâ
Result is
"CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
# CONFIG_SECCOMP is not set"
Thanks, those two outputs are fine. There must be a different issue anyway umdns is not a critical service and the package comes from OpenWrt feed. Itâs weird that it works for me. Anyway, we will take a look. It will be most likely solved in fixup release of Turris OS 5.0 as it does not any affect services.
Tried the upgrade again, it seems to be much more successful this time. Thanks for all the work stabilising it.
1 Like
Iâm getting error codes like this when I try to install or upgrade anything:
Package * version * has no valid architecture, ignoring.
Good to know. Except it seems to be stopping me from updating and looking at package info.
updating through updater-ng or opkg or both? And getting package info for packages that are installed already or to be installed?