Ich bin für den Firmwarebau von Gluon2022.1.x auf der Suche nach DSA-Migrationsscripten für den Xiami Mi4A-gigabit.
Da einige andere Communities (siehe vor-thread) diese auch schon im Einsatz hatten und diese inzwischen auf höheren Gluon-Versionen sind habe ich zumindest die Hoffnung, dass irgendwer anders da schon was hat, um das Rad kein zweites Mal zu erfinden.
Was für die Migration prinzipiell gemacht werden muss und wie solche Patches in die Buildchain gehören ist mir prinzipiell klar. Es würde z.B. schon helfen, falls wer die Unterschiede in den pci-pathes vom Wifi, von den LEDs und der Switchconfig noch irgendwo hat.
(Ich bitte auf wenig sachdienliche Hinweise, z.B. „warum jetzt erst“ oder „haben die Leute eben Pech gehabt“ zu verzichten.)
Die Änderung an fwtool_check_image() bringt glaub ich hier gar nichts.
Weil die greift ja erst, wenn das Update bereits installiert ist.
Router mit v2021.1.x oder v2020.1.x haben die Änderung ja gar nicht und kennen ignore minor compat leider auch noch nicht.
die Änderung an der image makefile ist das relevante, weil die die Änderung entfernt, die ins sysupgrade file reinschreibt (metadata), dass das Update die compat Version erhöht auf 1.1
wenn man das entfernt, nehmen alte Geräte das sysupgrade an, ohne zu meckern, dass die compat Version erhöht wurde.
minor compat increases sind für Gluon irrelevant, da gluon (zumindest ab v2022.1.x) die Netzwerk config neu erzeugt und damit keine Artefakte entstehen oder (hier relevant) die alte swconfig übrig bleibt, wenn das neue Betriebssystem auf DSA setzt. (dynamic switch architecture)
Das fwtoolcheckimage war hier die Lösung, um nicht in einer Sackgasse zu landen. Gibt sicher auch andere Lösungen. Hast Du eine?
Um es nochmal zu erläutern: Geräte, die bereits ein Gluon 2022.1.x haben sollen auch noch ggf. nötige zwischenupdates auf ein weiteres 2022.1.x erhalten können. Und zwar OHNE dass ich den ersten Patch entferne. Denn das würde „noch verbliebene“ 2021.xer-Mi4Agiga abhängen.
Alternativ müsste man diesen Nachzüglern noch eine Zwischenfirmware separat hinlegen und eine rewrite-Rule-Sonderlocke im FW-Server lassen. Und das möchte in SEHR vermeiden, nicht nur wegen des Speicherbedarfes in Ermangelung von Multidomain-Firmware (anderes Thema)