Mdadm package seriously outdated!

@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.

1 Like

That rather says it all of what not to expect. Thanks a bunch!:anguished: :cold_sweat:

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 :cold_sweat: 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.

BTW, i got my package from hereā€¦https://downloads.openwrt.org/snapshots/packages/x86_64/packages/

Another edit: The first url is for the packages itself, the Luci packages (web-interface-confguration) go here: https://downloads.openwrt.org/snapshots/packages/x86_64/luci/

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? :confused:
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 * :joy:

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.

Online? Like providing servers? I donā€™t know about any project doing something like that for their contributors.
But bootstrapping build environment is easy enough if you have Linux machine. Either use Vagrant or Docker. In case of docker you donā€™t even have to compile it, itā€™s already compiled on docker hub (kind of older version but I am working on updating that). If you donā€™t have Linux machine then I would suggest using some vps for short amount of time (for example DO bills by minute if I remember correctly).

Tricky part is how OpenWRT is developed with feeds. So you can either get all new packages or none. Or you have to backport individual packages. Trouble is that if you pull a new packages feed, plenty of packages will no longer work. That is the reason we are trying to focus on rebasing on newer OpenWRT release that will hopefully come soon and with new release model OpenWRT is adopting it will hopefully work better in the future. The best way would be to improve OpenWRT build system to support multiple versions of packages and track what builds where like OpenEmbedded does, but that would be tremendous amount of work. So we have high hopes for 4.0 - based on to be released OpenWRT and we will see how it will work.

Plan we shared somewhere was this year. There is high degree of uncertainty on how migration will work out and what will break and also not yet well known pile of MOX work.

2 Likes

mdadm was updated to version 4.0 in Turris OS 3.11.

1 Like