Turris OS 5 is coming

You can track our work on Gitlab (https://gitlab.labs.nic.cz/groups/turris/-/issues?scope=all&utf8=✓&state=opened&milestone_title=Turris%20OS%205.0, https://gitlab.labs.nic.cz/groups/turris/-/merge_requests?scope=all&utf8=✓&state=opened&milestone_title=Turris%20OS%205.0)

I am not sure what information you want to know. In general we are not working with roadmap. We release when it is ready. That means that we don’t have some pinned date or state updates. Everything in reality is in public on our Gitlab.

I want exactly this kind of information:

But I guess it is partially derivable from this documentation page.

Results are in (though void of targeted branch off date)

5.4 kernel is prefered for the next release as this option got 14 votes, whereas 4.19 kernel got 13 votes.

Probably a relief for the TOS developer team not having to carry yet another branch any time soon.


[9] http://lists.infradead.org/pipermail/openwrt-adm/2020-February/001316.html

1 Like

Turris OS 6 with kernel 5.4 sounds good. I believe in an early release of Turris OS 5 (unfortunately without kernel 4.19). Turris OS 3 and 4 are obsolete.

According to the workflow it would have to traverse the build chain to HBS

Branch for the real releases that are deployed to the end users automatically.

whilst TOS4.x currently occupying slots: HBK -> HBT -> HBS.

Do you really want to link here every my post in that thread?

3 Likes

Do you really think that I am linking all of your posts?

Why I can´t answer to your question? This message was written polite.

Turris OS 5 is coming (into HBK).

1 Like

Well today I finally did it and tried to migrate to TOS 5 as I wanted to skip TOS 4 on my blue Turris 1.0.
I made sure to download latest 5.0 medkit form here turris1x-medkit-latest.tar.gz 2020-03-10 04:29 39M

Then
schnapps import -f turris1x-medkit-*.tar.gz
schnapps rollback factory

and verified with schnapps mount factory that there is 5.0 version in /etc/turris_version
reboot

After reboot logged to forris @ http://192.168.1.1 made basic config and selected packages after that logged with putty on console and found out running updater in the background but /etc/turris_version showed 4.0.5 version even it should be 5.0 as it was after medkit installation
within about 10 minutes followed another restart and finally i still am on 4.0.5 HBS instead 5.0 HBL

root@turris:~# uname -a
Linux turris 4.14.172 #0 SMP Tue Mar 10 00:13:43 2020 ppc GNU/Linux

BusyBox v1.28.4 () built-in shell (ash)

  ______                _         ____  _____
 /_  __/_  ____________(_)____   / __ \/ ___/
  / / / / / / ___/ ___/ / ___/  / / / /\__
 / / / /_/ / /  / /  / (__  )  / /_/ /___/ /
/_/  \__,_/_/  /_/  /_/____/   \____//____/

TurrisOS 4.0.5, Turris 1.x

root@turris:~#

Now tried switch-branch to hbl

  • echo ‘OPKG update failed. Please see previous output to know what went wrong.’
    OPKG update failed. Please see previous output to know what went wrong.

  • set +x

           ,%%%%%%%%,
         ,%%/\%%%%/\%%
        ,%%%\c "" J/%%%
    

%. %%%%/ o o %%%
%%. %%%% _ |%%%%% %%%%(__Y__)%%' // ;%%%%-/%%%’
(( / `%%%%%%%’
\ .’ |
\ / \ | |
\/ ) | |
\ /_ | |__
(___________)))))))
You are now in branch containing software build every night. It often contains bugs and sometimes requires manual intervention!
It is based on latest stable OpenWRT branch with latest Turris OS changes.
Turris team provides no guarantees and no support for this branch. You can get some help on forum (https://forum.turris.cz/).
If you encounter some bugs than please debug cause and report it to developers trough gitlab (https://gitlab.labs.nic.cz/),
You shouldn’t be in this branch unless you are advanced user!
To return to stable branch run this command: switch-branch hbs

after about another 10 minutes and anouther restart

BusyBox v1.30.1 () built-in shell (ash)

  ______                _         ____  _____
 /_  __/_  ____________(_)____   / __ \/ ___/
  / / / / / / ___/ ___/ / ___/  / / / /\__
 / / / /_/ / /  / /  / (__  )  / /_/ /___/ /
/_/  \__,_/_/  /_/  /_/____/   \____//____/

TurrisOS 5.0.0, Turris 1.x

root@turris:~# uname -a
Linux turris 4.14.162 #0 SMP Thu Jan 16 13:58:33 2020 ppc GNU/Linux

this is slightly less obsolete, even kernel bit older but newer version of busybox

after that I double checked that I have really 5.0 in factory and yes I do

root@turris:~# schnapps mount factory
Snapshot factory mounted in /mnt/snapshot-@factory
root@turris:~# cd /mnt/snapshot-@factory/
root@turris:/mnt/snapshot-@factory# cd etc
root@turris:/mnt/snapshot-@factory/etc# cat turris-version
5.0.0

So it is unclear to me why intermezzo with 4.0.5 is needed even factory TOS to which rollback was initiated is 5.0

I eventually end up on HBS anyway as upgrade every night is maybe too much for me to handle.

1 Like

Yes, I can confirm that it is going to be merged in HBK. A forum thread will follow soon or would you like to create it? I don’t have anything against that. :wink: That’s why I haven’t posted a changelog as I know that you will publish it here without providing any further details.

Rest assured that we are providing details as soon as we know. This time it was a little bit delayed as I had a vacation just for this day.

3 Likes

Well I can publish any details you request as it is under my fingerprints right now. Take your vacation, maybe I will have a lot of free time to play with TOS 5 due to quarantine. Please create the forum thread for all of us as I am no familiar with that.

Your finding was already discussed here on the forum. I’m including forum threads as reference:

This is expected. See this English thread below or you can find also other posts related to it:

If you prefer Czech, you can take a look here:

In this case, you haven’t provided details why update failed. But most likely you encountered this issue:

Otherwise, there is no need to provide more details.

1 Like

Oh wow I accidentally tried to run pkgupdate so I get arount this issue without scanning gitlab. Anyway I don’t understand the purpose why TOS 5 medkit leads to immeadite downgrade 4.0.5 that render router unusable untill downgrade is done. I understand now what is happening and that you no longer touch medkits for HBS and HBK. I understand that it is my fault not reading the forum throughly but yesterday it just wasted one hour of my time to figure out what is going on.

After fiddling with upgrade for 5 hours in the afternoon I get to state when my router boot but I was unable to connect to it and it did not give dhcp addresses to clients which was most likely caused by my effort to reinstall all missing packages by script prepared from opkg list-installed and output to that i made opkg install for all the packages which first was kmods, second was libs third were apps fourth was lxc and last were luci packages that worked for me b4. As I said at that moment my router was unusable and it was roughly about 22h so at that moment I give up and went to sleep. Luckily the idea to wait for another 64GB sdcard to be delivered for dd backup turns out great so I put the backup sd card into router and booted flawlessly back to TOS 3.11.14. So BACKUP, BACKUP, BACKUP! I knew it is going to be a bumpy ride to TOS5. After waking up today I plugged broken SD card to debian system under expectation that it will not be readable as I stated in another post but to my surprise debain buster immediately connected both partition including the BTRFS one that was unreadable before I consider it as side effect of upgrade when SD cards was created under some obsolete version of BTRFS kernel driver and now after upgrade the BTRFS partition were somehow upgraded and is it possible to be read now under up to date debian buster distribution.

/dev/sde1 102182 4252 97930 5% /media/vojta/0F01-0B1B
/dev/sde2 62417920 24788652 35793780 41% /media/vojta/0f276d8f-aa1e-4011-bef7-3ea279374bf2

This is quite important as before going to sleep I was satisfied that I will have to restore img backup to SD card which in my case take 4 hours to write (almost 40% of 64GB). Now to be able to read the BTRFS partition and to have snapshot of 4.0.5 it gives me hope that it will just need to take to rewrite content of this last snapshot to current one and Turris should boot e.g. not all 5 + 4 (sd restore) hours would be wasted and I could waste my time somewhere else with trying to get LXC containers of debian and pihole working back again under TOS5 and reconfigure all the services under TOS5

When will be TOS 5 switched to HBT?

Thanks for your question. Soon.

Thank you also. I don’t want to respond right after creation TOS 3.11.16 release thread, but TOS 5 (HBT) with functional mwan and newer and updated kernel will be great.

I considered use of TOS 5 (HBK) on me managed Omnia’s, but I am waiting to solving “Unreliable DSL (PPP) connection” issue.

Milestone related issues https://gitlab.labs.nic.cz/groups/turris/-/milestones/28


it was mentioned