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!
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.
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!
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.
Hello,
Nice to read that the Turris OS team is expanding and also contributing upstream
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
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.
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
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
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.
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 Good luck!
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)
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.
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
OK thanks for encouraging feedback!