[Info] modfs - SquashFS-Image (AVM-Firmware) ändern für NAND-basierte FRITZ!Boxen

[PeterPawn]

Nur noch mal als Hinweis, bevor die Frage nach einer Quelle dann auch hier auftaucht: Die 06.50 gibt es zum gegenwärtigen Zeitpunkt noch nicht offiziell, sie wurde bisher nur von den Leuten gesichtet, die sich mit einer (versehentlich?) irgendwann Ende August veröffentlichten Entwickler-Version auch als "externe Tester" immer wieder per Update-Abfrage bei AVM auf die jeweils neueste (inoffizielle) Labor-Version von AVM stürzen. Diese Versionen wurden zwar ab und an auch als offizielle Labor-Version bereitgestellt, das galt aber beileibe nicht für jede Zwischenversion und gilt bisher auch noch nicht für die dort bereits gesichtete 06.50 (weder als Labor- noch als Release-Version).

EDIT: Früh am Abend geschrieben, dann doch die Release-Version gesehen, erst mal andere Tests gemacht und dann versehentlich die alte Antwort sehr spät doch noch gesendet. Also tatsächlich Quatsch, was ich da geschrieben habe ... zum Zeitpunkt des versehentlichen Absendens wußte ich es schon besser. Um Irritationen zu vermeiden, lösche ich trotzdem nicht den gesamten Beitrag.

 

[BurningCrash]

7490 mit 6.50 erfolgreich mit modFS bearbeitet.

Großes Danke an @PeterPawn

 

[Bonvie]

Hallo PeterPawn,
bei mir hat das Update mit dem Script nicht funktioniert. Liegt es daran das ich zwei Versionen übersprungen haben ?

# mkdir -p /var/mod;cd /var/mod;wget -qO- http://yourfritz.de/modfs-0.3.1.tgz | gunzip -c | tar x;./modfs
Ermitteln der Hardware-Version ... OK
Prüfen, ob die Hardware-Version unterstützt wird ... OK
Suchen der Einstellung zur Umschaltung auf das alternative System ... OK
Prüfen der aktuell zu startenden Systemversion ... OK
Suchen der aktuellen Kernel-Partition ... OK
Suchen der alternativen Kernel-Partition ... OK
Vergleich der Systeme in den Kernel-Partitionen ... OK
Suchen der aktuellen Dateisystem-Partition ... OK
Suchen der alternativen Dateisystem-Partition ... OK
Überprüfen des zur Verfügung stehenden Speicherplatzes im RAM ... OK
Überprüfen des freien Speicherplatzes für das Auspacken des Dateisystems ... OK

Das System erfüllt die Voraussetzungen zur Modifikation des root-Dateisystems.

Im Moment läuft auf der Box die Version: 113.06.24

Als Ausgangspunkt dieser Modifikationen wird ein SquashFS-Image benötigt.
Dafür stehen drei Möglichkeiten zur Auswahl:

a - das root-Dateisystem des laufenden Systems benutzen
b - ein neues root-Dateisystem aus einem Firmware-Download vom FTP-Server des Herstellers verwenden
c - ein an anderer Stelle im Dateisystem abgelegtes Image verwenden
q - keine Änderungen vornehmen

Bitte den Buchstaben des gewünschten Punktes eingeben : b

Download eines aktuellen Firmware-Images vom FTP-Server des Herstellers ... Fehler

Beim Versuch des Downloads einer frischen Kopie der aktuellen Firmware vom
FTP-Server des Herstellers ist ein Fehler aufgetreten.

Unabhängig von dem Fehler natürlich Danke für deine Mühen hier und natürlich für das Script.

Gruß
Bonvie

 

[PeterPawn]

Der Aufruf erfolgte so, daß das Skript versucht hat, die Version 06.24 vom AVM-Server zu laden (die es natürlich schon lange nicht mehr gibt) ... da fehlt vermutlich (wenn ich Deine Intention richtig verstehe) der Parameter "update" beim Aufruf (siehe #1 und die dortigen Verweise auf weitere Beiträge zum "update"-Modus.

 

[Bonvie]

Danke für die schnelle Antwort.
Spitzen Script, update meiner zwei Boxen in Rekordzeit, da alles in einem Schritt erfolgt.

Kaum macht mann es richtig, funktioniert es

mkdir -p /var/mod;cd /var/mod;wget -qO- http://yourfritz.de/modfs-0.3.1.tgz | gunzip -c | tar x;./modfs update

Nochmals danke,
Bonvie

 

[Semenchkare]

Hallo,

ich versuchte es wie Bonvie mit dem "update". Das klappte nicht. Dann mit

mkdir -p /var/mod;cd /var/mod;wget -qO- http://yourfritz.de/modfs-0.3.1.tgz | gunzip -c | tar x;./modfs

hier rebootet die Box (siehe letzte Ausgabe auf telnet), das Modfs wird nicht durchgezogen:

# mkdir -p /var/mod;cd /var/mod;wget -qO- http://yourfritz.de/modfs-0.3.1.tgz |
gunzip -c | tar x;./modfs
Ermitteln der Hardware-Version ... OK
Prüfen, ob die Hardware-Version unterstützt wird ... OK
Suchen der Einstellung zur Umschaltung auf das alternative System ... OK
Prüfen der aktuell zu startenden Systemversion ... OK
Suchen der aktuellen Kernel-Partition ... OK
Suchen der alternativen Kernel-Partition ... OK
Vergleich der Systeme in den Kernel-Partitionen ... OK
Suchen der aktuellen Dateisystem-Partition ... OK
Suchen der alternativen Dateisystem-Partition ... OK
Überprüfen des zur Verfügung stehenden Speicherplatzes im RAM ... OK
Überprüfen des freien Speicherplatzes für das Auspacken des Dateisystems ... OK

Das System erfüllt die Voraussetzungen zur Modifikation des root-Dateisystems.

Im Moment läuft auf der Box die Version: 113.06.50

Als Ausgangspunkt dieser Modifikationen wird ein SquashFS-Image benötigt.
Dafür stehen drei Möglichkeiten zur Auswahl:

a - das root-Dateisystem des laufenden Systems benutzen
b - ein neues root-Dateisystem aus einem Firmware-Download vom FTP-Server des Herstellers verwenden
c - ein an anderer Stelle im Dateisystem abgelegtes Image verwenden
q - keine Änderungen vornehmen

Bitte den Buchstaben des gewünschten Punktes eingeben : a

Als Quelle wird das root-Dateisystem des laufenden Systems verwendet, damit werden auch bereits vorhandene
Änderungen automatisch in das neue System übernommen. Für das Vermeiden doppelter Änderungen sind die
jeweiligen Skripte verantwortlich.

Entpacken des root-Dateisystem für die Modifikationen ... /Dec 11 21:57:43 dsld[17646]: mstv: DHCPv4: no answer on DISCOVER
OK

Das entpackte Dateisystem ist jetzt bereit für die Modifikationen.

Verzeichnis des root-Dateisystems : /var/tmp/1449867450/squashfs-root


Die Modifikation 'enable system selection from GUI' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
Überprüfen des Erfolgs der Modifikation ... OK

Die Modifikation 'enable system selection from GUI' wurde angewendet, Fehlercode = 0.

Die Modifikation '(re)enable telnet daemon' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
Überprüfen des Erfolgs der Modifikation ... OK

Die Modifikation '(re)enable telnet daemon' wurde angewendet, Fehlercode = 0.

Die Modifikation 'enable rc.user execution' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
Überprüfen des Erfolgs der Modifikation ... OK

Die Modifikation 'enable rc.user execution' wurde angewendet, Fehlercode = 0.

Die Modifikation 'create edit_rcuser command' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Soll die Modifikation 'create edit_rcuser command' mit folgender Beschreibung
Es wird ein zusätzliches Kommando 'edit_rcuser' erzeugt, mit dem die Kommandos
in der Datei 'rc.user' sicher bearbeitet werden können, ohne daß man sich um
die Besonderheiten des TFFS kümmern muß.
angewendet werden ? (j/N) j
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
Überprüfen des Erfolgs der Modifikation ... OK

Die Modifikation 'create edit_rcuser command' wurde angewendet, Fehlercode = 0.

Die Modifikation 'enable custom profile extension' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Soll die Modifikation 'enable custom profile extension' mit folgender Beschreibung
/etc/profile modifizieren, um die Kommandos in /var/custom/profile am Ende
zusätzlich auszuführen, wenn diese Datei existiert
angewendet werden ? (j/N) j
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
Überprüfen des Erfolgs der Modifikation ... OK

Die Modifikation 'enable custom profile extension' wurde angewendet, Fehlercode = 0.

Das ist die letzte Chance zum manuellen Modifizieren des Dateisystems in /var/tmp/1449867450/squashfs-root.

Die Eingabetaste drücken, um mit dem Packen des neuen root-Dateisystems zu beginnen
oder 'q' eingeben, um die letzte Möglichkeit zum Abbruch zu nutzen :

Packen des neuen root-Dateisystems ... \

Was könnte bei mir nicht i.O. sein bzw. wie bekomm ich den Modfs drauf?

 

[Riverhopper]

hallo Semenchkare,
siehe Lösungsvorschlag #177
Abschnitt "Wenn die Box kommentarlos neu startet"

LG Riverhopper

 

[koyaanisqatsi]

Moins

Aus dem Bauch raus: Mach mal deinen internen Speicher leer

..aber es kommt bestimmt noch ein besserer Tip.

 

[Semenchkare]

Vielen Dank.

ein

prepare_fwupgrade start_tr069

war tatsächlich die Lösung.

Hatte das nicht geglaubt, da MODFS bei mir seit jeher super klappte.

ich habe das Gefühl, die 7490 wird seit der .50 deutlich mehr beansprucht...


Danke an alle, Riverhopper war am nächsten dran!

Gute Nacht!

 

[Tieflieger]

Problem mit einer Box 7490 von Vodafon Firmware 31 <-?

tty is "/dev/pts/0"
Console Ausgaben auf dieses Terminal umgelenkt
disable start/stop characters and flowcontrol
# mkdir -p /var/mod;cd /var/mod;wget -qO- http://yourfritz.de/modfs-0.3.1.tgz |
gunzip -c | tar x;./modfs update
Ermitteln der Hardware-Version ... OK
Prüfen, ob die Hardware-Version unterstützt wird ... OK
Suchen der Einstellung zur Umschaltung auf das alternative System ... Fehler

Die Einstellung in der Box (linux_fs_start), mit der zwischen den zwei FRITZ!OS-Versionen
umgeschaltet werden kann, ist nicht vorhanden.

Edit: nach update geht es - warscheinlich weil noch kein Update gefahren wurde.

und

mkdir -p /var/mod;cd /var/mod;wget -qO- http://yourfritz.de/modfs-0.3.1.tgz | gunzip -c | tar x;./modfs /var/media/ftp/(firmwaredatei)

 

[KiRKman]

Edit: nach update geht es - warscheinlich weil noch kein Update gefahren wurde.

Ja richtig: Wenn eine Box "jungfräulich" ist, so ist noch kein alternatives Betriebssystem vorhanden. Das Script kann also nicht ermitteln, welches der beiden Systeme gerade benutzt wird. Außerdem ist noch kein "Backup" des Systems vorhanden.

Besser ist es, einfach das erste Update auf dieser neuen Box zu fahren, damit der alternative Bereich das erste Mal genutzt und damit eingerichtet wird. Somit ist dann auch die Variable "linux_fs_start" vorhanden.

Übrigens könnt Ihr das Image auch auf einen an der Box angeschlossenen USB-Speicher packen und das Update von dort aus mit modfs starten. Bei mir ist das Image im Verzeichnis "fw" auf einer externen Samsung-USB-Platte:

mkdir -p /var/mod;cd /var/mod;wget -qO- http://yourfritz.de/modfs-0.3.1.tgz | gunzip -c | tar x
./modfs update /var/media/ftp/Samsung-S2Portable-01/fw/fritzos.image

Ihr braucht also nur das "Samsung-S2Portable-01/fw/fritzos.image" auf Euren Pfad/Dateinamen anzupassen.

 

[PeterPawn]

Dafür aber bitte nur USB-Speicher verwenden, der ein Linux-Dateisystem enthält. Bei FAT oder NTFS gehen sowohl die Symlinks als auch die korrekten Unix-Zugriffsrechte für die Dateien verloren, das ist spätestens bei den Modscripts dann ein größeres Problem, weil alle Dateien die Rechte vom Mounten des Volumes "erben".

Die Abfrage von "linux_fs_start" ist eigentlich eher "historisch" ... am Beginn wollte ich nur sicherstellen, daß die Umgebung innerhalb der Box auch wie erwartet aussieht. Heutzutage glaube ich sagen zu können, daß ein

echo linux_fs_start 0 >/proc/sys/urlader/environment

auch vollkommen ausreichend wäre. Theoretisch kann man das auch aus der Anzeige von

cat /proc/mtd

ablesen, wenn dort die Partitionen mit den Nummern 2 und 3 diejenigen mit dem "reserved"-Bestandteil im Namen sind, dann ist der richtige Wert "0", ansonsten (mtd0+mtd1 sind "reserved") eben die "1" (habe ich in einer "leeren" Box noch nicht gesehen, auch das /var/install-Skript der AVM-Firmware hätte damit seine Probleme, das nimmt bei fehlendem Wert auch einfach 0 an und fragt nicht die Namen der Partitionen dafür ab).

Wenn ich mal Langeweile habe, baue ich vielleicht noch eine Abfrage ein, ob man das fehlende "linux_fs_start" automatisch korrigieren lassen will, das spart dann das erste Update ... inzwischen ist ja klar, daß auch dabei nichts anderes/besonderes passiert. Das war vor 15 Monaten noch nicht so richtig klar für mich.

Dabei gibt es dann auch noch eine neue Möglichkeit, das bestehende System auch ohne Neustart zu "klonen", das war eigentlich auch nur eine reine Vorsichtsmaßnahme, die es heute wohl nicht mehr braucht und die es "weniger handlich" macht, einfach kumulative Änderungen umzusetzen.

 

[KiRKman]

Dafür aber bitte nur USB-Speicher verwenden, der ein Linux-Dateisystem enthält. Bei FAT oder NTFS gehen sowohl die Symlinks als auch die korrekten Unix-Zugriffsrechte für die Dateien verloren, das ist spätestens bei den Modscripts dann ein größeres Problem, weil alle Dateien die Rechte vom Mounten des Volumes "erben".

Sehe ich jetzt anders Bei mir ist das externe Speichermedium zwar ext2-formatiert, das muss aber nicht zwingend der Fall sein. Denn dort liegt ja nur das zu verwendende "Quell-Image". modfs entpackt bei mir jedoch nach wie vor nach /var/media/ftp/...

Es verhielt sich auch schon immer so, dass der Macronix-Flash der 7490 verwendet wurde. Dort gehen ja keine Flags verloren. Woher das Image letztendlich kommt, sollte dann ja egal sein.

Ich habe bei mir das Image also auf einer externen Samsung-USB-Festplatte (an der FRITZ!Box) liegen und rufe modfs dann so auf:

./modfs update /var/media/ftp/Samsung-S2Portable-01/fw/fritzos.image

Das Filesystem der Partition "Samsung-S2Portable-01" ist doch dann wurscht? Oder übersehe ich was?

 

[PeterPawn]

@KiRKman:
Es geht um die Dateirechte für die Skripte selbst (hier besonders die im "modscripts"-Verzeichnis, wo die x-Flags ja entscheiden, ob ein Skript automatisch ausgeführt wird oder nicht bzw. ob es überhaupt ausgeführt wird - selbst wenn das kein Systemaufruf ist, sondern eine eigene Auswertung in modfs) und um die Fähigkeit, die Symlinks für die unsquashfs/mksquashfs-Programme anhand der Hardware-Revision der verwendeten Box auf die Files in "VR9" richtig zu setzen.

Klappt das mit den Rechten und den Symlinks nicht richtig, werden entweder zuviele Modscripts ohne Nachfrage ausgeführt oder bei jedem einzelnen nachgefragt und wenn die Symlinks dann nicht in "echte Dateikopien" umgewandelt werden, funktioniert nicht einmal das Auspacken richtig, weil "unsquashfs" nicht gefunden wird.

Für das ausgepackte Image macht das wieder gar keinen Unterschied, weil da ja sichergestellt wird vom Skript, daß es sich um ein Linux-Filesystem handelt. Findet sich keines mit ausreichendem freien Speicherplatz, wird eine 128 MB große ext3-Partition per Loop-Device in einer Datei auf dem USB-Speicher emuliert mit einer entsprechenden Vorlage.

Ich hatte das aber wohl ohnehin falsch verstanden ... Du meintest ja offenbar tatsächlich nur das Image-File von AVM und nicht den Inhalt des modfs-Archivs, während ich mich ausschließlich auf den letzteren bezog. Beim Image ist es natürlich Bummi, woher es kommt ... beim Update auf 06.50 kann man es (bei funktionierender Internetverbindung) ja sogar direkt durch das Skript vom AVM-Server laden lassen.

 

[Bonvie]

Hallo PeterPawn,
ich habe mich leider zu früh gefreut. Das Update über dein Skript von 6.24 auf 6.50 lief zwar fehlerfrei durch, aber danach fingen die Probleme an. Kurz ich habe beide Boxen mit dem FRITZ.Box_7490.06.50.recover-image neu aufgesetzt und per Hand neu konfiguriert. Dabei sind mir zwei Sachen aufgefallen:

Nach dem Ausführen deines Skriptes und dem reboot steht in der eigentlich leeren rc.user folgender Text:

eventadd 1 "Die Datei rc.user (TFFS-Minor-ID 98) wird abgearbeitet ..."

ist nicht schlimm, aber zeigt das etwas falsch läuft.

Der zweite Punkt ist etwas kurios. In meiner Basis Box bleibt nach deinem Script wie gewünscht telnet aktiv, auch nach einem Reboot.
Bei der Repeater Box muss ich jedes Mal "telnet.tar" einspielen bevor ich darauf zugreifen kann.

Davon unabhängig wird auf beiden Boxen die rc.user wie gewünscht ausgeführt.

Gruß
Bonvie

 

[PeterPawn]

ist nicht schlimm, aber zeigt das etwas falsch läuft.

Das ist normal und volle Absicht ... wenn modfs auf eine leere rc.user trifft, schreibt es genau dieses "eventadd"-Kommando (das einen Eintrag im Ereignisprotokoll der FRITZ!Box hinterläßt) in die Datei, damit man sofort überprüfen kann, ob die Änderung funktioniert oder nicht. Wenn Du eigenen Inhalt dort hinterlegst, kannst Du Dich ja frei entscheiden, ob Du diese Zeile drin läßt oder löschst.

Bei der Repeater Box muss ich jedes Mal „telnet.tar“ einspielen bevor ich darauf zugreifen kann.

Das bloße Hinzufügen des Symlinks für den telnetd startet ja den Service noch nicht ... das soll normalerweise (wie früher auch) der "telefon"-Daemon übernehmen, wenn man den Telnet-Service über die bekannte Tastenfolge aktiviert hat. Wenn man diese Einstellung nicht vorgenommen hat, startet auch der telefon den telnetd nicht ... entweder man aktiviert ihn einfach über die Tastencodes oder man muß ihn eben selbst in der rc.user starten. Der Patch schafft nur die Möglichkeit, den telnetd zu benutzen ... nichts weiter - alles andere bleibt (absichtlich) dem Benutzer überlassen.

Anders als Freetz dürfte auch modfs keinerlei Einfluß auf irgendwelche Funktionen des FRITZ!OS an sich haben, es werden ja nur Skript-Dateien geändert und keine Binaries oder Libraries ausgetauscht oder AVM-Code aus Skript-Files gelöscht. Sonstige Probleme mit dem FRITZ!OS dürften also keinen Zusammenhang mit der Behandlung mit modfs haben ... das wäre extrem unwahrscheinlich.

 

[Bonvie]

Danke für die schnelle Antwort.
Das mit dem Inhalt der rc.user wusste ich nicht, sorry für die falsche Interpretation.
Den Hinweis auf die Tastenfolge, werde ich gleich heute Abend testen, Danke.

Bitte nicht falsch verstehen, die Problem die ich hatte beziehe ich nicht auf dein Skript oder die rc.user mit Inhalt. Bei mir waren Rufnummern sporadisch nicht erreichbar und später konnten sie sich gar nicht mehr anmelden. Die Probleme sehe ich eher durch das Update beim Überspringen der 6.30 Version.

 

[scraemgo]

Ich hatte meine 7490 damals mit dem Skript von der 6.24 auf die 6.30 upgedated. Jetzt habe ich auf die 6.50 upgedated, was soweit super funktioniert hat. Dann habe ich testweise noch einmal die 6.30 geladen um was nachzuschauen. Ging auch super. Anschließend wollte ich wieder zur 6.50 zurück aber dann hing die 7490 in einer Bootschleife. Auch komplett stromlos machen und alle Kabel ausstecken half nichts. Konnte sie mit der Recovery wieder herstellen.

Wollte nur für das nächste Mal fragen, ob ich den Fehler irgendwie anders beheben kann, bzw. ob du eine Ahnung hast warum das aufgetreten ist? Oder ob bzw. was ich tun kann, damit ich Hinweise auf den Fehler (Logs usw.) sichern kann.

 

[PeterPawn]

Ich war praktisch in der ganzen Zeit, in der der Labor-Zweig für die 7490 lief, ein "Wanderer zwischen den Welten" und habe - bis auf einige wenige Einstellungen, die beim Wechsel zurück auf 06.30 wieder "verschwunden" sind (z.B. das "volume_labels" in der usb.cfg) - eigentlich keine Probleme feststellen können; zumindest nicht am Beginn. Irgendwann wollte dann mal das WLAN unter der 06.50 nicht mehr, obwohl es nach der Umschaltung auf 06.30 sofort wieder lief ... das habe ich dann durch mehrmaliges Werksreset (wie das gewirkt hat bzw. was es bewirkt haben soll, verstehe ich selbst nicht) mit der 06.50 irgendwann in den Griff bekommen (kaputt konnte das WLAN ja nicht sein, denn es lief mit der 06.30 einwandfrei).

Ansonsten kamen halt ab und an mal ein paar Einträge in der "landevices"-Sektion der ar7.cfg durcheinander, weil die eben jeweils neu geschrieben wurde vom aktiven System ... das war aber zu erwarten.

Probleme mit einem nicht startenden System hatte ich jedenfalls weder mit der 06.30 noch mit der 06.50 ... wenn ich nur umgeschaltet habe. Bei Experimenten innerhalb eines Systems habe ich die Box natürlich oft genug aufgehangen, dann aber mit einer Umschaltung über EVA jedesmal auch wieder zur Arbeit überreden können und dann von diesem laufenden System aus meinen eigenen Fehler jeweils korrigiert.

Man muß halt etwas aufpassen, daß man nicht die Systeme durcheinander wirft ... das war bei früheren Übergängen weniger kritisch, weil zumindest das Wurzel-Dateisystem wechselseitig gelesen werden konnte.

Insofern glaube ich eigentlich nicht daran, daß sich das Problem bei Dir reproduzieren läßt ... wenn doch, hilft die Umschaltung von "linux_fs_start" über EVA, um das "alte" System wieder zu verwenden und von dort kann man dann ggf. die "crash.log" oder auch die "panic.log" aus dem Flash-Speicher untersuchen, falls das System dazu gekommen ist, dort etwas zu hinterlassen. Wenn es nicht soweit geht, schreibt der Kernel die "crash"-Variable im Urlader-Environment ... wenn man die ordentlich löscht nach einem erfolgreichen Start und entsprechender Auswertung, sieht man notfalls auch im Bootloader schon bei einem späteren Problem, ob das System "hart" abgestürzt ist und wenn ja, wo.

 

[Bonvie]

@scraemgo: Ich habe das gleiche Phänomen bei mir gehabt allerding mit der 6.24 auf der zweiten Partition. D.h. ich kam von der 6.50 auf die 6.24, aber nicht wieder zurück.
Da aber nach dem Schritte zurück auf 6.24 die Rufnummern Anmeldung nur noch zum Teil funktionierte und ich keine Anpassungen vornehmen konnte weil die Felder leer bleiben, war mir klar das System wird so nie wieder problemlos laufen.
Ich konnte die Box über das Recover-Image ohne Problem wieder aus der Boot-Schleife holen und neu aufsetzen. Einen anderen Weg habe ich nicht gesehen, da die Konfigurationen den Wechsel auf 6.50 eh schon nur bedingt überstanden hatten. Das war der Grund wieso ich versucht habe auf die 6.24 zurück zu gehen.