Turris OS 5.0.0 is released in HBT

#115

This time, we are releasing a new RC4 version of Turris OS 5.0, which is based on the latest OpenWrt 19.07.3 release.

This release is an important one as there is a mitigation for NXNSAttack security vulnerability. This affects many DNS resolvers. We created several pull requests for all OpenWrt versions. More details about it can be found on our blog, where colleagues from Knot Resolver described in more details.

There is updated php7, golang and added hack for ppp, which improves stability in some cases.

We are getting closer to release it to the Stable branch, but there a few things, which we need to get sorted out as reported in some cases ath9k driver is not loaded and services like transmission, umdns do not start.

If you know about anything else, please let us know.

7 Likes
Update Knot resolver in TOS 4
#116

A post was merged into an existing topic: Turris OS 5.0.0 is going to be in HBK

#117

I got a weird notification today in Foris:

Updater failed: Called uri_path on URI of scheme: https

It might be related to broken connection (and consequently DNS) at the moment. I don’t expect it’s really a problem, perhaps just a confusing message.

#118

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).

#119

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
#120

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.

PPPoE with Deutsche Telekom and VLAN7
#121

No more ath9k errors for me :wink:

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 crash
#122

I 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!

#123

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.
#124

That’s caused because of enabled hardening package list. We will remove it from there. Thank you for spotting this issue out.

#125

Hi,
the Problem was Fixed. Thank you!
Both WLAN are active.

#126

pkgupdate reported “umdns timeout”
Syslog reports after reboot: turris procd: /etc/rc.d/S80umdns: Command failed: Request timed out

#127

MOX hangs after update.

#128

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!

#129

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 https://gitlab.labs.nic.cz/turris/turris-build/issues/82 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.

#130

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
#131

root@turris:~# zcat /proc/config.gz | grep -ri “SECCOMP”
Result is
"CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
# CONFIG_SECCOMP is not set"

#132

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.

#133

Tried the upgrade again, it seems to be much more successful this time. Thanks for all the work stabilising it.

1 Like
#134

I’m getting error codes like this when I try to install or upgrade anything:

Package * version * has no valid architecture, ignoring.