Firmware Modul, das den Autoupdater Branch auf "stable" setzt


#1

Ich habe mal ein Modul eingebaut, das automatisch beim Firmware Upgraden aufgerufen wird, und ein Script aufruft das den Updater Branch auf “stable” setzt.

Einfach dieses Modul includen: https://github.com/freifunk-kiel/ffki-packages/blob/master/gluon-au-change/

Das Script macht nichts weiter außer dass es /lib/gluon/upgrade/100-au-change auf dem Router erstellt


Firmware Änderungswunsch: WiFi Taste deaktivieren
#2

Wichtig war noch, dass das Script im git schon executable gespeichert ist:

https://github.com/freifunk-kiel/ffki-packages/commit/67ffe553db95684aa144aa5b5d15905d18d44efb

Dann funktionierts auch :smile:


#3

Ich denke der häufigste Fall ist, warum jemand eine experimental firmware nimmt ist, wenn ihr/sein Routermodell noch nicht unterstützt war.

Sollte man dieses Modul nicht ev. immer als standard in die Stable Firmware einbauen?

Dann würde jeder, der die Stable Firmware installiert automatisch den update-branch wieder aus stable gesetzt bekommen und den auto-updater angeschaltet.

(Wenn jemand auf experimental bleiben will, dann kann er den ja weider umstellen im Config mode)

In dem Fall müsste man nur das autoupdater -f am Ende des scripts entfernen, oder?


#4

joa, nette idee - bei Stable geflashten Routern auch stable als branch zu enforcen … das in der Regel sicher besser als umgekehrt (wer trotzdem nen anderen branch will. der weis ja in der Regel was er tut, im gegensatz zu leuten die stable flashen und denken/hoffen “jetzt is alles gut”)
was mir an dem Paket nicht gefällt ist das dort der autoupdater zwangsaufgerufen wird (nachdem man ja in /lib/gluon/upgrade nur deshalb ist weil man gerade neue FW geflasht hat)
und da du das während dem abarbeiten der upgrade skripte aufrufst prognostiziere ich dir mal unerwartete Fehler … da das auch früh läuft. Wenn da mal jemand an einer sehr schnellen Leitung ist und da eher langsame Skripte drinstehen (die erst timeouten müssten) machste an dieser Stelle eher Dinge kaputt … ich empfehle daher 999 statt 100 oder noch besser den autoupdater eben nicht zu starten (wozu auch)


#5

Müssen wir wohl ändern:
https://github.com/freifunk-kiel/ffki-packages/issues/5

Ich hoffe da ist gestern jetzt nichts kaputt gegangen in Kiel. 20 Router haben sich das Update erfolgreich gezogen. Von 2015.2 auf 2016.1.5


#6

Was passiert denn da noch alles nach 100?

Kann mal jemand auf einem Router mit 216.1.5 die Ausgabe von contrib/lsupgrade.sh ( in the Gluon repository) posten? ( Siehe readthedocs)

Ohne den erneuten Autoupdate Aufruf am Ende war 100 aber schon korrekt, oder?

http://gluon.readthedocs.io/en/v2016.1/dev/upgrade.html#script-ordering

Update:

Würden wir im stable Branch gleichzeitig ein weiteres Update durchführen wäre es vielleicht ein Problem. So jedoch nicht.


#7

ne , sowas gehört weit ans Ende … der upgrade kette. Auch wenn einzelne Namen anderes suggerieren.
hier mal unsere lib/gluon/upgrade von einem beliebigem Router mit v2016.1.6++

ls /lib/gluon/upgrade/
001-upgrade                                 300-gluon-mesh-batman-adv-core-wan          400-respondd-firewall
010-primary-mac                             300-setup-mode                              410-mesh-vpn-fastd-generate-secret
020-interfaces                              310-gluon-mesh-batman-adv-core-mesh         420-mesh-vpn-fastd-simple-tc
030-system                                  310-setup-mode-migrate                      500-autoupdater
100-authorized-keys                         320-gluon-client-bridge-wireless            500-enable-alfred
100-dnsmasq                                 320-gluon-mesh-batman-adv-core-wireless     500-node-info-system
100-lock-password                           320-setup-ifname                            500-opkg
110-network                                 330-gluon-mesh-batman-adv-core-mesh-on-wan  500-radvd-remove-user
120-ntp-servers                             340-gluon-mesh-batman-adv-core-mesh-on-lan  500-status-page-api
130-reboot-on-oom                           350-gluon-mesh-batman-adv-14                510-node-info-role
140-firewall-rules                          350-gluon-mesh-batman-adv-core-rssid        511-update-etc-profile
150-poe-passthrough                         400-mesh-vpn-fastd                          520-node-info-whitespace-fix
200-wireless                                400-neighbour-info-firewall                 998-commit
300-gluon-client-bridge-network             400-next-node                               999-version


#8

abgesehen davon wenn du das Paket default in stable reinmachst provozierst du u.Umständen auch einen loop - da die version erst mit 999-version gesetzt wird, hat der router so lange die alte version, gegen diese Nummer checkt aber dein 100-whatever script … und denkt, da denkt autoupdater -f dann er hat eine neuere version gefunden und installiert die, wenn die wieder dein 100’er script hat, dann gehts von vorne los.
(wegen dem enforcten autoupdater im upgrade prozess)


#9

Ich habe das erneute update am Ende rausgenommen und die nr auf 100 gelassen. as Paket im Kieler repo stellt also nun nur noch den Branch um, sonst nix:


#10

korrigiert mich, falls ich auf dem falschen Dampfer bin, aber in diesem Zustand, sprich wenn man die derzeitig geflashte Versionsnummer prüft, könnte man das package für “immer” aktiv lassen?


#11

Das immer zu aktivieren ist nich t so sinnvoll, vielleicht will man ja auch mal eine experimental version rausbringen, die der stable entspricht, aber später dann doch wieder eine neuere experimental auf den testroutern ausrollen


#12

Du darfst es gerne anders machen - aber bei uns hat auf allen Testroutern hat sowieso jemand SSH-Zugriff, der sich auskennt, entsprechend kann man einfach wieder experimental aktivieren.
Mein Package geht davon aus, dass nur experimental-Versionsnummern zwei Bindestriche enthalten.
Sicher wäre das schöner machbar und v.a. in lua - aber vermutlich funktioniert es so auch :wink: