Restore 17.01.4 backup to 18.06.1

Hello,

Do you guys know, if required all packages are installed, that are required by both firmwares, then a LEDE 17.01.4 backup restore is valid of a OpenWrt 18.06.1 firmware?

In general, there's a good chance for it to work (talking about 17.01.x --> 18.06.y) - but depending on your specifics there might have been changes that might bite you (e.g. the xDSL modem interface for lantiq, OpenVPN configurations, etc. pp.).

i use the regular settings, plus i have opevpn outgoing and l2tp vpn incoming settings.
do you know how i can find out what settings changed?

Make this then a sysupgrade with keep settings and compare files under /etc/config....or another way ;- )

For OpenVPN, you can either read through upstream changelogs and commits in OpenWrt's packages repo, anticipate the potential breakge, so you can preemptively adapt the config before upgrading - or you can just try, while expecting breakage and checking logs after the fact, to get the hints you need to look for changes between the versions.

The former will keep you busy a couple of hours to days, with a chance to avert breakage before it happens.
The later might leave you OpenVPN sessions broken for a while, until you find and fix the problems.

There should be no changes that would affect an OpenVPN config... the more important changes would be if OpenVPN 2.3.x was being utilized on 17.01.x (i.e. OpenVPN was never updated on the device), as many things changed in OpenVPN 2.4.x.

You can do a diff comparison on config files with a text editor like Atom and the split-diff package, comparing against the config files in an OpenWrt official image, however there may be a more efficient way that I may not be aware of... else what @slh suggested above may be required.

Like the previous writers have said, for most routers there has been nothing that really breaks things. But for some routers there has been e.g. eth0/eth1 swaps etc. that could break connectivity.

By looking at the source repos.
You can look at the package changelogs and at the core changes at the board detection phase.

One example of a core system change is that 18.06 has tagged switch configuration by default, unlike 17.01, so the default interfaces are now typically like eth0.2 and eth1.1 (instead of just eth0.1 and eth1). That change affected also other network related config files e.g. SQM, BCP38 etc.
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=73d923ed6baabe3f8844f13216c50a6383a79a46;hp=770ac77cce59c4544dae65aeb1a3908623883854

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=ea269c37b83b9e6b93e35d576b49a6e0ae8ea0b9;hp=62bf0d495810429bdda8cd2ebf94ef395f8111fd

This is an example of a defaults change that affected most routers. However, your old config would still work as your old settings would override that new default. But you would then have slightly non-standard network config deviating from the 178.06 defaults.

In the long run it might be wise to let 18.06 to generate new defaults from scratch and then compare your old settings to those, and modify the new settings if needed.

The crucial ones are: system, network, dhcp (and maybe firewall, but not much there)

Add-on packages are then a separate story, as you need to check the individual packages if there have been crucial changes.

2 Likes

One handy script that I include in my own builds:

This compares your current config files against the defaults in /rom, and shows the diff.

#!/bin/sh
cd /etc/config
for F in *
do
        echo
        echo "===== $F ====="
        uci -c /rom/etc/config export $F >/tmp/$F.default 2>/dev/null
        case $? in 0) ;; *) echo '>> no default in /rom <<' ;; esac
        uci export $F >/tmp/$F.current
        diff /tmp/$F.default /tmp/$F.current
        rm -f /tmp/$F.default /tmp/$F.current
done

So, this is not about comparing two active configs, but for comparing your current config again that firmware's defaults.

Note that it does not compare network and wireless, as those are not statically in /rom but are created at the first boot based on the device recipe (board detection). It also works for only for those add-on packages that have been included in the build and image, so that the defaults are in /rom

The script could be easily modified to e.g. compare against restored config archive somewhere else than in /rom/etc/config

2 Likes

Thanks very much for the help! I will do it on the weekend, now I understand it is not evident to go from LEDE to OpenWrt, it looks like most the switch is changed and the network names. The rest looks like same.

i have upgraded to 18.06.1, what is weird is that the code is actually not changed at all, they is just naming refactor, that's what made me to work on it more instead of a simple upgrade.
i hope in like OpenWrt 19, they will not change unnecessarily name in the firmware (network name, wifi pci name). A bit useless, but I hope it will be fixed in the future. I code a lot so lots of mistakes that does not really shouldnt change at all happens of course, i bit we all over refactor.

You could voice that wish to upstream Linux kernel developers that changed the PCI numbering somewhere between 4.9 and 4.14.

Not all changes originate at Openwrt...

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.