[openwrt/openwrt] kirkwood: fix sysupgrade experience for early DSA-adopters

LEDE Commits lede-commits at lists.infradead.org
Sat Aug 8 10:14:15 EDT 2020


adrian pushed a commit to openwrt/openwrt.git, branch master:
https://git.openwrt.org/86c89bf5e8f570214371824587b38220cf05bdac

commit 86c89bf5e8f570214371824587b38220cf05bdac
Author: Adrian Schmutzler <freifunk at adrianschmutzler.de>
AuthorDate: Thu Aug 6 14:59:51 2020 +0200

    kirkwood: 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. at 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 at adrianschmutzler.de>
---
 .../base-files/etc/uci-defaults/05_fix-compat-version    | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/target/linux/kirkwood/base-files/etc/uci-defaults/05_fix-compat-version b/target/linux/kirkwood/base-files/etc/uci-defaults/05_fix-compat-version
new file mode 100644
index 0000000000..d7f8488e88
--- /dev/null
+++ b/target/linux/kirkwood/base-files/etc/uci-defaults/05_fix-compat-version
@@ -0,0 +1,16 @@
+#
+# Copyright (C) 2020 OpenWrt.org
+#
+
+. /lib/functions.sh
+
+case "$(board_name)" in
+	linksys,e4200-v2|\
+	linksys,ea3500|\
+	linksys,ea4500)
+		uci set system. at system[0].compat_version="1.1"
+		uci commit system
+		;;
+esac
+
+exit 0



More information about the lede-commits mailing list