# Anleitung: Ubiquiti EdgeRouter X (ER-X) auf aktuelles OpenWrt migrieren ## Ausgangslage Der ER-X hat eine sehr kleine, fest reservierte Kernel-Partition (3 MB). Ältere OpenWrt-Versionen (z. B. 22.03.x) passen noch rein, neuere Kernel (6.6+, ab OpenWrt 23.05/24.10) nicht mehr ohne Änderung der Partitionstabelle. Ein normales Sysupgrade/Firmware-Update über die Web-Oberfläche schlägt daher mit folgendem Fehler fehl: ``` upgrade: The device is supported, but this image is incompatible for sysupgrade based on the image version (1.1->2.0). upgrade: Partition table has been changed due to kernel size restrictions. Image check failed. ``` Das ist normal und kein Zeichen eines defekten Geräts – es braucht einen einmaligen Migrationsschritt. ## Voraussetzung - ER-X läuft bereits mit Standard-OpenWrt (nicht mehr originaler Ubiquiti EdgeOS-Firmware) - SSH-Zugriff auf den Router - **Wichtig:** Die Migration setzt das Gerät komplett zurück (alle Einstellungen gehen verloren). Vorher Konfiguration sichern, falls benötigt (Backup über LuCI: System → Backup/Flash Firmware → "Generate archive") ## Ablauf ### 1. Mit dem Router verbinden ``` ssh root@ ``` (Standard-IP bei Werkszustand meist `192.168.1.1`, kann je nach bisheriger Konfiguration abweichen) ### 2. Migrations-Scripts laden Auf dem Router: ``` cd /tmp wget --no-check-certificate https://raw.githubusercontent.com/darkxst/erx-migration/refs/heads/main/ubnt_erx_migrate.sh wget --no-check-certificate https://raw.githubusercontent.com/darkxst/erx-migration/refs/heads/main/ubnt_erx_stage2.sh chmod +x ubnt_erx_migrate.sh ``` Zur Kontrolle prüfen, dass beide Dateien echte Scripts sind (mehrere KB groß, keine HTML-Fehlerseite): ``` ls -la ubnt_erx_migrate.sh ubnt_erx_stage2.sh ``` ### 3. Migration starten ``` ./ubnt_erx_migrate.sh ``` Das Script fragt nach Bestätigung (`y`/`n`) und weist nochmal auf den Datenverlust hin. Nach Bestätigung: - Lädt automatisch das aktuelle OpenWrt-Release (zum Zeitpunkt dieser Anleitung: 24.10.1) für den ER-X - Führt die Neupartitionierung durch - Gerät startet neu – **SSH-Verbindung bricht dabei ab, das ist normal** ### 4. Warten und neu verbinden Nach dem Neustart (ca. 2–3 Minuten) hat der Router in der Regel wieder die Standard-IP `192.168.1.1` (auch wenn vorher eine andere IP konfiguriert war). ``` ping 192.168.1.1 ``` Sobald erreichbar: ``` ssh root@192.168.1.1 ``` **Hinweis:** Der SSH-Host-Key hat sich geändert (neue Installation), daher erscheint eine Sicherheitswarnung. Das ist normal, kein Angriff. Alten Eintrag entfernen: ``` ssh-keygen -f '~/.ssh/known_hosts' -R '192.168.1.1' ``` Danach erneut verbinden. ### 5. Fertig – Grundabsicherung Nach erfolgreichem Login zeigt sich die neue Version, z. B.: ``` OpenWrt 24.10.1, r28597-0425664679 ``` Root-Passwort setzen (Pflicht, da initial keins gesetzt ist): ``` passwd ``` Kontrolle, dass das neue Partitionslayout aktiv ist: ``` grep compat_version /etc/config/system ``` (sollte `2.0` zeigen) ## Ergebnis Der Router läuft jetzt auf aktuellem OpenWrt mit modernem Kernel und neuer Partitionstabelle. Zukünftige Sysupgrades auf neuere OpenWrt-Versionen funktionieren ab hier wieder normal über die Web-Oberfläche oder `sysupgrade`, ohne erneute Migration. ## Quelle Migrations-Scripts von [darkxst/erx-migration](https://github.com/darkxst/erx-migration), siehe auch [OpenWrt-Forum-Thread "Resizing kernel images for Edgerouter X"](https://forum.openwrt.org/t/resizing-kernel-images-for-edgerouter-x/194968). ## Erfahrung aus unserem Test Migration wurde am 26.09.2026 an einem Ersatz-ER-X erfolgreich getestet (von OpenWrt 22.03.5 auf 24.10.1). Ablauf lief ohne Komplikationen durch, Downloads und Neustart wie beschrieben. --- # OpenMPTCProuter (OMR) auf dem migrierten ER-X: Fehleranalyse Nach der Migration auf OpenWrt 24.10.1 (Kernel 6.6.86) wurde versucht, das offizielle OMR-Image für den ER-X aufzuspielen (`openmptcprouter-v0.64.2-6.18-...-ubnt_edgerouter-x-squashfs-sysupgrade.bin`). Der Flash-Vorgang selbst lief erfolgreich durch (passendes Partitionslayout dank vorheriger Migration). Danach zeigten sich mehrere, im Detail dokumentierte Probleme: ### 1. Kein vollständiges LuCI vorinstalliert Nach dem Flash war unter `http://192.168.100.1` (Standard-OMR-Zugriff über den **WAN-Port**, nicht LAN) keine Weboberfläche erreichbar. Ursache: `uhttpd` war im Image nicht installiert. Schrittweise Nachinstallation über `apk` nötig, bis die Oberfläche lief: ``` apk add luci-base uhttpd uhttpd-mod-ubus apk add luci-theme-bootstrap apk add luci-mod-admin-full rm -f /tmp/luci-indexcache /etc/init.d/uhttpd restart ``` Jedes fehlende Teilstück äußerte sich als eigener Fehler (u. a. „Unable to render any theme header template“, „No page is registered at '/'“), bis alle vier Pakete installiert waren. **Ergebnis:** Standard-OpenWrt-LuCI (System, Netzwerk, etc.) war danach nutzbar – aber ohne jeden OMR-spezifischen Bedienbereich. ### 2. OMR-eigener Paket-Feed liefert 404 / fehlt komplett Die für den OMR-Wizard und die Kernfunktionen nötigen Pakete (`luci-app-openmptcprouter`, `glorytun-tcp`, `shadowsocks-libev` u. a.) liegen in einem eigenen Feed (`openmptcprouter`), der bei diesem Kernel-Build (6.6, v0.64.2-6.18) nicht erreichbar ist: ``` apk search -v 'glorytun*' WARNING: opening from cache http://download.openmptcprouter.com:80/release/v0.64.2-6.18/ubnt-erx/packages/mipsel_24kc/openmptcprouter/packages.adb: No such file or directory ``` Getestet wurden zwei unterschiedliche, im System hinterlegte Feed-URLs (`download.openmptcprouter.com` und `packages.openmptcprouter.com`) – beide liefern für den `openmptcprouter`- und `luci`-Feed einen 404-Fehler. **Dies ist ein bekannter, offener Bug im Projekt selbst**, dokumentiert in [Issue #3176](https://github.com/Ysurac/openmptcprouter/issues/3176) ("opkg not updated lists on latest 6.6 kernel OMR"), betrifft alle Geräte/Architekturen mit dem neueren 6.6-Kernel-Build, nicht nur den ER-X. **Konsequenz:** Weder das LuCI-Wizard-Paket noch die eigentlichen Bonding-Kernkomponenten (Glorytun, Shadowsocks) lassen sich auf diesem Image regulär installieren. Das Problem liegt auf Seite des OMR-Projekts (kaputte/nicht gepflegte Paketquelle), nicht an unserer Konfiguration. ### Fazit zu OMR auf dem ER-X Nach mehreren Etappen (Debian-13-Sperre umgangen, iperf3-Bug gepatcht, glorytun-Build-Bug gepatcht, ER-X-Partitionsmigration durchgeführt) hat sich gezeigt, dass der aktuelle OMR-Release-Zweig (v0.64.2, Kernel 6.6/6.18) an mehreren, voneinander unabhängigen Stellen fehlerhaft bzw. unvollständig gepflegt ist. Eine funktionierende OMR-Installation auf dem ER-X ist mit aktuellem Stand **nicht ohne eigenen Paket-Build** erreichbar. ## Kurswechsel: BondingShouldBeFree (BSBF) statt OMR Als Alternative zu OMR wurde [BondingShouldBeFree (BSBF)](https://github.com/bondingshouldbefree) identifiziert, ein aktiveres, schlankeres Projekt mit demselben Ziel (MPTCP-basiertes Verbindungs-Bonding): - Nutzt den **Mainline-Linux-MPTCP-Stack** (bereits im OpenWrt-24.10-Kernel enthalten, kein Custom-Kernel nötig) - Nutzt **xray-core** (VLESS-Protokoll) statt Glorytun/Shadowsocks - Bietet einen **Firmware-Selector** (`fs.bondingshouldbefree.org`), der über OpenWrts offiziellen Attended-Sysupgrade-Dienst ein fertiges, vorkonfiguriertes Client-Image baut - Server-Installer läuft auf gewöhnlichen Linux-Distributionen mit `apt`, `systemd` und `ifupdown` (keine dokumentierte Einschränkung auf bestimmte Debian-Versionen, im Unterschied zu OMR) **Stand:** Wird aktuell evaluiert, noch nicht produktiv getestet. Nächste Schritte: Server-Installer-Script sichten und auf dem Freifunk-Server testen, danach Client-Image über den Firmware-Selector für den ER-X bauen.