Turris OS 5.0.4 is now in HBT (Testing branch)

Dear Turris users,

We would like to inform you that in the HBT (Testing) branch, you can find a new Turris OS 5.0.4. In this version, you can find improved support for multi SSID if you were using an SDIO Wi-Fi card with your Turris MOX. It means that guest Wi-Fi should work on the SDIO WI-Fi card more reliably. There are also security updates for golang, libvorbisec and updates for golang. While at it, we looked at the same issues, which were reported to us like zerotier and squid which were not working and, in some cases, they segfaulted at start.

As usual, we appreciate any feedback regarding this release.

2 Likes

MOX restart succeeded.

I just clicked the “update” button from a remote location. Now I received an email from the router saying

"The system was updated, but some changes will take effect only after reboot. Please reboot the device.

The device will be restarted automatically on Thursday, July 30 at 08:00 PM."

However, my MOX is one of the devices that gets stalled when it is rebooted.

So I fear this means, in 10 days from now, my router will shut down and not come up again? Given I’m >250km away from it, that would be very annoying!

Is there a way how I can inhibt this automatic reboot in 10 days from now and to make it happen only once somebody can unplug/plug the power plug? I was unable to identify which script/program is responsible for triggering the reboot, would that be the foris-controler?

We are releasing another RC of Turris OS 5.0.4. There are security fixes for Python 3, updated squid (huge update) and msmtp (adds undisclosed_recipients). For the Turris 1.x routers (the blue one which was given to the people in the Czech Republic as part of security research running on PowerPC CPU) there are a few missing packages:

1 Like

@dg1sek In general it is not good idea to poke in internals unless you really know what you are doing (know program and script you are tampering with) just for consideration and as warning before I answer you.
Saying that reboots are scheduled as part of notification system (by notifier script) and process triggering this reboot is atd. You can list all scheduled tasks by running at -l. In general there should be only reboot tasks but either way you can recognize reboot tasks because of reboot time. To remove task you can do at -r NUM where NUM is job number (that is number in first column of at -l output). I hope this helps.

2 Likes

And there is released Turris OS 5.0.4 RC3!
Most notable changes is that those packages, which were fixing for Turris 1.x routers are back.

Thank you!
That helped me a lot and saved me from an unwanted stalled router!

root@raspberrypi4:~# ssh 10.8.0.2 -l root
root@10.8.0.2's password: 

BusyBox v1.30.1 () built-in shell (ash)

      ______                _         ____  _____
     /_  __/_  ____________(_)____   / __ \/ ___/
      / / / / / / ___/ ___/ / ___/  / / / /\__ 
     / / / /_/ / /  / /  / (__  )  / /_/ /___/ / 
    /_/  \__,_/_/  /_/  /_/____/   \____//____/  
                                             
 -----------------------------------------------------
 TurrisOS 5.0.4, Turris Mox
 -----------------------------------------------------
root@turris:~# at -l
14	Thu Jul 30 20:00:00 2020 a root
root@turris:~# at -r 14
root@turris:~# at -l
root@turris:~#

MOX classic, simple config, WiFi - after RC3 lost both WiFi :frowning: fortunately schnapps rollback returned config to previous working state.
NB had simillar problem with 3.11.18 RC of TO, where fortunately reboot helped to recover lost 5GB WiFi :wink:

Between RC3 and RC4, there are just changes in packages and openwisp feeds.
We were using these commits in RC3:

  • feeds/openwisp: a5f5fd020bea524c9e68cab4ff0f413fe8a9b2bc
  • feeds/packages: e798f539c9c89a8e2e0b43720246e3deec45fc26

And this one in RC4:

  • feeds/openwisp: 70371fc0b306a89a6627ded0554ce0fb7aaae52e
  • feeds/packages: f29fdc7c24a9d0593447169856f94c60234b2a91

Most noticeable changes were related to zstd, mpd, mpd and liblz4. These packages do not affect Wi-Fi, so I am more curious about what means “lost both Wi-Fi”. Were they detected by the hardware/software? Could you see something related in messages? Hostapd was running?

Hello,

I have the following problem with my blue Turris.

When I upgrade from OS 3.11.17 to 5.0.x, everything seems to be fine, with one exception. The following warning is displayed during the update: "Updater failed: Called uri_path on URI of scheme: https "

I’m on the new OS now. However, if I change anything requiring a network restart (eg. a change in the WiFi section), the router will freeze during this network restart and stop all communication. There is no chance of accessing the Internet, Putty will not connect to the Turris, a restart will not help. Only Factory Settings and return to 3.11.17. helps …

Any idea, what to do?

Thank you

Hi,

We already know that. It is mentioned here:

and here

You will need until we release 5.0.4 into the Stable branch and then you can try migration once again.

5 posts were split to a new topic: Future 5.1 release discussion

Sending diagnostics with part of syslog to support. Was not able to find why WiFi did not work (mainly not knowing what to look for). Best luck!
Moreover, I forgot to mention that my MOX after reboot or powering off/on most often do not come to life, I have to repeat the sequence more times.

After an unsuccessful attempt to upgrade to 5.03, I performed a factory reset of the router.

Now I have another problem I haven’t seen before. Step 6 of the initial configuration (update) fails with the note

“Updater selhal: Chybí CRL, pravděpodobně je problém v připojení k internetu.”

Internet is working properly - the “Connection test” in the DNS section shows 6x OK.


One hour later … another problem …

“Updater selhal:
unreachable: https://api.turris.cz/updater-defs/3.8.5/turris/base.lua: Operation timed out after 30014 milliseconds with 0 out of 0 bytes received”

Thank you.


Funny, when I turned off IP6 protocol in Foris, everything started working.
With IP6 on I was even unable to perform the command opkg update in the putty