Optional migration from Turris OS 3.x for advanced users

viktor · June 7, 2020, 5:54pm

This is common and already explained in forum.

cynerd · June 8, 2020, 7:09am

@don_mums can you please send diagnostics to support? I have no idea directly from this what is happening in your case. Also please state if router reports Turris OS 5.0.0 or 3.x release on login. I think that it might not even start migrating because of some updater configuration you have in /etc/updater/conf.d.

Outside of topic of migration but possibly yes. Those are incremental size against other snapshots (well previous one). If update was just minimal change then it can be such small as just few seconds before there was pre-update snapshot that contains most of the changes.

This is commonly the case and is this time as well but just to clarify: updater-ng is able to trigger immediate reboot and it was used multiple times in Turris OS 3.x to prevent breakage od swconfig (that piece of software was commonly getting incompatible with running version of kernel driver and caused broken network effectively).

Was that because you had multiple interfaces or was that just because it wasn’t migrated? The script you are linking is executed as part of migration process so I am interested in why it might fail or wasn’t executed correctly.

@kmarty I am sorry to hear that. I know where is the problem and I missed this. The cause is that migration halts in the middle because updater is not sure what to do next when he can’t resolve dependencies for clearly required file knot-host so it lets it on user but problem is that in that time new version of updater is installed and with that all of its dependencies (libc, ssl and so on) and that breaks rest of the system. I would suggest you to do rollback to 3.x and remove knot-host before attempting migration again. I am going to add warning about knot-host in to migration guide and think about how to prevent this.

@jklaas can I ask you if you (re)moved or moved /usr/share/updater/localrepo/auto before update? Also are you sure that you started with Turris OS 3.11.17? This looks like either old version of localrepo was installed in system or that during execution localrepo repository was (re)moved but not fully. This repository is added by /usr/share/updater/localrepo/localrepo.lua if you remove that path you should remove lua script as well.

No.

kmarty · June 8, 2020, 7:46am

Already did it, thanks goes to @anon82920800 (I’ve been so perplexed I totally forgot there’s chance to rollback).
Anyway, thank you for your reaction.
Maybe it is bad idea, but what about statically linked updater for these critical transitions? (Ignore it if it is really stupid)

LXC: Same situation as @_te has. Three single network containers, none of them converted. Maybe I am wrong, but it seems it is not part of “tos3to4” package and moreover I see some issue here

_te · June 8, 2020, 8:31am

@kmarty

Was that because you had multiple interfaces or was that just because it wasn’t migrated? The script you are linking is executed as part of migration process so I am interested in why it might fail or wasn’t executed correctly.

I did not have multiple interfaces. The configurations I had were 1:1 as described in the MR.

andrsd · June 8, 2020, 2:14pm

I ran into the same problem as @jklass with the updater not being able to read /usr/share/updater/localrepo/auto/Packages. I did:

# touch /usr/share/updater/localrepo/auto/Packages

and that seemed to unstuck the process and I ended up with Turris 5.0 after a few minutes. I also started from Turris 3.11.17. And I do not remember messing with that location.

Seems like a simpler fix that factory reset, etc.

jklaas · June 8, 2020, 2:32pm

After some mis-adventures this morning since it decided to try updating again (because the 2 LED restore decided I should use the post-update snapshot) I got a schnapps restore I feel I can trust not to try updating on me, which is the post install after updating to 3.11.17.

# find /usr/share/updater/localrepo/
/usr/share/updater/localrepo/
/usr/share/updater/localrepo/auto
/usr/share/updater/localrepo/auto/luci-app-access-control_0.4.1.ipk
/usr/share/updater/localrepo/auto/Packages.gz
/usr/share/updater/localrepo/auto/luci-app-radius_0.1-1.ipk
/usr/share/updater/localrepo/auto/adblock_3.5.4-2.ipk
/usr/share/updater/localrepo/localrepo.lua

This was entirely there from before the attempted upgrade (in my current snapshot). Should I remove /usr/share/updater/localrepo? The upgrade doc just mentions that this will be blown away, which I’m fine with (I have backups and/or can recreate as needed).

jklaas · June 8, 2020, 2:34pm

andrsd:

I ran into the same problem as @jklass with the updater not being able to read /usr/share/updater/localrepo/auto/Packages . I did:
# touch /usr/share/updater/localrepo/auto/Packages
and that seemed to unstuck the process and I ended up with Turris 5.0 after a few minutes. I also started from Turris 3.11.17. And I do not remember messing with that location.

Ah, OK. I can give that a shot.

[edit] I tried that and it’s just sitting there. Did you touch the file before the upgrade?
[edit2] I schnapps restored again and touched the file before I started the upgrade and it completed. - Yay, Turris 5.0

cynerd · June 8, 2020, 2:34pm

@jklaas I see where is the problem. Hmm all right. I am going to fix that. Anyway removing /usr/share/updater/localrepo is all right as fix for now.

pierre · June 8, 2020, 3:52pm

Please add knot-dig

fantomas · June 8, 2020, 4:32pm

yeah, common and explained, so you have to dig for it.
Just FYI: Provides with Conflicts are incorrectly reported as in cyclic dependency

cynerd · June 9, 2020, 9:19am

Thanks to migration to be pointed in Turris OS 3.x still to HBK the Turris 1.x migration should be possible now.

Fix for LXC migration should be up once Turris OS 5.0.1 is released to HBS (script just wasn’t included, my fault). It is already available If you migrate from nightly as it is in HBK already.

kmarty · June 9, 2020, 10:47am

@cynerd:

If reading from STDIN is not your plan, this patch should be applied

--- lxc.orig	2020-06-09 04:58:22.000000000 +0200
+++ lxc	2020-06-09 12:43:57.000000000 +0200
@@ -7,7 +7,7 @@
 		echo "Config is detected as migrated: $conf" >&2
 		return
 	fi
-	if [ "$(grep -c '^lxc\.network\.type')" -gt 1 ]; then
+	if [ $(grep -c '^lxc\.network\.type' "$conf") -gt 1 ]; then
 		create_notification -s error \
 			"Automatic migration of LXC failed: Unable to migrate configuration with multiple network sections: $conf"
 		echo "Unable to migrate configuration with multiple network sections: $conf" >&2

cynerd · June 9, 2020, 11:07am

Thank you for noticing that. It should not cause any problems during update with exception that it won’t stop LXC config migration of multiple networks are found in config. Updater runs these script with closed stdin if I remember correctly. In manual execution that causes problem that is true.
It should be fixed now in master and should be part of future fixup release (5.0.1 or 5.0.2).

seiichiro0185 · June 9, 2020, 5:10pm

Hi there, I did try to update my Turris Omnia from 3 to 5, which in general worked ok with the known caveats (LXC-Container with multiple Interfaces, and freeradius 2 to 3 Config Changes etc…) but at the moment there is one thing blocking the usability for me:

I have several VLANs running, and most importantly a trunk port for the vlans on LAN1. The Migration seemingly did migrate this more or less as expected, (meaning, it puts lan1.vlanid interfaces into the respective bridges) but it does not work. I can’t reach anything on the other side of the trunk. Is this supposed to be a supported migration, or are there any additional steps / manual changes necessary to get this working?

As the Omnia is my main Router and my Network doesn’t work without the trunk port I did rollback to Version 3 for the time being (fortunately this works as expected).

cynerd · June 9, 2020, 5:52pm

Can you please pm me old network configuration and migrated one? You can get 3.x one directly and migrated one can be received by mounting rollback snapshot. That is /etc/config/network file.

Barrett98Bravo · June 11, 2020, 12:59pm

I followed the migration steps logged in as root via ssh shell:
opkg-cl update
opkg-cl install tos3to4
updater-supervisor -d
After reboot I had to reassign my WAN under the Interfaces menu but my switch and lan ports are no longer available. Wifi is fine. Does anyone have a default /etc/config/network file for 5.x they can post the contents I may reference to make my switch and wired lan operational again?

Thanks

jiberjaber · June 11, 2020, 4:34pm

So I bit the bullet and pulled the trigger to update my TO to 5.
Script seemed to go fine, email notifications as timing, I think I kicked off around 16:35 (“Updater approvals were deactivated to prevent problems during migration to latest major release of Turris OS!” email).
Received the updates applied email around 16:54
Now on:
:: TurrisOS 5.0.1 :: TurrisOS 5.0.1 e752fc1ff9d1d4f50a32155dd714dcde4b070bd4 :: 5.0.1.e752fc1ff9 ::

I don’t have LXC yet which caused some problems as I use pihole on a LXC so need to workout how to get that running again.
I needed to power off and back on again to get the full network up (wifi didn’t work)
I am receiving an error on the LXC page thus:

If I click the login button and login, it cycles back to the same message and I have to log in again, sometimes after the second login I get a text screen saying that there is a corrupt file.
“/usr/lib/lua/luci/dispatcher.lua:426: /etc/config/luci seems to be corrupt, unable to find section ‘main’”

jiberjaber · June 11, 2020, 4:45pm

Here you go, this is my 5.0 network file:

config interface 'loopback'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'
	option ifname 'lo'

config globals 'globals'
	option ula_prefix 'fd47:9f75:add1::/48'

config interface 'lan'
	option force_link '1'
	option type 'bridge'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option ip6assign '60'
	option _orig_ifname 'eth0 eth2 wlan0 wlan1'
	option _orig_bridge 'true'
	option mtu '1492'
	option igmp_snooping '0'
	option delegate '0'
	option _turris_mode 'managed'
	list ifname 'lan0'
	list ifname 'lan1'
	list ifname 'lan2'
	list ifname 'lan3'
	list ifname 'lan4'

config interface 'wan'
	option proto 'pppoe'
	option username 'XXXXXXXXXXXXXXXXXXXXXXX'
	option password 'XX'
	option mtu '1492'
	option ipv6 'auto'
	option peerdns '0'
	option dns '192.168.1.4'
	option ifname 'eth2'

config interface 'wan6'
	option proto 'dhcpv6'
	option reqaddress 'try'
	option reqprefix 'auto'
	option ifname '@wan'

config interface 'vpn_turris'
	option enabled '1'
	option proto 'none'
	option auto '1'
	option ifname 'tun_turris'

config route
	option interface 'lan'
	option target '192.168.2.0/24'
	option netmask '255.255.255.0'
	option gateway '192.168.1.2'

config interface 'guest_turris'
	option enabled '1'
	option type 'bridge'
	option proto 'static'
	option ipaddr '10.111.222.1'
	option netmask '255.255.255.0'
	option bridge_empty '1'
	option ifname 'guest_turris_0'

Barrett98Bravo · June 11, 2020, 6:23pm

Thanks jiberjaber! Working great now!

I noticed no switch configuration exists in your network file. Any idea why not? Was this done away with in 5.0?

I do recall this existing in 3.x and the Switch menu showing up under the Network tab in LuCi.

protree · June 11, 2020, 6:56pm

Please search for keyword „dsa“ on this forum, you will find plenty of information

Like this:

EDIT: Btw I think a change like this should be added to release notes / migration documentation mentiond in first post…