Turris OS 6.4.2 is released!

Dear Turris users,

we just released Turris OS 6.4.2, not many changes, but it still contains important updates and some bugfixes.

:rocket: New Features

• Schnapps supports local remote storage (local:// or file://)
• php8-pecl-sodium package backported to better support Nextcloud

:pushpin: Updates

• Linux kernel updated to 5.15.127 (MOX, Omnia) and 5.10.191 (Turris 1.x)
• Samba updated to version 4.18.6
• Knot Resolver updated to version 5.7.0

:bug: Bug Fixes

• gcc: passing correct build options on Turris 1.x
• nextcloud: add php8-pecl-sodium as dependency
• webapps-tvheadend: fix dynamic config file generation

8 Likes

TO 2016, HBS branch, 2 GB, 2x WiFi, HaaS, RIPE Atlas, Sentinel, lxc, SSD (logs etc), simple config, all seems OK.

1 Like

TO 2020, 2 GB edition: v6.4.1 → v6.4.2

Everything works so far even after the reboot.

  • mSata mounts
  • LXC
  • Vlan
  • Wifi (2.4 Ghz + 5 Ghz)
  • DDNS

@miska, what does Schnapps supports local/remote storage mean? As I can save as well as restore from a remote place?

Edit: nevermind, i looked it up about remote. Very nice indeed as i already have a Nextcloud instance running within my network.

Just startet the update for my TO router and got the following error-message:

[31-Aug-2023 11:26:32] ERROR: Another FPM instance seems to already listen on /var/run/php8-fpm.sock
[31-Aug-2023 11:26:32] ERROR: FPM initialization failed

Do I need to do anything after manually after the reboot? This is related to nextcloud-installation I assume.

edit: Nextcloud is running well after reboot, so no idea if this error is of any relevance.

edit 2: Seems all updates went well that far for my TO router (only app running currently is NC instance) and two dumb APs (MOX A(SDIO)D(2,5GBE)B(WLE1216v5-20) + TO with 1xNP1+2xNPD).

Nextcloud is still reporting missing sodium, even if the new sodium package is installed.

I see the same. Despite having the sodium packages installed. In PHP sodium podule seems to be activated. See below.

Can it be related to this issue [Bug]: Nextcloud asking for sodium although being installed · Issue #35593 · nextcloud/server · GitHub?

$ opkg list-installed | grep sodium
libsodium - 1.0.18-4
php8-pecl-sodium - 2.0.23-1
$ sudo -u nobody /usr/bin/php-cli -i | grep sodium
/etc/php8/30_sodium.ini,
sodium
sodium support => enabled
sodium compiled version => 2.0.23
libsodium headers version => 1.0.18
libsodium library version => 1.0.18
$ sudo -u nobody /usr/bin/php-cli -m | grep sodium
sodium
$ sudo -u nobody /usr/bin/php-cli -r 'print_r(get_defined_constants());' | grep -i argon
    [SODIUM_CRYPTO_PWHASH_ALG_ARGON2I13] => 1
    [SODIUM_CRYPTO_PWHASH_ALG_ARGON2ID13] => 2
    [SODIUM_CRYPTO_PWHASH_STRPREFIX] => $argon2id$

MOX A+D TOS 6.4.1 > 6.4.2
Have approval enabled and hit install today.
Took a couple of minutes rhen the MOX locked up and my link to the world was gone.

Had to go down to the basement and pull the plugg to get it running again.

First lock up in a long time.

Now everything work as expected.

Following forum I saw many cases when after update something went amiss, but after reboot or powering off/on things got to normal… I wonder whether making reboot after any update mandatory wouldn’t solve such cases… maybe to allow for some delay to enable to check update result/log before forcing reboot…

Most updates require a reboot. At least those upgrading kernel, and most of them do it. After such update, the router is rebooted in a few days if you don’t do it earlier yourself.

I personally prefer to do a reboot immediately after updating. And if I want to defer reboot for some time, I’d defer the update with it. I think it’s really difficult to do perfect reboot-less nontrivial updates (including all corner cases), even if kernel isn’t touched.

1 Like

This night, Turris has updated&rebooted. In the morning, the mSATA drive was gone (and the LXC containers were not started, obviously).

The drive is not mounted, /etc/fstab is empty, as is /etc/config/storage.

In reForis, the drive is listed in the Prepare Drives section, the Drive selection section states just There are no prepared drives to be used.

I rebooted manually once more to be sure, nothing changed.

So, what went wrong and what should I do to fix that (not losing the data on the mSATA drive)?

Looks like HDD or filesystem failure. Log in via ssh and look through dmesg and /var/log/messages if you find anything related to btrfs or /dev/sd … If the drive is not mounted, you can also try btrfs scrub to find errors on it.

Is the MOX-Network-Boot UI missing? (I cannot find it …)

OK, solved. I’ve had disabled the NAS package group in reForris prior to the installation (as I didn’t think I needed any of its functionalities). Apparently, this uninstalls many dependencies, including block-mount.

With the package uninstalled, LuCi System menu does not offer Mount Points, and the mSATA disk does not get mounted on boot, apparently.

After reinstalling the NAS package group and rebooting, the drive and LXC containers are back.

3 Likes

I am still blocked on version 6.3.3. I tried to install this update a few minutes ago but, as with the previous one, it broke everything and couldn’t access the dashboard nor SSH to my Mox.

Sharing here for visibility, and if someone had a similar issue in the past.

Background info:

I first had auto-update ON which installed Turris OS 6.4.0 on the 27th Jul, and after a 3 day delays (that I setup), the updated was applied (July 30th).

However, I had no internet connection nor access to reForis at 192.168.1.1.

What I did:

  1. Check ip a on my computer: I noticed there was no inet anymore,
    only inet6, which I found strange.
  2. I used recovery mode 5 (unsecure SSH) to SSH into my Turrix MOX and rollback before update with schnapps
  3. Can now access Internet and reForis at 192.168.1.1

It may have been possible to SSH through IPv6 but honestly no idea how to do that with Turris MOX.

I’ve stopped auto-update for now since then and contacted support who asked me to wait for the next update.

I tried again this morning with 6.4.2 but still the exact same issue.

Other info:

Device CZ.NIC Turris Mox Board
reForis version 1.4.1
Turris OS version 6.3.3
Turris OS branch HBS
Kernel version 5.15.114

Potential cause of issue?

  • I am using ds-lite (which is not supported by reForis). Not sure if that is the cause of the issue
  • I am using experimental packages OpenWrt's process jail and Secure Computing Mode (seccomp)
  • I am also using Morce (experimental, high memory)

Please let me know if there are other diagnostic/troubleshooting I can do to help pin point the issue.

Thank you!

Try manually stopping morce and other memory-intensive apps before installing the update. Make sure via htop you have at least 300 MB free RAM. It can happen that if the RAM is full during the update, something will fail and leave the router in a half-configured state.

All of this is (well) known :wink: I agree with @vcunat and similarly reboot immediately after any update, be it reboot recommended or not, even though configuration of my TO and MOX is very simple…
I just suggested that reboot could be optionally included in update procedure… to be on safe side.

Thanks for your advice. This seems to have been the culprit of the issue!
Morce and AdBlock were using too much RAM.

After disabling them and making sure I had more than 300MB of free RAM, I was able to do the update smoothly!

Too bad there is not a check in place to verify there is enough RAM.

Thank you again!

Yes, I think all the “High memory” apps installed via Reforis should be automatically stopped before update and started after it. These low memory issues have hit a lot of people and generate bug reports where there is actually no bug with the update itself. @miska is this somewhere on the roadmap?

As a workaround, you can do it yourself, for example:

# cat /etc/updater/hook_preupdate/01_tor.sh 
#!/bin/sh
/etc/init.d/tor stop

And add a similar postupdate hook if you want to start the service again.

2 Likes