Turris OS 5.0.0 is released in HBT

Okay, that was bad. I tried a switch-branch hbt on my Omnia and bad things happened:

Wifi 1 stopped working
wan didn’t work some of the time. Sometime reboot fixed it.
ssh just didn’t work. It got to password prompt and then hangs

Switching back to hbs from luci seemed to work, but sshd still doesn’t get passed entering the password. Not being able to ssh to investigate issues is very limiting so I attempted a schnapps rollback to the pre-upgrade snapshot.

To your second point, I found the docs on your website. I had to go and get ssh set up as well cause LuCI commands won’t go through the whole flow automatically.

As for my experience so far with TOS 5:
Works fine.
I like some of the LuCI changes and dislike some others, probably most of this is not you guys.
Having some new behaviour with the PCI LEDs and I can’t see how that’s set, maybe I can’t see it because of preexisting configuration. I did like the fancy power up animation :slight_smile:

Do you have any thoughts on enabling WPA3 on default install?

Today, we are releasing a new RC of Turris OS 5.0.0 in the Testing branches.

We heard your voices that in some cases update was not smooth as it should be especially on Turris MOX routers. We worked on Updater, so it should take a less memory during the update. We removed sysgupgrade from the system. It is not available anymore as it is dangerous. We converted DHCP script to Python 3 and there is updated Knot Resolver to version 5.1.0. And we updated Sentinel DynFW, which addresses issue, which was mention here as well.

There are changes from feeds, which we are using, for example, updated wireguard, youtube-dl, fixed some issues with Cloudflare in ddns-scripts and added a new package - gerbera, which should be a replacement for MiniDLNA.

2 Likes

MOX update works, but device change MAC address again.

Have you solved the problem where the WiFi drivers fail to load with vmalloc error?

After upgrade the LUCI and Foris were not accessible. There seems to be missing python link to python3.
After running following commands, both working fine again.

ln -s /usr/bin/python3 /usr/bin/python
reboot

There is also a new topic here Luci inaccessible.

1 Like

Hi,
no the WiFi Probmel with the vmalloc is bigger in the new Version.
I can not load 6 kernel Driver.
Can i expand the vmalloc?

Blockquote
[ 16.763126] kmodloader: 6 modules could not be probed
[ 16.768230] kmodloader: dependency not loaded mac80211
[ 16.773455] kmodloader: - ath10k_core - 1
[ 16.777506] kmodloader: dependency not loaded ath10k_core
[ 16.783004] kmodloader: - ath10k_pci - 1
[ 16.786953] kmodloader: dependency not loaded mac80211
[ 16.792128] kmodloader: dependency not loaded ath9k_hw
[ 16.797316] kmodloader: dependency not loaded ath9k_common
[ 16.802887] kmodloader: - ath9k - 3
[ 16.806423] kmodloader: dependency not loaded ath9k_hw
[ 16.811619] kmodloader: - ath9k_common - 1
[ 16.815745] kmodloader: - ath9k_hw - 0
[ 16.819553] kmodloader: - mac80211 - 0

strange - for me the vmalloc is exactly the same as before, ath10k works but ath9k still gives the vmalloc error.

New problem (apart from the missing python resulting in foris and luci not working as described above) is luci_statistics stopped to work:
root@turris:~# /etc/init.d/luci_statistics restart
/usr/bin/lua: /usr/bin/stat-genconfig:37: attempt to index upvalue ‘sections’ (a boolean value)
stack traceback:
/usr/bin/stat-genconfig:37: in function ‘section’
/usr/bin/stat-genconfig:318: in main chunk
[C]: ?

This does not even work with the default file (copied luci_statistics-opkg to luci_statistics, same error)

Hi,
after update the Adblocker don’t work any more. kresd is running.

Blockquote
adblock-4.0.4[18014]: adblock instance started ::: action: start, priority: 0, pid: 18014
adblock-4.0.4[18014]: dns backend restart with adblock blocklist failed
kresd[31494]: [poli] RPZ /etc/kresd/adb_list.overall:3: RR type NS is not allowed in RPZ

The “not allowed” messages are just warnings, so I can’t see why it failed for you. (And in case of NS and SOA the warning is quite misleading; I’ll look into improving that.)

I have switched to hbt today. When trying to access luci, before login, I got:

/usr/lib/lua/luci/dispatcher.lua:426: /etc/config/luci seems to be corrupt, unable to find section 'main'

I have tried to restore /etc/config/luci to default without any change.

Maybe this one?

Indeed, this fixed it. Thanks.

I think @dibdot can help you with that, if you ask. :slight_smile:

Sorry for any issues caused by this! It is going to be fixed in the upcoming RC version.

1 Like

But does it work at all? I think your issue is different, which has @redFox according to the details, which were given by you.

Did you experience it as well or you were just scary by one post?

We will not enable it by default for now. We were discussing it and decided not to include it. There are just a few devices, which support WPA3, but the main point is which you should be asking why OpenWrt does not have it enabled and preinstalled by default. They have it optional. but on our forum, it was described how to do that. If I am not mistaken it was because some client devices will have issues connecting to the WPA3 network neither they do not connect to it even if it was set to WPA2+WPA3 mixed mode.

In the future, we would like to do a package list for WPA3. It means that in Foris/ReForis you will see in the Updater tab option to choose WPA3 support.

It does not make sense to write your issue multiple times. You should write to tech.support@turris.cz as it was described in OP. If you wrote it there, then fine. Guys will reply to you soon and ask you to more details, if they need it.

Your reported bug affects just Turris 1.x routers. We are not sure what is causing it. We didn’t look at it, so far. There are created two issues about it:


No known workaround, sorry.

Yes I had the exact same problem two weeks ago when I tested HBT branch, but I since rolled back to Turris OS 4.0.5.

In that case, you need to provide any details which should help us to reproduce the issue. We were thinking that there is possibility that one guy could have some problems with HW and it needs to be sent to us, but if it affects many people it needs to be investigated before releasing but without providing any details it is not helpful either.