Hmm, beim Upgradeversuch eines Edgerouters X von einem gluon-v2022.1.3+ auf ein v2023.1.2+ wurde mir gerade folgendes berichtet:
root@node:/tmp# sysupgrade gluon-ffff-1.2.3~4-ubiquiti-edgerouter-x-sysupgrade.bin
Sun Jul 27 18:59:13 CEST 2025 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.
Jemand 'ne Idee, wo DAS herkommt?
Sollte das nicht mit einem --ignore-minor-compat-version (oder update über autoupdater) zu lösen sein?
Vermutlich steckt die DSA migration dahinter?
Größerer Spaß wird wohl beim Upgrade auf das kommende Gluon Release mit openwrt-24.10 notwendig sein:
Da bin ich mal gespannt drauf.
Dunno, kenne das ER-X-Zeuch, ist in einigen unserer Gruppen aber (leider) recht verbreitet; ich geb’ das mal weiter.
Aber:
„1.1->1.0“ klingt für mich, als ob die fragliche v2022.1.3+ Version 1.1 hätte, v2023.1.2+ aber 1.0 der „config“? Und das wäre schräg, da Downgrade, oder?
Ja, kann ich bestätigen.
Passierte leider beim ERX auch bei 2023.1.x auf 2023.2.x, wenn es eine „von 2021.1.x geerbte Config“ ist.
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.)
Kann das eventuell an dem zu kleinen Bereich liegen, in dem der Kernel gespeichert wird (3MB)?
Danke!
v2021.1.2.1 bei uns, leider sind einige ERXe auch auf einer jetzt eigentlich übersprungen werden sollenden v2022.1.4, das wird ja ein richtig nerviger Spaß. Und warum haben die Kisten zwischen v2021 (UBNT-ERX) und v2022 (Ubiquiti EdgeRouter X) den Namen geändert? Naja, jetzt ganz praktisch zum raussuchen, wieviele Systeme betroffen sind …
Nein. Es liegt am Imagecompat-String, weil der schon auf 1.1 ist, die Firmware aber eine 1.0 erwartet.
Siehe Ausgangspost:
„The device is supported, but the config is incompatible to the new image (1.1->1.0). Please upgrade without keeping config (sysupgrade -n).“
Falls Du eine „Schuldzuweisung“ durchführen möchtest, dann würde ich mal in Richtung „Regression-Testing seitens der Communities“ schauen.
Ich hatte neulich einen ER-X upgraden wollen und hatte die gleiche Meldung erhalten. Ein erzwungenes sysupgrade -n hinterliess zunächst leider nur einen Backstein.
Kannst Du das bestätigen @wusel?
⇒ Habe keinen im Zugriff und nach dem, was ich in dieser Woche erfahren habe, werde ich um diese Kisten auch weiterhin einen weiten Bogen machen. Die Mistdinger haben schon Zeit gekostet beim Update des Uelzener Netzes auf v2021.1 und ich bin kein Freund von solchen Pflänzlein, die schein’s nun bei jedem Update eine Meinung zu haben meinen wollen …
Ich gehe momentan auch davon aus, daß sie in Gluon-Next nicht unterstützt werden mangels Upgradepfad – Statement von Gluon-Entwicklern wäre interessant – und bereite mich (und demnächst die Nutzenden) darauf vor, daß ER-X & Anverwandte mit unserem Gluon v2023.2 auf’s Abstellgleis geschoben werden (Firmwarebranch ›deadend‹, wo schon 841er und Nanostations gelandet sind). Kannste dann neu installieren, aber die Altlasten laufen weiter statt ins Essen zu brechen (weil sie die Version nach v2023.2 nicht mehr zu sehen bekommen).[1]
Ja, sorry, ich bin gerade etwas angepißt, daß es ist, wie es ist und damit das Update v2021.x → v2023.1 → v2023.2 für rd. 2k Knoten wegen einem knappen Hundert Mimosen-Geräten auf unbestimmte Zeit aufgehalten wird (sind halt i. d. R. Offloader, high impact also). Bei allem Frust, Dank insbesondere an @adorfer für den Link zum Patch (Thread folgt).
Nein, es gibt keine Regeln auf dem FW-Server, wer was sieht. Das Leben ist zu kurz für so einen Quark. YMMV. ↩︎
Verlorene Configs hatten wir auf „unserem Weg“ nicht bei den ERX, aber wir sind gesprungen von 2021.1.x zu 2023.1 zu 2023.2, waren also nie auf einer 2022.x
(Und den ERX-SFP hatte ich nicht mit reingenommen in den Patch, weil auf den einzigen davon hatte ich SSH-Zugang)
P.S.: Auf dem Weg von der 2019 zu 2021 gab es mit dem ERX schon was, weil Partitionsschema sich änderte und dann bei Geräten mit Badblocks im EEMC das nur mit „Umwegen“ ging. Was das genau war/was dann gemacht werden musste: Ist so lang her, dass ich es nicht mehr aus dem Stehgreif weiss. Da führte es aber bei „force“ klar zum „Stuck-during-boot“.
Ja, wie gesagt, ER-X haben schon von ›damals‹ (aka Juni/Juli '24) fett negative Punkte gesammelt …
Vergrößerungen der compat version können sehr unterschiedliche Gründe haben. (Kompatibilität)
bei OpenWrt 24.10 ist es aber ein major compat version increase. 1.x nach 2.x
statt 1.0 nach 1.1 oder so (minor)
minor kann man ignorieren, wenn man wie gluon die Netzwerkconfig eh neu aufbaut.
major nicht. major bedeutet, dass sysupgrades fehlschlagen werden. Wieso du die Warnung, die dir sysupgrade mit Text gegeben hat, ignoriert hast, statt danach zu googlen, musst du dir selber beantworten (edit: ist eventuell Quatsch, ich kläre das eben erstmal per PM, sorry für die Behauptung)
Aber Ubiquiti Geräte kann man ja glücklicherweise mit tftp gut recovern 
Freifunk beschäftigt sich noch nicht mit dem major compat Version increase wie du und @fmaurer ihn beschrieben haben, da das erst mit dem kommenden Gluon Release v2025.1 ansteht. Den gibt es bisher nur als Gluon main branch
ich hoffe, das konnte die Fragen beantworten. Das hat das Thema nun leicht in eine falsche Richtung verzerrt
Für mich sieht Wusel’s Problem eher aus wie ein hausgemachtes. (das meine ich völlig ohne Wertung)
Welche eigenen Patches baut ihr derzeit ein? Dann kann ich dein Problem sauberer nachvollziehen.
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
Bleibt die Frage warum eure v2022.1.3 nicht den Patch von Gluon drin hat(te). Adorfer’s patch ist eventuell die einzige Variante da raus, falls der autoupdater wirklich minor compat downgrades nicht ignoriert. (hab ich nie getestet)
Dazu die Frage: wie rollt ihr die Updates aus? Mittels Autoupdater oder mittels sysupgrade/Skript? (letzteres würde nach Problemen schreien, die damals beim Rollout in Gluon längst adressiert wurden)
Dass ein Router mal in OpenWrt bei Aufräumarbeiten umbenannt wird, ist nicht so ungewöhnlich und auch eigentlich kein Problem.
ZyXEL heiĂźen jetzt auch Zyxel seit OpenWrt 24.10
ist das nur bei mir so, dass eure Website im Telekom Festnetz in einen timeout läuft und im Telekom Mobilfunk auf Anhieb funktioniert?
@wusel
Ich kann verstehen, dass du Frust schiebst, aber es ist nicht so als wären die Kisten selbst das Problem. Das waren bisher alles Softwareprobleme.
Ich gehe übrigens davon aus, dass Gluon für ERX auf Dauer einen Upgradepfad realisieren können wird (anders als bei v2019.1.x damals). Es gibt ja im PR ein Skript für sysupgrade, dass die Partitionen anpasst. Das wurde nur in OpenWrt selbst nicht zurückportiert in den alten Release. Aber als Gluon wird man soetwas einbauen können, hoffe ich.
Das Grundproblem der zu kleinen Kernelpartition betrifft übrigens auch weitere Geräte wie die Xiaomi AX3200 (mt7622), aber von denen gibt es weniger. Es gab auch schon früher (OpenWrt 23.05) Linksys Geräte mit demselben Problem, aber die waren damals noch nicht in Gluon.
Ich hatte schlicht vergessen, dass ich ein aktuelles OpenWRT image (24.10.x) über ein Gluon (2023.x.x) image bügeln wollte. Ich bekam jedoch die gleiche (oder sehr ähnliche Meldung zur Kompatibilität).
Nun war auf dem ER-X zuvor bereits ein OpenWRT 24.10.x image (mittels des Migrationspatches). Meine Annahme war, dass man dann keine zweite Migration braucht, wenn das Skript bereits einmal lief.
Vielleicht war das der Grund fĂĽr den Backstein.
Nunja, immerhin ist’s hier ja nicht unbekannt; die Suchmaschinenantworten auf die Fehlermeldung waren eher … unspezifisch.
site-ffgt-v2023.2/patches at v2023.2.x · ffgtso/site-ffgt-v2023.2 · GitHub für unsere 2.0/v2023.2-based, site-ffgt-v2023.1/patches at stable · ffgtso/site-ffgt-v2023.1 · GitHub für unsere 1.9/v2023.1-based, die unsere 1.4/v2021.1-based sowie Lippes 1.5.2-20220507 / gluon-v2021.1.2+, 1.6.0-20230308 / gluon-v2022.1.3+ und 1.7.0-20240418 / gluon-v2022.1.4+ ablösen soll. Lippe baut(e) IIRC weitgehend unmodifiziert.
Das …
root@NnodeLippe:/tmp# sysupgrade gluon-4830-1.9.0\~12-ubiquiti-edgerouter-x-sysupgrade.bin
Sun Jul 27 18:59:13 CEST 2025 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.
… stammt vom Versuch, per sysupgrade einen ER-X von lippischer 1.6/v2022.1.3+ auf unsere 1.9/v2023.1 zu bringen.
Deinen Ausführungen und der Fehlermeldung nach fehlt der eher in der v2022.1.3er Ausgangsfirmware von Lippe? (1.1->1.0) paßt ja auf »Gluon beide 1.0, OpenWrt beide 1.1«?
Generell via Autoupdater; der hat fĂĽr Lippe aber unsere 1.4er als lippische 1.5.9er (weil wir ja die 4/32-Kisten dort auch migrieren mĂĽssen), daher hat der Kollege das per sysupgrade versucht.
Yepp, EA/MR8300, die hatten wir in unserer v2022-based drin und machten da die entsprechenden Änderungen via upgrade-Skript. Aber da wir v2022 nun komplett übersprigen weiß ich auch nicht so recht … Aber das ist ein völlig anderes Thema 
Ich vermute, jener Patch ist (u. a) dieser und der relevante Change ist
- $(Device/dsa-migration)
sprich die Entfernung jenes OpenWrt-Makefile-Feature (was DEVICE_COMPAT_VERSION auf 1.1 setzt)? In v2023.2.x ist AFAICS der Patch nicht mehr drin, wie wird denn da die Updatebarkeit von DEVICE_COMPAT_VERSION 1.0 (prä-v2023.2) auf 1.1 (augenscheinlich ab v2023.2 mangels Patch?) sichergestellt? Found it, autoupdater nutzt --ignore-minor-compat-version, danke für’s Stichwort. Allerdings ist jener Patch in autoupdater.c der Version, die mit gluon-v2022.1.3+ gebaut werden sollte schon drin — dann dürfte es die Meldung 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). ja gerade nicht geben?
1.7.0-20240418 wo liegt denn die site hierfĂĽr? (v2022.1.3+)
habt ihr mittlerweile getestet ob ein Update mittels autoupdater erfolgreich ist? Oder was sprach dagegen. Das hab ich bisher nicht verstanden
Alternativ welche Fehlermeldung liefert
sysupgrade --ignore-minor-compat-version file
genau das, aber ich weiß gerade noch nicht ob das wirklich ein Problem ist. Updates rollt ihr ja normal nicht manuell aus und ansonsten sollte es ja kein Problem sein, --ignore-minor-compat-version zu verwenden wie es eben nötig ist
Die Migration passt die Partitionen auf dem Flash an. Die Partitionstabelle ist aber Teil des Betriebssystems (mtd partitionen werden in device trees definiert: dts). Ich bin höchst erstaunt, dass gluon nicht schon beim downgrade gecrasht ist beim booten. (also v2023.2 installieren nach openwrt 24.10)
nur modernere hw wie filogic nutzt dynamische Partitionstabellen von ubi und ubifs. Da sieht das dann wieder anders aus und solche Partitionen werden nicht vom Betriebssystem definiert
Dagegen spricht, daß der fragliche Knoten im Feld steht bei einer öffentlichen Instution. Die Kollegen habe ein Replacement zum Austausch bereitgestellt und werden ASAP an dem Standort den ER-X gegen einen NanoPi R4S tauschen. Dann kann mit dem ER-X experimentiert werden …
autoupdater wird ein Problem bleiben: die 1.6.0-20230308 / gluon-v2022.1.3+ steht noch nicht zur Migration an, auf dem Fake-Updateserver bieten wir nur eine korrekt signierte 1.5.9 den lippischen 1.5.0/v2021.1.x-Knoten an, was unserer 1.4.0/v2021.1.x entspricht.
Erst wenn die Migration der lippischen v2021-Knoten auf unsere v2021 durch ist (und damit alle nicht mehr supporteten Knoten im ›deadend‹-Branch gelandet sind), würden wir den lippischen Knoten unsere 1.9/v2023.1 anbieten.
That said: ich kann mir aktuell die compat version 1.1 bei der lippischen v2022-ERX-FW nicht erklären, aber was ich die letzten Tage recherchiert habe, ist das alles wohl nur ein der Unwissenheit geschuldetes Faßöffnen gewesen — sorry for that. Da ab Gluon v2023.1 die /etc/config/networks von Gluon rebuilded wird, werden aufgrund der eingeschränkten Optionen die meisten swconfig-zu-DSA-Upgrades funktionieren. Spezialkonfugurationen brechen ins Essen, aber damit muß man rechnen, wenn man »under the hood« arbeitet; Gluon ist eben nicht OpenWrt. Der autoupdater verwendet ab mind. v2022.1.3 --ignore-minor-compat-version, hätte – AFAICS – also das Update von v2022 auf v2023.1 gemacht.
DafĂĽr sprich auch, daĂź 7 ERX schon zu Ubiquiti EdgeRouter X wurden und glĂĽcklich mit unserer 2.0/v2023.2.x laufen.
Alles klar dann warten wir solange 
ihr könnt den autoupdater auch manuell mit einer andern URL starten wo eine signierte v2023.1 liegt (in einem anderen Ordner auf demselben Server z. B.)
und man kann dem autoupdater sagen per Parameter, dass weniger Signaturen reichen
also ein Kommando zum Copy&Pasten für Leute die früher hochaktualisieren möchten, mit dem man Knoten manuell updaten kann ohne die Tücken, die auftreten, wenn man das sysupgrade Tool direkt benutzt.
da wird dann auch automatisch das richtige Image gewählt, selbst wenn der Gerätename jetzt anders heißt. All sowas