diff options
| author | Adrian Schmutzler <freifunk@adrianschmutzler.de> | 2020-08-06 14:43:16 +0200 |
|---|---|---|
| committer | Adrian Schmutzler <freifunk@adrianschmutzler.de> | 2020-08-08 16:13:51 +0200 |
| commit | a9703db72030a43c5a22f02411d3680ba2e2faf3 (patch) | |
| tree | 6126704b0c8663aebe3a7a94b59b6b4007d7b77c /target/linux/mvebu | |
| parent | de78747de111ba5e4c978fe8067b2260efe01d0d (diff) | |
| download | upstream-a9703db72030a43c5a22f02411d3680ba2e2faf3.tar.gz upstream-a9703db72030a43c5a22f02411d3680ba2e2faf3.tar.bz2 upstream-a9703db72030a43c5a22f02411d3680ba2e2faf3.zip | |
mvebu: fix sysupgrade experience for early DSA-adopters
Conceptually, the compat-version during sysupgrade is meant to
describe the config. Therefore, if somebody starts with a device on
19.07 and swconfig, and that person does a forceful upgrade into a
DSA-based firmware without wiping his/her config, then the local
compat-version should stay at 1.0 according to the config present
(and not get updated).
However, this poses a problem for those people that early-adopted
DSA in master, as they already have adjusted their config for DSA,
but it still is "1.0" as far as sysupgrade is concerned. This can
be healed by a simple
uci set system.@system[0].compat_version="1.1"
uci commit system
But this needs to be applied _after_ the upgrade (as the "old" fwtool
on the old installation does not know about compat_version) and it
requires access via SSH (i.e. no pure GUI solution is available for
this group of people, apart from wiping their config _again_ for
no technical reason). Despite, the situation will not become
obvious to those just upgrading via GUI, they will just have the
experience of a "broken upgrade".
This is a conflict which cannot be resolved by achieving both goals,
we have to decide to either keep the strict concept or improve the
situation for early adopters.
In this patch, we address the issue by providing a uci-defaults
script that will raise the compat_version for _all_ people upgrading
into a 1.1 image, no matter whether they have reset config or not.
The idea is to implement this as a _temporary_ solution, so early
adopters can upgrade into the new mechanism without issues, and
after a few weeks/months we could remove the uci-defaults script
again.
If we e.g. remove the script just before 20.xx.0-rc1, early adopters
should have moved on by then, and existing stable users would still
get the intended experience.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Diffstat (limited to 'target/linux/mvebu')
| -rw-r--r-- | target/linux/mvebu/cortexa9/base-files/etc/uci-defaults/05_fix-compat-version | 21 |
1 files changed, 21 insertions, 0 deletions
diff --git a/target/linux/mvebu/cortexa9/base-files/etc/uci-defaults/05_fix-compat-version b/target/linux/mvebu/cortexa9/base-files/etc/uci-defaults/05_fix-compat-version new file mode 100644 index 0000000000..5965fdc2f5 --- /dev/null +++ b/target/linux/mvebu/cortexa9/base-files/etc/uci-defaults/05_fix-compat-version @@ -0,0 +1,21 @@ +# +# Copyright (C) 2020 OpenWrt.org +# + +. /lib/functions.sh + +case "$(board_name)" in + linksys,wrt1200ac|\ + linksys,wrt1900ac-v1|\ + linksys,wrt1900ac-v2|\ + linksys,wrt1900acs|\ + linksys,wrt3200acm|\ + linksys,wrt32x|\ + solidrun,clearfog-base-a1|\ + solidrun,clearfog-pro-a1) + uci set system.@system[0].compat_version="1.1" + uci commit system + ;; +esac + +exit 0 |