Automatic migration is here!

Pepe · December 1, 2021, 12:49pm

Dear Turris users,

These days, we are maintaining two stable versions of Turris OS.

In one case, you might notice that we did not release a new version of our old stable version Turris OS 3.x running on Turris 1.x and Turris Omnia routers. Turris OS 3.x is with us for a long time, and it runs an older OpenWrt version, which is no longer maintained by OpenWrt but by us.

We can not assure on Turris OS 3.x that you will be secured against recent security vulnerabilities. Sooner, we want to deprecate and decide not to support this version anymore. Before doing it, we need to migrate to our latest version - Turris OS 5.3.x.

You might want to know what it means to you.

All Turris 1.x routers using Btrfs without contract and running Turris OS 3.x will be migrated to Turris OS 5.3.x in this wave.
The first two thousand of Turris Omnia will be migrated in this wave.

If you want to trigger the migration process early, you can do that in Foris.

What are the most changes?

You will be using the supported OpenWrt version 19.07.8.
It means updated kernel to version 4.14 LTS, new versions of everything, LuCI uses client-side rendering, and many other features! We should not forget about ours like redesigned Foris (reForis), new detection system Turris:Sentinel are waiting for you!
Migration from Turris OS 3.x to Turris OS 5.x is a huge step.
More than three years of development on our side and on OpenWrt required to do some changes. In that case, some packages and features are no longer there, like Server-side backups, CUPS, etc. You can found short list of changes in our documentation: 3.x migration - Turris Documentation

Where I should report issues

We hope that the migration will be smooth for most cases like basic configuration and so on. If not, we are ready to help you. Please, follow this article.

We want to use our efforts to focus on releases, which are maintained by OpenWrt devs&community, where we are contributing and keeping all OpenWrt routers secured and updated. It will help our developers develop new features to use up-to-date versions of Python and other things they need.

Pepe · December 1, 2021, 2:19pm

If you are curious how the development of the migration process went, yesterday @Cynerd was talking about it during Turris Academy. Here is the video:

sedlak.mila · December 1, 2021, 5:49pm

Zdravím, když jsem tu četl o prvních úspěšných migračních krocích, tak jsem to zkusil po delší době znovu také, router běžel stále asi 2 dny ale jeho webové rozhraní nefungovalo. Když jsem ho následně zrestartoval, tak už z něj byla cihla i bez přístupu SSH. Tak jsem udělal čistou instalaci a nyní již běžím na 5.3.1.
V minulosti jsem na nějaké 5.1.x nebyl schopen zprovoznit obě dvě WIFI karty.
Snad tedy budou mít ostatní s migrací více štěstí. Za mne je i čistá instalace v pohodě a díky za podporu.

tomskra · December 2, 2021, 7:14am

Yesterday, automatic migration on my Turris 1.1 started. I have the same problem as sedlak.mila, router Web interface stopped work after migration. I checked lighttpd and I have got this error:

root@turris:~# lighttpd -f /etc/lighttpd/lighttpd.conf
Undefined config variable: var.home_dir
2021-12-02 08:05:32: (../src/configfile.c.2093) source: /etc/lighttpd/modules.d/30-webdav.load line: 25 pos: 49 parser failed somehow near here: +
2021-12-02 08:05:32: (../src/configfile.c.2093) source: /etc/lighttpd/lighttpd.conf line: 36 pos: 8 parser failed somehow near here: (EOL)

I tried to disable webdav module and web interface now works OK.

Pepe · December 2, 2021, 8:08am

Hello @tomskra,

Thank you for providing such details. I was able to reproduce it on my end. I will take a look at what I can do about it.

beda · December 2, 2021, 7:53am

It seems that during the upgrade, the /etc/config/network config on my Turris 1.0 got modified. I lost all the switch_vlan sections and some other parts got rearranged as well.

I also have a secondary Wifi card but the /etc/config/wireless config got modified as well, so the path attributes which pointed each config to a different card were lost.

All in all, not that great an update for me

beda · December 2, 2021, 8:45am

After some more digging (definitely an unexpected way of spending my morning ) I found that there are now automatically provided interfaces for all the lan ports (lan1, lan2, …), so one does not need (and maybe can’t?) use the old configuration with switch, etc.

Unfortunately the migration script was not able to comprehend my rather complex VLAN configuration so it removed the ifname attr from most of the interface sections in /etc/config/network (it only converted it in one section to lanX and with incorrect ports at that).

I got it working now, but what a PITA.

Still no luck with the wifi, but that is not that important as I mainly use my Omnia for that.

cynerd · December 2, 2021, 9:43am

@beda all those changes were necessary. Switch can’t be configured that way because there is no swconfig anymore, there is DSA instead. The original configuration was incompatible with the new one. The same applies to WiFi identifiers. The paths are invalid in the new kernel version for some cards but without running the new kernel to find out the correct path we had to use a different identifier to ensure that cards are still working. The correct identifier was mac address. This is even what OpenWrt now uses in default to identify cards (although their documentation tells you that it is for overriding mac address only). Is it possible that you have originally overridden the mac address on the WiFi card and so the identifier is no longer valid?

Can you please send me your configuration with possibly some explanation? I can look at it. The script was able to migrate any network we throw at it but we might missed something.

beda · December 2, 2021, 11:09am

@cynerd OK, thanks for the info. I will have another look at the wifi.

Here is the original configuration:

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

config globals 'globals'
	option ula_prefix 'fdbe:4a0a:5457::/48'

config interface 'lan'
	option ifname 'eth0 tap0'
	option type 'bridge'
	option proto 'static'
	option netmask '255.255.255.0'
	option ipaddr '192.168.9.1'
	option ip6assign '64'
	option ip6hint '1'
	option mtu '9000'

config interface 'wan'
	option ifname 'eth2'
	option proto 'dhcp'

#config interface 'wan6'
#	option _orig_ifname '@wan'
#	option _orig_bridge 'false'
#	option proto '6in4'
#	option peeraddr '217.31.57.16'
#	option ip6addr '2a01:8c00:ff00:2f2::2'
#	option ip6prefix '2a01:8c00:ffe0::/48'


config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option ports '6 4 5'

config switch_vlan
	option device 'switch0'
	option vlan '4'
	option ports '0t 2'

config switch_vlan
	option device 'switch0'
	option vlan '3'
	option ports '0t 3'

config switch_vlan
	option device 'switch0'
	option vlan '6'
	option ports '0t 1'

config interface 'phone'
	option ifname 'eth1.4'
	option proto 'static'
	option ipaddr '192.168.200.1'
	option netmask '255.255.255.0'

config interface 'ripeatlas'
	option ifname 'eth1.3'
	option proto 'static'
	option ipaddr '192.168.201.1'
	option netmask '255.255.255.0'
	option ip6assign '64'
	option ip6hint 'a1'

config interface 'guest'
	option ifname 'eth1.6'
	option proto 'static'
	option ipaddr '192.168.210.1'
	option netmask '255.255.255.0'
	option type 'bridge'
	option ip6assign '64'
	option ip6hint 'a0'

My main problem was that lan was assigned lan4 and lan5 even though the original config had ports 1 and 2. So the clients in lan were no longer in that network and could not connect. Also the ifnames dissapeared from the other interfaces. Here is a diff from schnapps:

--- @217/etc/config/network	2017-04-12 18:57:45.000000000 +0200
+++ @218/etc/config/network	2021-12-02 00:46:48.825431869 +0100
@@ -1,15 +1,14 @@
 
 config interface 'loopback'
-	option ifname 'lo'
 	option proto 'static'
 	option ipaddr '127.0.0.1'
 	option netmask '255.0.0.0'
+	option ifname 'lo'
 
 config globals 'globals'
 	option ula_prefix 'fdbe:4a0a:5457::/48'
 
 config interface 'lan'
-	option ifname 'eth0 tap0'
 	option type 'bridge'
 	option proto 'static'
 	option netmask '255.255.255.0'
@@ -17,52 +16,20 @@
 	option ip6assign '64'
 	option ip6hint '1'
 	option mtu '9000'
+	list ifname 'lan4'
+	list ifname 'lan5'
+	list ifname 'tap0'
 
 config interface 'wan'
-	option ifname 'eth2'
 	option proto 'dhcp'
-
-#config interface 'wan6'
-#	option _orig_ifname '@wan'
-#	option _orig_bridge 'false'
-#	option proto '6in4'
-#	option peeraddr '217.31.57.16'
-#	option ip6addr '2a01:8c00:ff00:2f2::2'
-#	option ip6prefix '2a01:8c00:ffe0::/48'
-
-config switch
-	option name 'switch0'
-	option reset '1'
-	option enable_vlan '1'
-
-config switch_vlan
-	option device 'switch0'
-	option vlan '1'
-	option ports '6 4 5'
-
-config switch_vlan
-	option device 'switch0'
-	option vlan '4'
-	option ports '0t 2'
-
-config switch_vlan
-	option device 'switch0'
-	option vlan '3'
-	option ports '0t 3'
-
-config switch_vlan
-	option device 'switch0'
-	option vlan '6'
-	option ports '0t 1'
+	option ifname 'eth2'
 
 config interface 'phone'
-	option ifname 'eth1.4'
 	option proto 'static'
 	option ipaddr '192.168.200.1'
 	option netmask '255.255.255.0'
 
 config interface 'ripeatlas'
-	option ifname 'eth1.3'
 	option proto 'static'
 	option ipaddr '192.168.201.1'
 	option netmask '255.255.255.0'
@@ -70,10 +37,10 @@
 	option ip6hint 'a1'
 
 config interface 'guest'
-	option ifname 'eth1.6'
 	option proto 'static'
 	option ipaddr '192.168.210.1'
 	option netmask '255.255.255.0'
 	option type 'bridge'
 	option ip6assign '64'
 	option ip6hint 'a0'

BTW, it would have been really helpful, if some kind of comments were added to the parts that were modified and instead of removing something, you would just comment it out with extra info about why it was done. It would make my life much easier, because at the beginning I had no clue what has happened and where to look.

druzickaster · December 2, 2021, 6:19pm

Ahoj,
Turris 1.0 update na turrisos5 nejak probehl, ale updater mi hlasi chybu

Updater selhal:

inconsistent: Requested package nor-update that is not available.

Pritom podle fora jsem NOR update provedl, hned kdyz se testoval, tak nevim, doinstalovat balik? Bohuzel mam router momentalne 60km daleko, takze mam jen jeden pokus, proto otravuju.

Diky a pekny den

David

Pepe · December 2, 2021, 6:28pm

Balíček odstraňte pomocí postupu uvedeného v dokumentaci:

Balíček byl přejmenován na turris-nor-update, ale není nutné jej mít nainstalovaný.

druzickaster · December 2, 2021, 7:20pm

Super, tuhle informaci jsem v navodu prehledl, omlouvam se. Odstranil jsem balik z /etc/updater/conf.d/opkg-auto.lua a vypada ze by to i jelo dal, zitra odpo budu pokracovat, dcera ma rano skolu, tak ji to nechci sestrelit

Diky za pomoc! David

druzickaster · December 3, 2021, 12:38pm

Updater dojel uspesne do konce, vypada, ze vse funguje. Dekuji za vasi praci a podporu!

pierre · December 5, 2021, 7:13pm

Just want to say THANKS. Migration went fine, just a liitle bit work to do to bring my attached storage (for lxc) back online. All networking/vlan configurations have been migrated successfully. You did a great job.

stokito · December 7, 2021, 11:47am

You must create a /etc/lighttpd/modules/1-vars.load file and declare the variable there.
See my instruction https://gist.github.com/stokito/77c42f8aff2dade91621c1051f73e58c

stokito · December 7, 2021, 11:49am

The same problem exists in a vanilla openwrt. See https://gist.github.com/stokito/77c42f8aff2dade91621c1051f73e58c

Pepe · December 7, 2021, 12:11pm

I know, I am aware of it. I need to fix it in our distribution and then send it to upstream.

Shortik · December 7, 2021, 7:45pm

Hlásilo mi to stejnou chybu. Na základě návodu v odkazu jsem si vypsal nainstalované balíčky (opkg list-installed), ale nor-update jsem tam nenašel. Zkusil jsem se mrknout do /etc/updater/conf.d/opkg-auto.lua, ale ani tam nebylo o nor-update vidu ani slechu. Spustil jsem tedy ručně update ( pkgupdate), který bez chyb proběhl a po restartu Turrise mi, zdá se, vše běží v pořádku.

Pepe · December 8, 2021, 1:48pm

Dear Turris users,

Recently, we released a new Turris OS 5.3.2 version, which included multiple fixes for the migration process reported here or through our support channels.

We decided to trigger automatic updates for more Turris Omnia routers today.

This wave triggered ~5500 serial numbers to be migrated from Turris OS 3.x to Turris OS 5.x. It is possible that migration was not triggered for someone. That’s because it will be done in upcoming waves. There are remaining ~11 000 SN from ~18 000 SN.

If you don’t want to wait, you can trigger it manually in Foris.