Mi4ag-migration.patch

Technik Gluon
1

Fortsetzung der Diskussion von ER-X von v2022.1.3 auf v2023.1.2 "incompatible"?:

Und dann der Link auf firmware/patches/mi4ag-migration.patch at e6f3b60b4e8c6c6e7d62e745791c2f7ab12d51d6 · eulenfunk/firmware · GitHub — der mich vor Probleme stellt.

Aber vorher die Ausgangslage:

  • Ich habe 3 Xiaomi Mi Router 4A Gigabit — die sind im Patch ja auch genannt, aber auf die würde ich erst einmal sch…^H^H^H^H^H mit dem Verweis auf einen bedauerlichen Einzelfall reagieren

  • Ich habe dann

    • 57 UBNT-ERX, also gluon-v2021.1
    • 4 UBNT-ERX-SFT, dito
    • 18 Ubiquiti EdgeRouter X, gluon-v2022.1.3, gluon-v2022.1.4 und gluon-v2023.2.5 (Ziel)
    • 4 Ubiquiti EdgeRouter X SFP, gluon-v2022.1.4 und gluon-v2023.2.5 (Ziel)

    wobei es Firmwares von 2 Communties sind, die gerade mergen …

Lt. anderem Thread ist v2021 gar nicht betroffen? Oder muß ich das genau da einbauen, damit es auch für ER-X glatt von v2021.1 zu v2023.1 geht?

Die Mi4Agiga sind mir wie gesagt eher egal — die ER-X zwar auch, aber der Impact wäre so groß, daß es gerechtfertigt ist zu sinnieren, ob/wie ER-X mit v2021.1 und v2022.1 problemlos per Autoupdater nach v2023.1 kommen.

Als kurz gefragt: ich verstehe daß so, daß die jeweilige Bestandsfirmware (ab einschließlich Gluon v2022, aber nicht darunter) OpenWrts fwtool patchen muß, damit eine folgende Firmware per Autoupdater aufgespielt werden kann (welche für zukünftige Updates den Patch ebenso haben muß)? Richtig durchschaut?

2

Ja.

Sinnvoll ist die Aktion natürlich nur, wenn so ein Update (nach derzeitigem Stand mit „-f“ geforced auf der Shell) wieder zu einem lauffähig upgedateten Router führt.
Falls so ein Vorab-Test zu einem Router führt, der in einer irgendwie „ungültigen Config“ festhängt (oder gar ungültigen Partitionstabelle im Boot failed), also nicht mehr „online kommt“, dann würde es natürlich nur wenig helfen.
Dann wäre weitere Forschung nötig, was ggf. zustätzlich noch an Vorarbeiten/Migrations-Vorbereitungen in der Alt-Firmware notwenig sind in einer Zwischenupgrade-FW.

3

FTR: die Kollegen bereite einen Knotentausch vor, um einen ER-X zum experimentieren/eruieren, was da los ist, zu haben, hoffentlich zum Wochenende …

1 „Gefällt mir“
4

Berichte auf jeden Fall!
Denn „Communities mit semi-alter Firmware integrieren“ ist durchaus ein Usecase, den wir noch häufiger haben werden.

5

Will do, wobei … Ich habe Fragen:

Irgendwas paßt da nicht, wenn die Aussage von @Djfe korrekt ist – woran ich nicht zweifele – und, so verstehe ich es jedenfalls, in v2022.1 und v2023.1 (und dann, würde ich erwarten, auch in v2023.2?) die compat version beim ER-X auf 1.0 gepatcht wird, dann dürfte es bei Euch ja nicht geknatscht haben?

Und auch bei uns war/ist das Problem ja, von (lippischer) v2022.1.3+ auf unsere v2023.1 zu gehen, Ergebnis: upgrade: The device is supported, but the config is incompatible to the new image (1.1->1.0). Please upgrade without keeping config (sysupgrade -n). Image check failed.

Demnach fehlt der lippischen v2022.1.3+ dieser Patch, siehe Aussage von Felix. Ich wiederum habe den entsprechenden Gluon-Patch – der kann kann ja nur unter gluon/patches/openwrt bzw. gluon/patches/packages liegen, oder? – bislang nicht gefindet, daher glaube ich kaum, daß der (leider verstorbene) Firmwärebäcker der lippischen 1.6/v2022.1.3+ explizit jenen ausgebaut hatte.

Frage über Fragen :wink:

6

Versuch herauszufinden ob es nicht doch mit sysupgrade und der Option bzw. dem Autoupdater funktioniert. Bisher habt ihr ja nur sysupgrade ohne Option probiert, oder? :slight_smile:

7

Kann dieser patch nicht ausgebaut werden, wenn ihr den neuesten Commit vom branch baut?

den wndrmac v2 gibt es dort (würde zurückportiert)

8

Nun, wir hatten den seit v202x drin, als er wegen fehlender Formalie rausflog. Wir hatten halt so 10 oder so davon, daher war das rauswerfen ein no-go für uns (wie auch der geforderte Weg von der Vendor-FW zu Gluon; man kann’s auch übertreiben mit den Korinthen; anderes Thema). Anyway, wir haben die Patches rübergezogen und die, die failten, entweder angepßt oder gedroppt. Frage mich, warum der keinen Fehler schmiß …

Ah, weil Deine Referenz ›v2023.1.x‹ falsch ist: der ist erst seit v2023.2.3 wieder dabei, in v2023.1 gerade nicht! (Auch deshalb nutze ich keine Branches und Tags sondern Verzeichnisse/eigene Repos. Anderes Thema.)

Also nein, der Patch kann für unseren v2023.1.x-Build nicht raus.

9

Ja, siehe dort
.

10

Es ging mir ja darum, darauf hinzuweisen, dass das neueste v2023.1 den wohl drin hat (nach dem letzten Release Tag, einfach nur der branch v2023.1)
Ihr baut also nicht ganz den neuesten Stand, befürchte ich. Darum der Hinweis.

Das war damals nicht eine fehlende Formalie sondern der Wechsel des Targets ar71xx auf ath79, wo das Gerät neu hinzugefügt wurde. Der erneute Test war nötig, weil dabei mit andern Geräten schon diverse Kleinigkeiten aufgefallen sind, die bei der Übertragung von mach c files nach dts schief gegangen sind.
Sonst bauste halt gluon Firmware für die Tonne und Leute regen sich auf, warum solche Sachen nicht vorher aufgefallen sind :sweat_smile: das will auch keiner

11

Nö, eigentlich soll es mehr und mehr in Richtung »use the most recent release instead« gehen … Aber da’s einen eigenen Patch erspart, ab nun also v2023.1.x statt v2023.1.2 :wink:

1 „Gefällt mir“