Please be aware that this is still experimental and problems might be present. You
should read the documentation to its fullest before you attempt migration.
You can also check Gitlab issue about migration to get an idea about features that are covered by migration.
If you are going to perform migration on Turris 1.0 and Turris 1.1, be aware that Turris OS 5.0 is not supported on internal storage. You have to migrate to SD card first, you can follow this tutorial.
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.
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?
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.
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.
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.
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.
""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:
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.
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?)
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.
