# Mi4ag-migration.patch **URL:** \ **Category:** Gluon\ **Created:** [29. Juli 2025 um 23:01 UTC](https://forum.freifunk.net/t/mi4ag-migration-patch/24468 "2025-07-29T23:01:01Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![wusel](https://forum.freifunk.net/user_avatar/forum.freifunk.net/wusel/32/630_2.png) [@wusel](https://forum.freifunk.net/u/wusel)\ **Post date:** [29. Juli 2025 um 23:01 UTC](https://forum.freifunk.net/t/mi4ag-migration-patch/24468/1 "2025-07-29T23:01:01Z")
Fortsetzung der Diskussion von [ER-X von v2022.1.3 auf v2023.1.2 "incompatible"?](https://forum.freifunk.net/t/er-x-von-v2022-1-3-auf-v2023-1-2-incompatible/24466/4): > [@ER-X von v2022.1.3 auf v2023.1.2 "incompatible"?](https://forum.freifunk.net/t/er-x-von-v2022-1-3-auf-v2023-1-2-incompatible/24466/4): > > Abhilfe (für remote-Upgrade ohne SSH&Co): Nochmal eine „alte“ Firmware bauen (in Deinem Fall dann wohl 2022.1.3), mit so einem Patch hier. (Weil der Check leider von der alten Firmware durchgeführt wird, nicht von der neuen. Liste von Gründen erspare ich uns hier mal.) Und dann der Link auf [firmware/patches/mi4ag-migration.patch at e6f3b60b4e8c6c6e7d62e745791c2f7ab12d51d6 · eulenfunk/firmware · GitHub](https://github.com/eulenfunk/firmware/blob/e6f3b60b4e8c6c6e7d62e745791c2f7ab12d51d6/patches/mi4ag-migration.patch) — 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 Lt. [anderem Thread](https://forum.freifunk.net/t/dsa-migration-xiaomi-mi4a-gigabit-21-1-x-zu-22-1-x/24258/3) 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? > [@DSA Migration Xiaomi Mi4A-Gigabit (21.1.x zu 22.1.x)](https://forum.freifunk.net/t/dsa-migration-xiaomi-mi4a-gigabit-21-1-x-zu-22-1-x/24258/4): > > 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) 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? ---
**Author:** ![adorfer](https://forum.freifunk.net/user_avatar/forum.freifunk.net/adorfer/32/17910_2.png) [@adorfer](https://forum.freifunk.net/u/adorfer)\ **Post date:** [31. Juli 2025 um 14:57 UTC](https://forum.freifunk.net/t/mi4ag-migration-patch/24468/2 "2025-07-31T14:57:50Z")
> [@wusel](#): > > 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ß)? 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. ---
**Author:** ![wusel](https://forum.freifunk.net/user_avatar/forum.freifunk.net/wusel/32/630_2.png) [@wusel](https://forum.freifunk.net/u/wusel)\ **Post date:** [31. Juli 2025 um 16:00 UTC](https://forum.freifunk.net/t/mi4ag-migration-patch/24468/3 "2025-07-31T16:00:29Z")
FTR: die Kollegen bereite einen Knotentausch vor, um einen ER-X zum experimentieren/eruieren, was da los ist, zu haben, hoffentlich zum Wochenende … ---
**Author:** ![adorfer](https://forum.freifunk.net/user_avatar/forum.freifunk.net/adorfer/32/17910_2.png) [@adorfer](https://forum.freifunk.net/u/adorfer)\ **Post date:** [31. Juli 2025 um 16:01 UTC](https://forum.freifunk.net/t/mi4ag-migration-patch/24468/4 "2025-07-31T16:01:59Z")
Berichte auf jeden Fall! Denn „Communities mit semi-alter Firmware integrieren“ ist durchaus ein Usecase, den wir noch häufiger haben werden. ---
**Author:** ![wusel](https://forum.freifunk.net/user_avatar/forum.freifunk.net/wusel/32/630_2.png) [@wusel](https://forum.freifunk.net/u/wusel)\ **Post date:** [31. Juli 2025 um 17:13 UTC](https://forum.freifunk.net/t/mi4ag-migration-patch/24468/5 "2025-07-31T17:13:40Z")
Will do, wobei … Ich habe Fragen: > [@ER-X von v2022.1.3 auf v2023.1.2 "incompatible"?](https://forum.freifunk.net/t/er-x-von-v2022-1-3-auf-v2023-1-2-incompatible/24466/4): > > Passierte leider beim ERX auch bei 2023.1.x auf 2023.2.x, wenn es eine „von 2021.1.x geerbte Config“ ist. > [@ER-X von v2022.1.3 auf v2023.1.2 "incompatible"?](https://forum.freifunk.net/t/er-x-von-v2022-1-3-auf-v2023-1-2-incompatible/24466/13): > > v2022.1 und v2023.1 sind derselbe OpenWrt Release. > In Gluon werden beide Releases so gepatcht, dass sie compat version 1.0 haben sollten (für ein Upgrade von v2021.1 und früher, wo es `--ignore-minor-compat-version` noch nicht gab) > OpenWrt selber hätte sonst in beiden Releases compat version 1.1 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 😉 ---
**Author:** ![Djfe](https://forum.freifunk.net/user_avatar/forum.freifunk.net/djfe/32/26862_2.png) [@Djfe](https://forum.freifunk.net/u/Djfe)\ **Post date:** [31. Juli 2025 um 23:29 UTC](https://forum.freifunk.net/t/mi4ag-migration-patch/24468/6 "2025-07-31T23:29:09Z")
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? 🙂 ---
**Author:** ![Djfe](https://forum.freifunk.net/user_avatar/forum.freifunk.net/djfe/32/26862_2.png) [@Djfe](https://forum.freifunk.net/u/Djfe)\ **Post date:** [31. Juli 2025 um 23:30 UTC](https://forum.freifunk.net/t/mi4ag-migration-patch/24468/7 "2025-07-31T23:30:27Z")
> Kann dieser patch nicht ausgebaut werden, wenn ihr den neuesten Commit vom branch baut? den wndrmac v2 gibt es dort (würde zurückportiert) > ---
**Author:** ![wusel](https://forum.freifunk.net/user_avatar/forum.freifunk.net/wusel/32/630_2.png) [@wusel](https://forum.freifunk.net/u/wusel)\ **Post date:** [1. August 2025 um 00:48 UTC](https://forum.freifunk.net/t/mi4ag-migration-patch/24468/8 "2025-08-01T00:48:05Z")
> [@Djfe](#): > > Kann dieser patch nicht ausgebaut werden, wenn ihr den neuesten Commit vom branch baut? 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](https://gluon.readthedocs.io/en/latest/releases/v2023.2.3.html) wieder dabei, in [v2023.1](https://github.com/freifunk-gluon/gluon/blob/v2023.1/targets/ath79-generic) 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. ---
**Author:** ![wusel](https://forum.freifunk.net/user_avatar/forum.freifunk.net/wusel/32/630_2.png) [@wusel](https://forum.freifunk.net/u/wusel)\ **Post date:** [1. August 2025 um 01:44 UTC](https://forum.freifunk.net/t/mi4ag-migration-patch/24468/9 "2025-08-01T01:44:05Z")
> [@Djfe](#): > > Bisher habt ihr ja nur sysupgrade ohne Option probiert, oder? 🙂 Ja, siehe [dort](https://forum.freifunk.net/t/er-x-von-v2022-1-3-auf-v2023-1-2-incompatible/24466/19) . ---
**Author:** ![Djfe](https://forum.freifunk.net/user_avatar/forum.freifunk.net/djfe/32/26862_2.png) [@Djfe](https://forum.freifunk.net/u/Djfe)\ **Post date:** [1. August 2025 um 09:07 UTC](https://forum.freifunk.net/t/mi4ag-migration-patch/24468/10 "2025-08-01T09:07:03Z")
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 😅 das will auch keiner ---
**Author:** ![wusel](https://forum.freifunk.net/user_avatar/forum.freifunk.net/wusel/32/630_2.png) [@wusel](https://forum.freifunk.net/u/wusel)\ **Post date:** [1. August 2025 um 12:20 UTC](https://forum.freifunk.net/t/mi4ag-migration-patch/24468/11 "2025-08-01T12:20:29Z")
> [@Djfe](#): > > Ihr baut also nicht ganz den neuesten Stand, befürchte ich. Darum der Hinweis. 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 😉