Turris OS 5.2.6 is now in the Testing branch

Community office Testing branches
, , , ,
#1

Dear Turris users,

I want to welcome on our board a new member of the Turris team, who joined us to help with us and improve Turris OS distribution, which is using OpenWrt.

Welcome @mvasilek! :clap:
I am proud to let you know that he prepared a new Turris OS 5.2.6, which we released to the Testing branch just now. Most of his work was upstreamed to OpenWrt. :+1:

Some of you noticed recently found vulnerabilities in some packages and libraries like OpenSSL, mc and others. We need to keep you safe, so here it is! :wink:

What’s waiting for you in Turris OS 5.2.6 released to the Testing?

  • Security updates related to OpenSSL, tar, file, apr, mc
  • OpenWrt community fixed issue with https-dns-proxy, which was missing in the previous Turris OS 5.2.5 release.
  • Updated kernel and nextdns

How can I opt-in to the Testing branch?

Follow this article in our documentation.

How can I report any regressions?

Don’t hesistate and reach our support department as soon as possible!

As always, thank you for staying with us, and we appreciate any feedback regarding what we are doing.

Don’t forget to share any pictures of your custom Turris Omnia 3D models, wall mounts, etc., in this thread to win a T-shirt!

8 Likes
Turris OS 5.2.6 is released out!
#4
#5

Hello,
Nice to read that the Turris OS team is expanding and also contributing upstream :slightly_smiling_face:
A bit less nice is the fact that automatic reboot of my MOX due to updates (scheduled at 3am in my case) ends up with a MOX turned off the following morning, forcing manual hard restart.
I am preparing a server for self-hosting but I am getting worried of the MOX getting stuck. What if I was away from home? It happened many times, and recently with 5.2.5 and 5.2.6. Any fix?
Thanks

#6

Hi,
The same problem. MOX A+C+PoE (unused), software reboot for upgrade application will stop, need power cycle, next boot OK with new version. Independently software reboot works fine, but not for use to upgrade.

#7

Hello @cocturr , we are aware of this issue and our developers are in contact with the SoC vendor to resolve this, however we have some experimental workaround addressing this issue.
You can get the workaround here → Hang After Reboot Issue Solution v3

4 Likes
#8

Ah OK I was not aware, thank you for the info.
How likely could the flashing operation fail? I suppose the UART cable to de-brick the MOX in that instance would be something like that?
USB-UART 1.8V cable eBay

#9

Yes, that cable might be usable (depends if it uses counterfeit PL2303 or genuine PL2303) anyway the update is smooth and the only risk is the power supply outage, so don’t do the upgrade during storm…

You can also use the 3V3 cable used for Raspberry Pi, but only as a last resort. It is not recommended but the device will withstand it. Anyway, it might break your warranty in case something strange happens.

2 Likes
#10

Nice, finally an update without a spurious reboot of my Omnia … :slight_smile:

1 Like
#11

hi there. This nOOb just installed that ‘reboot firmware’ on my standard MOX. Had to manual hard reboot it afterwards ( while sweating , hoping not to go for the usb cable defilibrator option) and all went smooth. Had to reboot it 2 time more, since it was a bit slow and sloppy in luci…

so if this nOOb can do that, everyone can :slight_smile: Good luck!

1 Like
#12

:laughing: OK thanks for encouraging feedback!

1 Like
#13

Hi,
How do I view the U-Boot version on Mox?

#14

There is several ways how to get the U-Boot version.

  • using the serial console, breaking the bootloader and typing the command ‘version’
  • somewhat hackish, but can be done without serial cable in running system: cat /dev/mtd1 | grep U-Boot which should produce output like this
root@lab-mox-asbwc:~# cat /dev/mtd1 | grep U-Boot
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
U-Boot 2018.11 (Dec 16 2018 - 12:50:19 +0000)
** Invalid partition type "%.32s" (expect "U-Boot")
Cannot find PCIe node in U-Boot's device tree!
U-Boot.armv8
No valid device tree binary found - please append one to U-Boot binary, use u-boot-dtb.bin or define CONFIG_OF_EMBED. For sandbox, use -d <file.dtb>
U-Boot

or

root@lab-mox-aec:~# cat /dev/mtd1 | grep U-Boot
** Invalid partition type "%.32s" (expect "U-Boot")
Cannot find PCIe node in U-Boot's device tree!
Cannot %s PCIe in U-Boot's device tree!
Cannot fix PCIe regions in U-Boot's device tree!
Device "%s" not supported by U-Boot image
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
U-Boot.armv8
Burning U-Boot image "%s" from "%s" to "%s"
No valid device tree binary found - please append one to U-Boot binary, use u-boot-dtb.bin or define CONFIG_OF_EMBED. For sandbox, use -d <file.dtb>
U-Boot
U-Boot 2021.01-00012-g0e5db52d8f (Apr 09 2021 - 15:07:49 +0200)
1 Like
#15
#16

ok, just remote rebooted the MOX after the 5.2.6 update…, locked. needs a local hard reboot.
So that FW workaround does not work as advertised :slight_smile:

#17

Hi folks,
our developers have created a new version of the reboot issue workaround that looks promising to finally solve the issue.
Anyone interested can download the update here → reboot-issue-workaround-v4 · Turris / MOX boot-builder · GitLab

Please let us know if it helped or not; we have tested it on several boards but we would love to receive as much feedback as possible.

Cheers!

Turris OS 5.3 is released!
#18

Hi,
after upgrade U-Boot to version “U-Boot 2021.10-rc3-00050-g7d3fea2c7f (Sep 07 2021 - 18:16:56 +0200)”, subsequent reboot was KO. Necessary power cycle. The following reboots are correct. I will wait for next automatic update to OS 5.2.7 and subsequent reboot.

1 Like
#19

Dowload OK, checksums OK, flashing secure-firmvare OK, flashing a53-firmware - error (command was copied/pasted into CLI):

root@MOXjp:~# mtd write a53-firmware.bin a53-firmware || mtd write a53-firmware.bin u-boot
Could not open mtd device: a53-firmware
Can’t open device for writing!

New versin of U-Boot probably OK - message:

Unlocking u-boot …
Writing from a53-firmware.bin to u-boot …

Reboot after flashing hangs, after power off/on next 3 manual power off/on OK, as well as next 3 sw reboots from CLI.
Hoping this 4th version of experimental firmware solved MOX reboot problem at last. Keeping fingers crossed :wink:

1 Like
Turris OS 5.3 is released!
Reboot doesn't work
#20

Nice. I will test as well, thanks.