We just release Turris OS 6.5.2 into RC! It wouldn’t be there for too long. Changelog is as follows:
New Features
• updater: Staged rollouts in stable branch - updates are rolled out over the longer time period
Breaking Changes
• Dropped Netmetr package list as service is no longer operational
Bug Fixes
• foris-controller: Fix Interfaces tab when LTE is being used
If everything goes well, this will be the last release before Turris OS 7.0. That is why we are enabling staged updates. Those will start working in hbs only, so no testing in testing branches. But Turris OS 7.0 will be rolled out in stages, every day only part of the routers will get updated. And as mentioned multiple times, Turris OS 7.0 is only about migration to newer OpenWrt, no other changes, that is why we released Turris OS 6.5 - to get all the features out of the way of big release.
As there are minimal changes that can be tested in testing branch, we don’t expect any issues, but if you encounter anything, please let us know.
6.5.1 → 6.5.2 RC1 update ok, no unintended cable/wifi or internet downtime. Restart not needed.
Turris Omnia 2017, 1 GB RAM, dead eMMC, system running from mSATA SSD, original wifi cards, UBoot 2022.10. Storage plugin enabled, LXC containers, tor relay, USB HDD shared over samba4 and minidlna, SQM, Hardwario gateway + MQTT IoT bridge, OpenVPN, PPtP VPN, Strongswan IKEv2 VPN, morce.
Long-term, I have a problem with the handling of Reforis after updates. One would expect that when I trigger the update via Reforis, that I’ll see a notification about the update being done in Reforis. However, that doesn’t happen as reforis is always taken down as a part of the update and is not autostarted when the update finishes. That means I need to manually refresh the page, which takes me to the login screen (I think), but more importantly, which also takes reforis from its deep sleep again.
I think updater should check whether reforis was running at the beginning of the update and return it to this state after the update.
I understand your concerns, Viktor. However, upstream being EOL says nothing about downstream being EOL. Take the example of Python 2.7 which was EOL’d around 2020, while still being part of Ubuntu 18.04 which got free support until 2023, and has ESM support until 2028. So you can say Python 2.7 is EOL, but at the same time, find a security-maintained version of it out in the wild…
Big jumps means higher chance that something breaks. With 7.0 out of the way, we will off-course focus on Turris OS 8.0, but that will be again a lot of work, so it will take some time…
I don’t know current state of TOS 7. But still could be delayed more to release TOS 8 if not a big difference and impact between OpenWrt 22 and 23. This is just an idea of course.
This time it is better without a Kernel update. Flash will wear less.
I wouldn’t suggest to update the kernel often unless there is a reason and important security fix.
I fully agree with that, but in the past the Turris team capacity has proven insufficient. Of course I don’t mean releasing new versions of the kernel.
When TOS 6 came out, you repeatedly claimed that the changes to the new OpenWrt were not that fundamental, TOS 7 was coming soon and it’s been going on ever since. The changes to the current OpenWrt are even smaller. How long will it take, a year?
TOS 7 is currently well tested and polished including hopefully smooth migration. TOS 8 is currently in unknown state, so it will take at least few months to get it into releasable shape
So, while I would appreciate a somewhat faster cadence, I think going step by step is the right way forward… the next big thing IMHO will be to transition from iptables to nftables. Is that planned for TOS7 or is that something for TOS8?
New Features
Breaking Changes
Bug Fixes
