what’s the roadmap for TurrisOS 4?
what’s the roadmap for TurrisOS 4?
afaik it’s mainly upgrade to openwrt 18.06 keeping the Turris omnia specific patches like btrfs and kresd.
Guys, how is TurrisOS 4 going? It’s already march 2019.
Using TurrisOS 3.x, brings a lot of problems with it as most of the packages are outdated compared with OpenWRT. From DNS problems still not being fixed, to Mwan, now today experienced LXC failure. LXC not working is almost taking part of the heart out of the Omnia in my case.
You can try TO 4.0 already: https://forum.turris.cz/t/turris-os-4-0-alpha2-is-out
You can expect automatic migration this year I hope but no promises. It might be harder then it looks. Until then you have to do manual migration.
What do you mean? some extra chars
Well i still had the problem that DNS did not work. I manually added the repot of turris to the host file. However, i am trying to upgrade to TOS 4, so i guess no going back anymore to test things as i already wiped everything (backupped the config files).
However no somehow 4 LEDS don’t go in to the reflash mode.
today experienced LXC failure. LXC not working is almost taking part of the heart out of the Omnia in my case.
Could you tell me more details about it, please? So I can look at it.
Well i tried to put OpenWRT image on it, so i wiped everything, however the error that i got then, was a
clock.c lx clock 231 error opening
It was out of the blue. I just recently upgraded my NAS to 30 TB, so was copying some files to my NAS from the mSATA SSD in the Omnia, but suddenly LXC just crashed. Could not start the LXC, as i got that message. The mSATA SSD is just fine as it was mounted and i could browse everything using the terminal.
Now i “bricked” my Omnia, because i tried to flash to openWRT 18.06.2. On the forum people said to remove openwrt settings, to get the re-flash working again. However, i will hopefully try to do that the coming week.
About clock.c: There was just this row and nothing else? Which GNU/Linux distribution did you have in the container?
I see you were also interested in Turris OS 4.0. In alpha 2 thread you posted your comment and now I’m not sure if you flashed medkit, which we have provided or you wanted to try/have “pure” OpenWrt 18.06.02? Wouldn’t you mind if I ask you why did you choose OpenWrt instead of our Turris OS?
If you decided to flash OpenWrt, I hope you have UART cable. If you do, you need to proceed these two commands in the serial console:
env default -a saveenv
Yeah, i just got that row and it said it failed to start it. I had Linux Ubuntu 18.04 on it.
Well i used a medkit, which one, i am not sure anymore. As i THOUGHT all of those medkits were the same, but different versions. Maybe you guys should put extra information in the name of the medkits. I can mostly take care of things, when i mess things up, but just for people who have absolutely no Linux or technical background. For them they see a dragon that they have to take down with their bare hands.
I THINK i used this one.
Well i did not really wanted to test the “pure”-openWRT, but i felt like cornered, of DNS not working properly, then Mwan3 after a couple of updates back and now LXC. I searched the forum, but did not find TurrisOS 4.0 topic, except for this one. So i decided to just start using openWRT instead, but it did not go as planned and with very little spare time these days, now it has been posponed with a Omnia that is offline. Glad that i use RPI for internet and the Omnia just combining both the signals.
env default -a saveenv
Yeah i got a UART cable, but i am kind of holding back to use that one. I am not sure when the micro UART converter of something like that is being release. I read about it on a website you gave me a time back. It is a website that mostly talk about all kind of small computers. Maybe to refresh your mind, Khadas VIM MAX2. Did not save the website in to my bookmarks =_=!.
It was already told on some presentation. Why to waste so many time on migration problem, instead, the stable release should be ready asap, so most of us can do clean installation and then spend time on migration tool for less advanced users.
And after all, maybe, it would be just better to prepare instruction even for less experienced users of how to do manual installation, instead of creation super-migration tool which will be used only few times.
Even if the few low experienced users would need help on-site by teamviewer for example, I think it would be less hour/money required then developing of the migration tool.
You can already migrate to 4.0 if you like. There are still big buts in there but as we are working on 4.0 more and more documentation and guides are going to be created so it should not be hard to go from 3.x to 4.x.
I was responding on request of updating to 4.0. This is not possible without migration script so only way is to wipe configuration and start from scratch. That does not mean that we are not supporting clean installation, I would say that right to the contrary we do more than updating. I would also note that it is not a good idea to use backups from 3.x release because few important configurations were changed and router can be inaccessible if you load backup from 3.x (at least until configuration migration is done).
I am looking at least for beta release, as I cannot afford to play with alpha release.
All I am worried about is that the development of the stable release is slow down because of work on auto-migration-tool. Or at least I am getting this feeling from the forum and presentations.
I am not working on automigration yet. I am only promising it.
This is also an “alpha” release. In reality it is less alpha and more regular release. It pretty much works. I multiple times stated why it is marked as alpha: it is because not all features are there in final state. Updater for example is going to receive substantial update, data collection is not available and it is not tested well yet. Primary idea of alpha status is that updates might not be yet smooth not that firmware is unstable.