OpenWRT started to fork 19.07 from Master

Seems the new release is in the making as upstream apparently started to fork the upcoming 19.07 from master, now showing 19.07 as new/own branch in;a=summary

Wondering whether/how that will be reflected in TOS work flow of HBD/HBK branches?

Shall we first try and release tos4?

It will be in time, I was just wondering whether a new branch might be introduced

  • HBD -> Master (TOS6.x)
  • HB? -> 19.07 (TOS5.x)
  • HDK -> 18.06 (TOS4.x)

Or perhaps HBD staying with 19.07 instead and upstream Master not being tracked for the time being

First, we would like to release a final version of Turris OS 4.0 as currently it is:

  • HBD - OpenWrt master
  • HB{K, T, S} - OpenWrt 18.06.

Branch-off was not announced on mailing list (openwrt-devel nor openwrt-adm). We noticed that, discussed it yesterday. You can see:

Unfortunately for some time we won’t build OpenWrt master. The next build of HBD will be based on OpenWrt 19.07. If there is any change, we will tell you.


Since yesterday, we are again building master branch of OpenWrt. In it’s specific branch ‘master’.

1 Like

latest chatter points to a release of 19.07 beginning of September, or thereabouts


Looks like upstream finally got around to release 19.07. Upstream feed changes were committed today and upstream buildbot cycle is expected to complete tomorrow.

Finally they made it, better late than never… :clap: :fireworks:


Hot on its heels 19.07.1

1 Like

Whilst upstream already pushed the second service release for the19.07 branch - - there is no not even a TOS5.x beta available - that is 2 month after the initial release of 19.07!

Great going TO! :+1: Just keep on doing more TOS3.x releases and fixing stuff there.

Thanks. We appreciated your feedback. There will be an announcement soon as I said in this thread:

It is in the process. I should’ve written it yesterday, but I didn’t get to it. What I can promise is that I will do the thread tomorrow. Is that OK with you? OpenWrt 18.06 is still supported. We can not release something, which is broken and if some things are broken there. In the meantime for advanced users, there is a branch HBL, where you can try OpenWrt 19.07.

I understand that you are offensive, but after one month, which is a quite long period, there’s going to be released one Turris OS 3.x release. All of our work is open-source. You can check what we are working on. Any pull requests are welcome.

What exactly is broken - OpenWrt 19.07, is it now?
If it TOS that is broken then we are back to CZ resources and how the resources are devoted.

Development probably would still be working on TOS4.x if it was not for a particular bug.

I do appreciate that you take offence though stating obvious facts is hardly offensive.

It does not matter - anything for that obsolete TOS3.x diverts resource from going forward. There is no point in pouring effort into that branch - unless of course a TOS5.x release cannot be delivered any time soon - say within the next two weeks - and instead will take many more months and thus requires TOS3.x still being actively maintained.

That is fine - apparently the TOS development is mostly struggling with its own patches that are being applied on top of OpenWrt and causing the delay.

Sorry, you post above that came over quite passive-aggressive, and IMHO that is uncalled for.

??? Given that TOS3 users are not yet automatically upgraded to to TOS>3, it seems prudent and in line with the promise of automatic updates to keep pushing updates for TOS3 until the moment it is retired for good. Also, I consider it team turris’s prerogative to decide how to allocate their resources. Sure things could be faster, but the same critique applies to upstream OpenWrt as well.

Well, and with attempting and doing things stock OpenWrt does not do at all (btrfs, automatic updates with maintaining configuration, …) it is no wonder that integrating these things into OpenWrt will cause issues that require time to solve…
I understand you impatience, I really do, but I am not sure whether your current approach is helping either in making things faster or the mood of all involved better.

1 Like

I have to confirm that BTRFS in master does not boot, of course you can compile kernel module and you are able to mount BTRFS partitions but I was unable to find the way how to boot root filesystem on my x86 and wanted to ask turris team about it what is needed to make openwrt boot from BTRFS root on x86 but probably it would be unanswered anyway. And yes never seen anything that painful as updates in master. From community forum I realized it is not supported in openwrt at all the way turris team developed updater and I guess it would be very lovely to have this feature in master on x86. You have to literallly make new flash or dd fresh image and then run hundreads of opkgs and then reconfigure config files by hand.

TOS4+.x been worked on for more than a year (by now approx. 14 months - how long can it take - years?) and the automatic migration script is still far from being complete and it may never will be. Classic Catch22.

And it is not just the migration script but other TOS stuff (that is non-essential for the router functionality) too, e.g. (re)Foris, sentintel, etc…

Some of it could have been contributed to upstream, such as btrfs and multiple CPU/Switch port linking, least for latter the developers are too busy trying to sort MOX .

Those are not being up-streamed to OpenWrt and as said the TOS development is at it since 14 months…

The issue is that the vendor clearly lacks the necessary resources for timely development.

I see no catch22, really, as long as automatic upgrade still seems feasible it just takes as long as it takes, and until the upgrade either works as intended or is officially is given up I consider updates for TOS3 the right thing to do.


Some of them are not palatable to upstream OpenWrt at all, but still have value for TOS; upstreaming is great, but is not a panacea to all problems…

Which vendor does a better job? IMHO the turris effort is doing very well, sure there is room for improvements, but overall they are pretty much delivering on the core of their promises from the kick-starter, as far as I am concerned. But hey, if an occasional call to action like yours speeds up development, I will not complain, but I really do not see a project in disarray here, as you seem to do.


Sure, if you are content that it takes years. And

that development resources are being wasted on some obsolete code that has long since reached EoL.

Quite a number, just an example amongst them

Your (happy go happy) perspective is appreciated/respected but perhaps not shared by every one else

Not sure which kick-starter core promise you are referring to, to deliver a routing device into production?

Do you know what EOL means? Because TOS3 is still in the field and is being actively updated, not the typical signs of an end of life product… My point is not that I disagree that TOS3 should probably retired ASAP, but just that we have different opinions on what “as possible” means in this context.

Well, if you believe synology to be the right thing to run on your router… But it is clear I was imprecise, which router vendor in the consumer space that the turris project targets has an equal or better track record in long-term support of deployed devices?

Fair enough, it still seems valid to juxtapose your unhappy go unhappy perspective though.

(Continuous) automatic updates. For me, that was and is the big one, and the one the Turris team IMHO consistently delivers. Sure, I can and do build bespoke OpenWrt images for my other router, but I prefer not having to do so, especially for devices for friends and family.
Now, I am not claiming that this is the only promise from the campaign, and I have no real opinion on how well these other promises have been met; but I think or the update side (and the increased closeness to stock OpenWrt) the turris team should be applauded.

P.S.: I am not looking to get into a fight with you. I just do not agree with your quite negative view of the performance of team turris, and wanted to give a bit of a counter point, to balance the criticism.

1 Like

Do you know which LEDE branch TOS3.x is based on? Which has reached EoL a long time ago. That is nonetheless being maintained as TOS3.x just makes a case in point - waste of resources.

Again, there are quite a number of those that provide frequent updates. If Synology does not fall within “the consumer space that the turris project targets turris project target” then which one does? Thus far you have produced a blanket statement implying that no other vendor does a better job.

Let us try with AVM then - or that does not fit because they likely have a suitable amount of resources?

Big deal to deliver automatic updates for obsolete code (TOS3.x).

  • TOS3.x is nowhere close to OpenWrt
  • TOS4.x has been abandoned (thankfully) and is anyway based on a legacy OpenWrt branch
  • TOS5.x (based on current OpenWrt stable) is not even in beta

Sure that should be :clap:

There is no negative view - merely stating the obvious facts of the performance. Sure that is not to everyone’s liking but why sugar-coating it?