Einsprung in Config-Mode / upgrade-Skripts

Moin,

an welcher Stelle springt Gluon eigentlich wie in den Configmode und wann und wo werden die /lib/gluon/upgrade-Skripte gestartet? Ich finde in /ect/rc.d/* keine Hinweise, und in der Doku findet sich auch nix konkretes?

Wichtig hier: config-mode → Webinterface ; setup-mode → Der Zustand in dem sich das Gerät im Konfigurationszustand befindet.

Setup mode wird im preinit hier gestartet: https://github.com/freifunk-gluon/gluon/blob/master/package/gluon-setup-mode/files/lib/preinit/90_setup_mode

Hier beim config-mode reboot:

Und hier beim upgrade:

1 „Gefällt mir“

Danke für diesen – wichtigen – Hinweis.

Hintergrund: wir haben eine prä-Gluon-, dann lose an Gluon-Entwicklungen weiterentwickelte und nun aufgegebene, Firmware geerbt und möchten eine Gluon-basierte Migrations-FW bauen, die über bestehende Updatemechanismen die knapp 200 Bestandsknoten gen Gluon – und auf gewartete Infrastruktur – befördert.

Gluon soll also per sysupgrade ein ›anderes OpenWrt‹ aktualisieren — an sich relativ easy: Gluon müßte nur alle »Gluon-Firstboot«-Schritte durchführen – das scheint mir in upgrade/* zu geschehen? – und anstatt das formal unkonfigurierte System in den Setup-Mode (und in der Folge ins Config-Mode-Webinterface) zu schicken, setze ich in einem setup-mode/rc.d/S14-migrate-Skript die Parameter skriptgesteuert, die sonst der User eintragen würde; Koordinaten, Community, Knotennamen, Owner, TC-Einstellung sind ja aus der bisherigen Installation vorhanden und es ist auch bekannnt, wo das per UCI gesetzt/geändert werden muß.

Soweit die Theorie.

Die Praxis: setup-mode/rc.d/S14-migrate guckt aktuell, ob die alt-Firmware-Konfigdatei /etc/config/freifunk existiert und falls ja, benennt es diese in /etc/config/freifunk-old um, löscht nicht relevante, übernommene Konfigurationsdateien im Overlay (cd /overlay/upper/etc/config && /bin/rm -rf batman-adv autoupdater alfred dhcp fastd firewall network simple-radvd system wireless gluon*) und rebootet (/etc/init.d/done boot; reboot).

Im nächsten Schritt wird auf /etc/config/freifunk-old getestet und die relevanten Daten werden per uci-Aufruf übertragen, /etc/config/freifunk-old in /root/freifunk.legacy umbenannt (finale Version: gelöscht), gluon-setup-mode.@setup_mode[0].configured auf 1 gesetzt und nochmals rebootet.

Allein: im vorigen Schritt sperrt sich UCI (Ausgabe des Skripts nach »set -x«):

+ uci -q get 'simple-tc.@interface[0].enabled'
+ TCENABLED=1
+ '[' 1 '=' 1 ]
+ uci set 'gluon.mesh_vpn.limit_enabled=1'
uci: Invalid argument
+ :
+ uci -q get 'simple-tc.@interface[0].limit_ingress'
+ uci set 'gluon.mesh_vpn.limit_ingress=50000'
uci: Invalid argument
+ :
+ uci -q get 'simple-tc.@interface[0].limit_egress'
+ uci set 'gluon.mesh_vpn.limit_egress=10000'
uci: Invalid argument
+ :
+ uci -q get 'freifunk-old.@settings[0].name'
+ /bin/pretty-hostname Gluon-Test-3700v1
uci: I/O error
+ uci set 'gluon-setup-mode.@setup_mode[0].configured=1'
+ uci commit
uci: I/O error
uci: I/O error
uci: I/O error

Das ist eher kontraproduktiv; irgendeine Idee, wie man das umschifft?

1 „Gefällt mir“

„uci: I/O error“ kenne ich eigentlich nur von angeknackstem (oder vollem :wink: Overlay-fs

Alles was in Richtung „invalid argument“ geht: Wenn der „darüberliegende“ Schlüssel (also meist die entsprechende Config-Datei oder der Bereich im Configfile) noch gar nicht existiert, dann gibt es solche „geht nicht“-Meldungen.

Voll ist es nicht, angeknackst schein’s auch nicht — /etc/config/freifunk kann ich ja umbenennen und auch ein Logfile nach /root schreiben. Aber UCI ist unpäßlich, ich kann Sachen per ucí set setzen und mit uci show bzw. uci export die Daten auch sehen — selbst ein uci export gluon-node-info | grep -v ^package >/tmp/file && cat /tmp/file >/etc/config/gluon-node-info gibt keine Fehler — nach dem Reboot sind die Änderungen aber wieder weg.

Ulkigerweise bin ich dann ja im normalen Setup-Mode ( uci set gluon-setup-mode.\@setup_mode\[0\].configured=1' wird ja nicht gespeichert), und dann zickt UCI nimmer rum. Löse es jetzt mit uci export $i >/root/$i.export in Phase 2 und uci import $i </dev/null ; uci commit $i ; uci import $i </root/$i.export ; uci commit $i in Phase 3. Wahrscheinlich wäre eine ähnliche Schleife (uci import $i </dev/null ; uci delete $i ; uci commit $i) statt des rm -rf in /overlay/upper/etc/config in Phase auch ausreichend und dann würde es in Phase 2 schon funktionieren? Mal testen …

1 „Gefällt mir“