Optional migration from Turris OS 3.x for advanced users

#1

Official migration guide is now available on
https://docs.turris.cz/geek/tos3_migration/.

Please be aware that this is still experimental and problems might be present. You
should read the documentation in its fullest before you attempt migration.

Do not attempt migration of Turris 1.x at this time. There is known problem with switch configuration. You can potentially end up with invalid switch configuration and with access to router only over WiFi.

If you are going to perform migration on Turris 1.0 and Turris 1.1, be aware that Turris OS 5.0 provides only experimental support for these models.

Quick fix before it is added to documentation or hotfixed:

  • Remove package knot, knot-zonecheck, knot-tests, knot-nsupdate, knot-keymgr, knot-host and knot-dig if present in your system. (TLDR: remove any package depending on knot-libs) You can do that simply by:
opkg remove knot{,-zonecheck,-tests,-nsupdate,-keymgr,-host,-dig}

Fixes after migration:

  • Till the release of Turris OS 5.0.2 (to HBS) make sure that you switch to appropriate branch using switch-branch as you probably landed in HBK (development branch) due to bug.
5 Likes
Turris OS 5.0 is released!
#2

First sentence in documentation is “Update from Turris OS 3.x to 4.0”. Is it correct?

#3

Full sentence is “Update from Turris OS 3.x to 4.0 or newer is big leap.”. You can see there “or newer”, aren’t you? This documentation was written before 5.0 and wasn’t updated for it but it is fully valid. It migrates users to latest version of Turris OS no matter if that is 4.0 or newer and that includes 5.0 as well. :wink:

1 Like
#4

Which can confuse many users.

2 Likes
#5

Could you maybe add a list of “extra things” that are cared for during the migration? I mean, mention that samba migration is performed, lxc containers and so on…

What is the recommended way of making backups of lxc containers before performing the update? Is it enough to backup their config files, or should I rather backup the whole container?

#6

This might change so I am reluctant to add it in fullest to documentation specially because it is more implementation detail but we can have that in community documentation.

Only configuration files of LXC container are touched not content so backing up those is enough. In reality script itself is going to back it them for you by appending .lxc1 to them before generating new one from their content.

#7

Interesting & thank you.

If anyone has done the “’ Optional migration
Migration is not yet executed automatically but it can be triggered manually.”’ i would love to know the results. Since that will be the route i like to follow. My Omnia is runnig rather basic, the 2GB Kickstarter model, no internal mods or container stuff.

#8

I have same router. When the migration script will be completed, I will test it and prepare feedback.

#9

The issue viktor has referenced contains a list similar to the one I asked for. Is it still up-to-date?

#10

It is up to date but sometimes less optimistic. For example testing marks LXC as untested while it was tested multiple times but not with latest changes to migration script (that were just cosmetic but who knows). Although if that is enough for you then feel free to use that.

#11

Good. Can I count on all of the items in the issue will be worked on and are to be resolved in the future?

#12

I really appreciate this and the outline of considerations and known issues. However, there doesn’t appear to be even a rough guideline on how to start or do the actual migration.

I realize that information can be found elsewhere, but I was hoping this might be a more comprehensive documentation.

#13

hmm, i think it does ?

""To start migration you have to have at least Turris OS 3.11.14 installed on your device. Please be sure about that before you attempt migration. To double check you can run pkgupdate from command line (over SSH). It should not ask you to confirm any changes.

To initialize migration process you have to access router’s command line (with SSH) and run following commands:

rm -rf /usr/share/updater/localrepo
opkg-cl update
opkg-cl install tos3to4
updater-supervisor -d

This sequence installs a package that triggers migration and starts Turris updater."’

thats from the page?

1 Like
#14

Ah, sure. My apologies, I read that, but it didn’t sink in.

I guess I thought it would jump out at me more. I guess I think it would be better instead of

Optional Migration
Migration is not yet executed automatically but it can be triggered manually.

It might be better to have something like

How to Migrate
Because migration is not yet executed automatically, you must trigger the migration manually.

I’m just complaining since I didn’t see it directly.

1 Like
#15

Well, i’m more curious IF the Omnia is reachable ( SSH or webbased ) if something goes not as planned, and totally going bananas. And only a medkit or something is needed to get it breathing again.

Therefore i hope someone else is doing the bugsbunny work for me.

#16

Currently only the u-boot version that ships with the O 2019|20 revisions provides the 5-LED mode with SSH access https://docs.turris.cz/hw/omnia/rescue_modes/

#17

Ah good to know, mine is from 2016. Meaning, no go if all goes wrong? Im def not good with serial ports and stuff.

#18

That would be the only other option if things really go sideways (which likely won’t with the migration script), that is until u-boot for earlier O boards gets updated (in TOS3.x?)

#19

That is not the only option. Updater creates snapshot before update so you can do simple rollback. If you encounter problems after migration (when updater finished successfully) then you have postupdate snapshot that can’t be usedl to revert to 3.x version. In such case you can do factory rollback and use factory version the same way as SSH rescue mode.

I think that you were rather interested in if you can do it remotely. I would not advice that unless you have someone to call to rollback router to previous snapshot. It should be all right but migration performs libc replacement with incompatibilities so big that once update is started all components are pretty much broken (no new spawned process starts correctly) until relevant package is updated as well. If something goes wrong in the middle of that then you might end up not only without network connection but also without SSH access or even init system. This applies primarily for few days now as later with more testers you can be more sure that it is going to success.

Edit: I should say that extensive care was made so that would not happen. This means that there are some compromises in migration such as that updater ignores missing packages or that localrepo is pretty much wiped clean.

1 Like
#20

I have multiple interfaces. Around 10 VLANs. will that get migrated well? Also I got multipe WIFI networks interlinked with various VLANs?