Optional migration from Turris OS 3.x for advanced users

@Patryk this is a very weird error as kernel fault of course would be reproduced by other users as well. I looked into the code and I can’t see any clear way the division would happen in that specific function. Thus it leads me to the conclusion that the cause might be a corrupted kernel image. Are you sure that you finished the migration correctly? The router gets rebooted automatically as part of the migration process. Have that happen or was there a forced reboot? The second option is that MMC might just be worn out and out of the sectors and thus new writes could result in corrupted files. The kernel would report a load of BTRFS errors if that is the case (during the update most likely).
In general, I would appreciate it if you could send me the exported snapshot with your working 3.x version so I can attempt migration directly (of course only if you are willing to do so). You can get exported snapshots using schnappps export X where X is the number of 3.x snapshot that worked for you.

@Orzech I am happy to hear that migration finished in your case. The process is that we declare migration finished only after the first successful regular check for updates. That happens on a four-hour basis (that is up to four hours later from migration) or can be forced by clicking on Check and install updates in reForis (as well as few others that trigger an update to install or remove additional software).
On the topic of verification. You do it the same way as you would do with a new router. Feel free to browse reForis and LuCI and look around with SSH. For example, the Firewall is compatible in its settings between 3.x and 5.x versions thus there should be no change.

1 Like

@cynerd

Yeah, I think I had pressed Check and install updates some seconds before Save on package selection screen, as the buttons are on adjoining screens, so perhaps it was just a coincidence that the notification appeared after me pressing Save. It’s not a problem that the Save was pressed before update check has finished, is it?

As for the firewall, could point perhaps me to some default configuration so I could compare mine with it?

Firewall settings are in file /etc/config/firewall and default setting should be in /etc/config/firewall-opkg.

You can mount snapshot created before migration to version 5 from SSH.
List of all snapshots:
schnapps list.
And try to find line before first with description “Automatic post-update snapshot (TurrisOS 5.2.7)”.
In my case it was #431:

    # | Type      | Size        | Date                        | Description
------+-----------+-------------+-----------------------------+------------------------------------
  428 | time      |    34.31MiB | 2021-09-12 01:05:02 +0200   | Snapshot created by cron
  429 | pre       |    10.80MiB | 2021-09-15 17:37:35 +0200   | Automatic pre-update snapshot
  430 | post      |    10.81MiB | 2021-09-15 17:37:42 +0200   | Automatic post-update snapshot
  **431** | pre       |    10.83MiB | 2021-09-18 19:18:20 +0200   | Automatic pre-update snapshot
  432 | post      |    12.68MiB | 2021-09-18 19:26:15 +0200   | Automatic post-update snapshot (**TurrisOS 5.2.7**)

You can mount this snapshot

root@turris:~# schnapps mount 431
Snapshot 431 mounted in /mnt/snapshot-@431

and compare files /etc/config/firewall and /mnt/snapshot-@431/etc/config/firewall.
Don’t forget to unmount mounted snapshot when you are finished:
umount /mnt/snapshot-@431

1 Like

Both of those buttons run update in the background. It is implemented in such a way that there is only one instance spawned at the time thus clicking it multiple times causes no issues.

1 Like

Did two migrations so far:

  • One on a 2017 Turris Omnia: no problems whatsoever save SSL (as mentioned elsewhere in this thread)
  • One on an Indiegogo (second shipment) Turris Omnia

The latter went horribly wrong. At reboot somehow the network configuration was scrambled, because eth2 (WAN) had no link and so couldn’t connect to the Internet. But somehow the whole post-install configuration went awry, as syslog-ng wasn’t functional and thus there were no logs. Running pkgupdate (after attaching a USB 4G modem to get some connectivity) it reported a dependency problem with zip: removing it just changed a handful of packages and did nothing else.

Does OpenWRT have a way to fiddle with the physical interfaces? My hunch is that somehow the switch configuration was incorrectly made and thus the wrong ports were bridged together.

After about 30 minutes of fiddling I gave up and did a factory reset with the TurrisOS 5.2 medkit and restored the necessary configuration from a backup. After the reset, everything went smoothly.

I can’t fathom what could have gone wrong during the update. I might set up remote logging with syslog-ng to avoid future issues (or just attach some storage for persistent logs).

I have just finished IG Turris Omnia migration.
It did require more clicks in foris to get it running and then in reforis (that I had to fix via Can not use Reforis on TOS 5+ - ControllerMissing - #17 by encacz)

HDD with Omnia still works fine.
PPPoE - no issues.
VLANs migrated, but with one issue. Interfaces that were visible in luci did actually not work and had to be SET by set

 set network."VLAN_NAME".ifname='lan"0 or 1,2,3,4,5"."VLANID"'

e.g. set network.management.ifname='lan0.10'

So these were three major issues.
One small issue is that automatic updates did not do all the work and had to be triggered more times in order for the process to do someting.
I have also received no notifications during the process (I had them enabled)
After manual update clicking on manualy fixed reforis I got first notification about restart - and that was all.

EDIT: Third issue - collectd is still not working. Same problems as in v15.05 of openwrt fork. I have been able to make it work in the past, but updater damaged changes and made it broken again.
So I hope this package will get fixed soon. It is time

1 Like

where did you have to type this and for what use ? *
Is set a shell command on TOS 5 ?

typed it inside ssh session with omnia. just a normal command.
yep it is some piece of CLI thats basic dependency inside TOS5

USE: as stated, in order to make VLANs working after migration

Ok, and where is the doc for this ?
I have more and more re

I did not notice any sensible documentation. I have just reversed the command from LUCI :smiley:

For collectd, install luci_statistics and use /etc/init.d/luci_statistics start instead of starting collectd.
Reason: the collectd package init script assembles a configuration which ignores everything that’s being made in LuCi.

I just did opkg update
then opkg install luci_statistics and nothing has been found

Did you also configure the whole shebang in LuCi and got the whole collectd-mod-* installed? (I assume luci-app-statistics is also installed).

What do you mean?

#! - shebang? 
* - asterisk, or so called wildcard. 

Should I install whole collect-mod?
And something else?

Sorry, it’s an idiomatic form for “the whole thing”. Well, not the whole collectd-mod but you should have some installed by default with statistics. Next you need to check in LuCi if they’re enabled.

This is what I have in my /etc/config/luci_statistics (I have installed a few more collectd modules in addition to the default ones):

config statistics 'collectd'
        option BaseDir '/var/run/collectd'
        option Include '/etc/collectd/conf.d'
        option PIDFile '/var/run/collectd.pid'
        option PluginDir '/usr/lib/collectd'
        option TypesDB '/usr/share/collectd/types.db'
        option Interval '30'
        option ReadThreads '2'

config statistics 'rrdtool'
        option default_timespan '1hour'
        option image_width '600'
        option image_path '/tmp/rrdimg'

config statistics 'collectd_rrdtool'
        option enable '0'
        option RRAMax '0'

config statistics 'collectd_csv'
        option enable '0'
        option StoreRates '0'
        option DataDir '/tmp'

config statistics 'collectd_email'
        option enable '0'
        option SocketFile '/var/run/collectd/email.sock'
        option SocketGroup 'nogroup'

config statistics 'collectd_logfile'
        option enable '0'
        option LogLevel 'notice'
        option File '/var/log/collectd.log'
        option Timestamp '1'

config statistics 'collectd_network'
        option enable '1'
        option Forward '0'

config statistics 'collectd_unixsock'
        option enable '0'
        option SocketFile '/var/run/collectd/query.sock'
        option SocketGroup 'nogroup'

config statistics 'collectd_apcups'
        option enable '0'
        option Host 'localhost'
        option Port '3551'

config statistics 'collectd_conntrack'
        option enable '0'

config statistics 'collectd_contextswitch'
        option enable '0'

config statistics 'collectd_cpu'
        option enable '1'
        option ReportByCpu '1'
        option ReportByState '1'
        option ValuesPercentage '1'

config statistics 'collectd_cpufreq'
        option enable '0'

config statistics 'collectd_df'
        option enable '0'
        option Devices '/dev/mtdblock/4'
        option MountPoints '/overlay'
        option FSTypes 'tmpfs'
        option IgnoreSelected '0'

config statistics 'collectd_disk'
        option enable '0'
        option Disks 'hda1 hdb'
        option IgnoreSelected '0'

config statistics 'collectd_dns'
        option enable '0'
        option Interfaces 'br-lan'
        option IgnoreSources '127.0.0.1'

config statistics 'collectd_entropy'
        option enable '0'

config statistics 'collectd_exec'
        option enable '0'

config statistics 'collectd_interface'
        option enable '1'
        option IgnoreSelected '0'
        option Interfaces 'eth2 br-lan'

config statistics 'collectd_iptables'
        option enable '0

config collectd_iptables_match
        option table 'nat'
        option chain 'luci_fw_postrouting'
        option target 'MASQUERADE'
        option source '192.168.1.0/24'
        option outputif 'br-ff'
        option name 'LAN-Clients traffic'

config collectd_iptables_match
        option chain 'luci_fw_postrouting'
        option table 'nat'
        option target 'MASQUERADE'
        option source '10.61.230.0/24'
        option outputif 'br-ff'
        option name 'WLAN-Clients traffic'

config statistics 'collectd_irq'
        option enable '0'
        option Irqs '2 3 4 7'

config statistics 'collectd_iwinfo'
        option enable '1'
        option IgnoreSelected '0'

config statistics 'collectd_load'
        option enable '1'

config statistics 'collectd_memory'
        option enable '1'
        option ValuesAbsolute '1'
        option ValuesPercentage '0'

config statistics 'collectd_netlink'
        option enable '0'
        option IgnoreSelected '0'
        option VerboseInterfaces 'br-lan'
        option QDiscs 'br-lan'

config statistics 'collectd_nut'
        option enable '0'
        list UPS 'myupsname'

config statistics 'collectd_olsrd'
        option enable '0'
        option Port '2006'
        option Host '127.0.0.1'

config statistics 'collectd_openvpn'
        option enable '0'

config statistics 'collectd_ping'
        option enable '0'
        option TTL '127'
        option Interval '30'
        option Hosts '127.0.0.1'

config statistics 'collectd_processes'
        option enable '0'
        option Processes 'uhttpd dnsmasq dropbear'

config statistics 'collectd_sensors'
        option enable '0'

config statistics 'collectd_splash_leases'
        option enable '0'

config statistics 'collectd_tcpconns'
        option enable '0'
        option ListeningPorts '0'
        option LocalPorts '22 80'

config statistics 'collectd_thermal'
        option enable '0'
        option IgnoreSelected '0'

config statistics 'collectd_uptime'
        option enable '1'

@einar do you have a backup from 3.x so I could look at it to found out what could go wrong in your case? I really do not see what could be the cause of the issues you experienced. There was never issue with syslog-ng but any custom configuration added to it might be incompatible with the new version and that might cause the syslog-ng to not start. Considering the network the switch configuration should be correctly migrated in most cases but there might be some cases I missed so your backup of configuration would be welcome in this regard.

@Comodore125 can you please share the 3.x and resulting configuration with me? (PM would be fine) I would like to investigate what went wrong with your network configuration as well.
Regarding the notifications. That is expected unfortunately but there should be at least one notification about the finished update at the end. The network access is, due to switch configuration migration, broken during the update and unconditional reboot is performed at the end to bring it back up. This causes none of the intermediate notifications to be sent and they are wiped on reboot (as right now we do not store notifications on permanent storage).

@cynerd Unfortunately I only have a backup of the 3.x configuration as I wiped everything with the medkit. It looked however like the system was a half-finished upgrade somehow. top also wasn’t working properly, for one. But due to logs not working I couldn’t figure out what was going on.

I can however send it if you want (I need to wipe a couple of private details there but that’s it).

@einar please do. The router should reboot itself automatically after all components are updated. Is that something that happened or did update in your case halt before that? (That would mean some big fault in updater as once updater is updated it is instructed to ignore missing packages and requests it can’t satisfy to prevent unfinished update)

So, I have tried this again after few months on my Turris 1.0:

Result - partial success after 3rd try:

  1. Via Foris. After hitting Save in Updater, green stripe about successfull settings, then erron in Foris page → 30s reset → wizard + update to 3.11.23
  2. Following instructions, via SSH - message about missing btrfs and SD Card. Didn´t know that it was even possible to install 3.11.23 outside the SD card. → installed btrfs
  3. Via SSH, installation was running about few hours, router became unreachable, no automatic reboot even after 8 hours. After removing of power supply, router was updated to 5.2.7

Result after update:
No wifi card was detected. Have been trying to: reset wifi settings, reboot to default settings (this didn´t worked at all), copying wireless settings from omnia, install additional CandelaTech wifi drivers via packages.
Nothing helped. So I have tried 30s reset again and I am back on 3.11.23 running from internal flash, then I gave it up for yesterday.

Is there any way to use some medkit copied to SD card with latest OS for Turris 1.x routers, which will fall to 5.x after reset?