Turris OS 5.0.0 is released in HBT

Thanks for reporting. In one of the previous RC versions, we did a small improvement for Sentinel DynFW client and now we forward stderr to syslog by default.

I created an issue from your output:

In the meantime, would you please send me an email to tech.support@turris.cz, where you will include diagnostics and as well output from ipset list | head? This could help us to take a look at it and if we need any more details, we will get back to you soon!

1 Like

Mox Clasic TOS 5.0.0 branch HBK Kernel 4.14.180
Foris OK - all tabs working, reForis & LuCi dtto

I have find the error. I have load to many blocklist. After i reduce the blocklist, adblock load again.

MFG redFOX

Since a few weeks i have issues with adblock on this HBT os. Some IP’s ( even whitelisted ) have some sort of connection problem. If i ping that specific site, it sometimes works, and sometimes not. If i switch adblock off, no problem.
Tried diff lists, but no result.

I know, noone can do precise predictions, but are there still many issues open for 5.0.0 or will it be any time soon, when we can expect this release to be approved for hbs?
I need to rearrange my network setup and want to start with current firmwares only…
(And going with not stable firmware has a zero at the women/family-acceptance-factor)

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

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

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.

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 :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

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!

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