aboutsummaryrefslogtreecommitdiffstats
path: root/target/linux/mvebu
diff options
context:
space:
mode:
authorAdrian Schmutzler <freifunk@adrianschmutzler.de>2020-08-06 14:43:16 +0200
committerAdrian Schmutzler <freifunk@adrianschmutzler.de>2020-08-08 16:13:51 +0200
commita9703db72030a43c5a22f02411d3680ba2e2faf3 (patch)
tree6126704b0c8663aebe3a7a94b59b6b4007d7b77c /target/linux/mvebu
parentde78747de111ba5e4c978fe8067b2260efe01d0d (diff)
downloadupstream-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-version21
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