Turris Omnia - rtrom01 Turris OS 3.9.6 Kernel 4.4.119-082ea0f4a4e204b99821bedcb349ed54-0 Firmware OpenWrt omnia 15.05 r47055 / LuCI 49c3edd5861fd032fa8379ceda525c27a908a114 branch (git-17.212.24321-49c3edd) mdadm 3.2.5-2
Whilst been able to create the raid array it got lost after reboot and it took a while to figure out that the TO version is lacking mdadm.config and mdadm.init, which were added in the upstream repo already 2.5 years ago!
Unfortunately that is not the first package being outdated and it is upsetting having to spend time on researching and in the end having to beg for packages to be updated, even such basic one as this disk tool. Notwithstanding being told that TO has other priorities.
If it were clear prior to procuring the router that the TO package housekeeping was such a mess I definitely would have refrained from procuring it.
Hello,
would you be so kind to stop it? We hear your feedback, but there is no reason to create every day each thread. Unfortunately, things do not change with a fingertip, but we’re working on it.
Unfortunately that is not the first package being outdated and it is upsetting having to spend time on researching and in the end having to beg for packages to be updated
We told you that current state is just temporary. We know that our fork is unmaintainable in long run.
Please see again our reply to you in one of your threads, which you created.
Right now we have only two people maintaining few thousand packages, but for advanced users, we want to provide know how to update to Turris OS 4.0 hopefully during Q3 2018.
Anyway I’ll pass the request to update mdadm and dropbear to our developers, which they’ll decide, when we’ll update it.
EDIT:
Dropbear: We provide full-featured openSSH, so it doesn’t have priority and will be updated in Turris OS 4.0.
mdadm: any progress on this package will be in Gitlab. I don’t want to promise anything, but it’s possible that we’ll update it sooner.
Bon chance to those eying the MOX…
Turris MOX will run Turris OS 4.0, which is based on OpenWRT 18.5, which means that it’s upstream OpenWRT with few patches and our packages. So all packages (except those added on top of OpenWRT) are maintained by upstream.
Here you can find screenshot for kernel version and here is mailing list, where you can find patches for U-boot, which adds Mox support.
@pepe it has been decided by TO to set up the repo as it currently is, apparently not fitted to provide proper package housekeeping (2 people for a few thousand packages) with the user bearing the brunt of it.
And yes it was discussed in the other thread and yet there is no solution other than some vague outlook for TO OS v4, which at best is still months away.
How do you reckon to cope in the meantime, like you suggested to suffer it quitely (stop it) then whilst being at the mercy of your developers’ whim of whether/when to update a package along with the old referal to other priorties, like you just did for dropbear Dropbear seriously outdated
Dropbear can be hooked into initramfs and starts at boot time prior partitions get mounted. OpenSSH does not seem to be capabale of it but then that is not important to you as you made the call and also closed the thread.
On the other hand you decide that the ancient version of https_dns_proxy Turris OS 3.10 is now in RC! is worth to be updated earlier… leaving the descion making process shrouded in mystery (on a whim).
But perhaps you deem this all really user friendly, me on the receiving end is not.
@Pepe After having read your edits I am not sure you understand how frustrating it is having to beg constantly for package updates and then being repeatedly rebuffed with other priorities (e.g. MOX) and non-committal statements (no promises).
And packages that far outdated and that numerous can hardly be considered a temporary state.
Sure enough I would kindly stop listing outdated packages if there were none or barely any, this is simply cause and effect. Certainly I would like to spend my time more productive and enjoying the router in its full glory, than chasing and researching those packages and getting weary along the way.
The router has great potential which can only flourish if the fuel (software) does not stutter its engine, which it does however till date.
Till now there is no roadmap about development leaving once more the non-commital residue.
I believe both sides get frustrated unless they expend effort to avoid it. I’m not on the Turris team, but I also understand the frustration of a long-term state when your todo/wish-list is all the time getting inflow that’s double of what you can realistically catch to do, especially if there are repeated requests from people.
As @vcunat wrote it’s frustrating for both sides. We have limited resources (because there is no such thing as unlimited ones) and we have to commit them to something. Either we will go trough every single package we currently have and update it or we will work on 4.0. Now question is: do you want have some of the current packages updated but 4.0 next year or do you want to have all packages updated with 4.0 but live for some time with older versions. Please see our reasoning. More time we spend on updating current packages we are not spending on getting 4.0 up and ready.
Also we accept patches. If you want to have some package updated and it’s not our priority then you can update it on your own and send us a patch for it. We have documentation on how to build Turris OS 3.x.
You understand that one of those “rewrites” is Turris OS 4.0, don’t you? And also that I said that we will talk about creating roadmap? I would rather say that it’s something you can expect. I am missing what are you sad about.
The is about a roadmap lacking commitment to a timeframe (not even talking about a progress meter transparently on display to the user base)
What does it help to know from a roadmap that something is in the pipeline when it may take 1 month, 1 year or even 10 years to actually happen, or even never? I for one want to know whether it is worth hanging onto the TO for little longer or better selling it now.
@anon50890781, Again also my response to you. We have to put things in perspective. This whole mess was not because of NIC.CZ. The fault lies with the breakup of Openwrt and LEDE. They FINALLY merged back with each other under Openwrt and FINALLY just i believe within the last 4 months they merged things, from forum to everything.
So now we as users of the Turris Omnia, we cannot expect the Omnia Team to change things within even a month. You have to think about the excessive testing, or else we will be left with a broken Turris OS. Remember i am not defending the Omnia team, but just looking from a objective perspective and see who is at fault.
For now try to install things manually if possible. Just last night i discovered for example that mwan3 (multiwan package) was already on version 2.6.14. I grabbed that package from the latest openWRT snapshot and everything works great.
How do you reckon the OpenWRT/LEDE matter is factoring into TO’s package housekeeping?
On one hand you cite excessive testing and the next minute you are just grabbing something from the OpenWRT repo. No concern that it may break TO, like you said?
Did you provide a patch of said package to the TO repo like it been suggested by @cynerd?
It all might be bit easier (to help with patching) if there was a list of packages being altered by TO, e.g. unbound, compared to those from the OpenWRT repo. But try as might I could not trace one. Which leads to the next issue of lack of documentation, that is including for packages being altered in downstream.
Things don’t break that easily when we talk about SOME packages. Mwan3 for example, is a side package. But there are packages that are part OF THE CORE of the OS itself. What if for example the wifi-driver-package would not work correctly…just saying. Well majority would complain of the Atheros wifi-cards not working anymore. Even other packages that are more necessary if those do not work, well that would mess up the OS itself very good. So why i took the mwan3 package is if it didn’t work correctly, i would just have given a
opkg remove mwan3
and then reinstall version of the old repository to get back to it. Why i grabbed that later version, was because of many bugs and annoyance in the old version. LXC package for example is already on 2.1.1 in the snapshot, but i just don’t mess with it, until Turris OS 4.0 is released. Because right now, LXC does what it does and i experience no problems with it.
And believe me, i don’t count myself as a advanced used whatsoever. One can google, one can read, one is ready to invest some time instead of looking at cat-videos on facebook (just saying in general)…well you have a made yourself a valuable person.
About the suggestion, well to be honest, just LAST night i discovered it and i installed it. And right NOW i installed the luci package. So haven’t had the time to really test or give it some time to see if things do work correctly.
If you have any problems, many of us would be more than happy to help a fellow-Turris-Omnia-User.
Like I said, if there was list of packages been tailored to/for the downstream TO it would be much easier of a risk assessment to work on patches, or try your way of trial and error (though I would rather use schnapps than opkg for the rollback purpose).
Currently wouldn’t it be MORE wise to focus mostly on Turris OS 4.0 and on the side to update some packages if some users experience problems.
For example, LXC is still on version 1.1.5, i have addressed this issues a couple of times (before knowing of Turris OS 4.0), but after those bugs in LuCi were fixed things have been kept as it is. It is more wise to have a stable LXC package for now, until Turris OS 4.0 is released where everything is merged don’t you agree?
Some have same packages, some have different packages as the situation of every one of us is different. If i see some other Omnia user complain also about the mwan3 package, i would surely help them with it.
So i think we would help the Omnia team if we would leave them alone right now. If by december 2018 Turris OS 4.0 is not released with very weak arguments, i say unleash your dog and let your dog bite them in their… *PIEP *
It is not about unleashing dogs or LXC, it is about utilizing the device’s capabilities. And I am not sure how you are able to pin December 2018 as a deadline when the TO team is shy of any time table commitment.
Well i follow logic and logic tells me that the amount of hours spend most probably have been or SHOULD have been used properly to meet the deadline of at least December 2018. Of course knowing testing is always a mess, but still i say that deadline must have been met by then. If they do not have merged by then, for sure it will become even MORE difficult each day that has gone by, as openWRT also doesn’t stand still. About features, in the times we are living, routing and routers have become more important, security is changing, people host more stuff at home because of having higher upload speeds, new ways of WiFI functionality is being introduced because of over-crowding and you fill out the rest.
A bit like whole ownCloud & NextCloud. When the fork happened users were shown tutorials how to make the migration to Nextcloud. However the longer the user waited, the more complicated it becomes as differences in functionality between nextcloud and owncloud became bigger by each new major version. If i can remember correctly it was back with version 8 or 9. Nextcloud is now on version 13.
However i am not aware of how many are working on the Turris 4.0 development, as i read that right now it looks like their focus is on that MOX product of theirs. However with that the MOX being shipped with Turris 4.0. Anyways, give some suggestions, but we must have some patience with this all.
So what is your suggestion if you were to setup a raid array mounted at boot not in December 2018 but today and the relevant TO package not doing the trick since being outdated (ancient 6 years), other than your trial and error approach with OpenWRT repo packages?
This is like tying my hands and feet and forbid me to jump or crawl or roll, but tell me to go from point 1 to point b without any help.
My suggestion would obviously be, look at packages that are in the latest openWRT snapshot or a bit older and test with them. Because right now as it seems, is rather a issue of lack of functionality in the older packages. Although RAID is a very risky thing to do as it gives no guarantee if it would work correctly (losing your data…). But again taking things in to perspective, it is your choice of wanting to have it like this. One could have known that the packages would be outdated, (although i must agree 6 years is ancient) as many packages are created by individuals in the community. In my own case i have build my own NAS with RAID6 and having Ubuntu running on it. Every 2 years i migrate to a newer LTS version, all because i have taken that factor of outdated packages also in the choice making.
Now you mentioned it, i believe @Manul was having the same issue. He fixed it by auto-mounting it at boot using rc.local if i am correct as the functionality was missing in the current package. Have you read that topic?
@vcunat I am not launching repeated requests for the same package to be updated. But certainly others may want that package upated too, if you consider that an iteration of sorts.
Whilst not certain but you may refer (todo/wish-list) to actual development work and I can appareciate that being badgered with feature requests can be tiresome.
Yet here we are talking about housekeeping of the packages (a different scope) from the upstream repo and not developing a package. That is for packages not tailored to TO, which likely is the vast bulk.
How this can be frustrating for the housekeeping party is beyond my grasp actually. Or you mean the user bothering with an update request is frustrating?
If TO was to provide the development environment (Vagrant) online, e.g. like the demo, I would eventually consider contributing my time into producing patches.
leaving the descion making process shrouded in mystery (on a whim).
