[Gelöst] Freetzen einer 7590 mit FW 7.12

Doch, doch - das hatte ich in Beitrag #35 geschrieben - das relevante Protokoll ist E02_192-168-178-11-new_2020-05-12-37-txt
Vermutlich war das da nicht deutlich genug geschrieben... :oops:

Die relevanten Zeilen im Log sind folgende:
Code:
libscan: scanning eraseblock 2330: OK, erase counter 20
libscan: scanning eraseblock 2331: OK, erase counter 20
libscan: scanning eraseblock 2332: OK, erase counter 20
libscan: scanning eraseblock 2333libmtd: error!: cannot read 64 bytes from mtd6 (eraseblock 2333, offset 0)
        error 1 (Operation not permitted)
ubiformat: error!: failed to scan mtd6 (/dev/mtd6)

EDIT: das verwendete Shellscript war E02-test_me_new.txt
 
Zuletzt bearbeitet:
Das hatte ich tatsächlich nicht mitgekriegt - das ist die Gefahr, wenn man nachträglich editiert. Ich hatte den Thread schon offen in einem Tab und ihn beiseite gelegt, um später zu antworten (das mit den LEDs) - da war Deine Ergänzung noch nicht drin und so eine nachträgliche Bearbeitung wird dann auch nicht mehr als Änderung des Thread-Inhalts signalisiert.

=========================================================

Damit ist aber klar, daß das Problem wohl schon beim Lesen des EC-Headers auftritt ... der steht normalerweise in den ersten 64 Byte eines Erase-Blocks (die OOB-Daten benutzt UBI normalerweise auch nicht, da lag ich falsch bzw. das war mir entfallen).

Angesichts Deiner ohnehin geringen Werte für diese Erase-Counter halte ich es für vertretbar, die bisher erfolgten Schreibzugriffe zu ignorieren und zu versuchen, mittels "-e 0"-Option beim "ubiformat" auf die Leseversuche zu verzichten und für alle Blöcke (das gilt ohnehin ja nur für die, die unter UBI-Kontrolle stehen) den Zähler zurückzusetzen. Wenn das Schreiben des EC-Headers schon zum Fehler führt, sollte der PEB aussortiert werden.
 
Das hatte ich tatsächlich nicht mitgekriegt - das ist die Gefahr, wenn man nachträglich editiert.
Ich bin eigentlich auch kein Fan davon - normalerweise schreibe ich dann lieber einen neuen Beitrag.
Hier im Forum wurde ich aber schon verwarnt und mehrere aufeinanderfolgende Beiträge "zusammeneditiert" - und das ist noch schlechter, da sieht man dann gar nicht mehr, was nachträglich dazukam...

Angesichts Deiner ohnehin geringen Werte für diese Erase-Counter halte ich es für vertretbar, die bisher erfolgten Schreibzugriffe zu ignorieren und zu versuchen, mittels "-e 0"-Option beim "ubiformat" auf die Leseversuche zu verzichten und für alle Blöcke (das gilt ohnehin ja nur für die, die unter UBI-Kontrolle stehen) den Zähler zurückzusetzen. Wenn das Schreiben des EC-Headers schon zum Fehler führt, sollte der PEB aussortiert werden.
Das hatte ich mich bisher nicht getraut (weil ich nicht wußte, was das genau auslöst) - jetzt werde ich es mal durchführen ;)

Aussführungsbericht wieder hier als "EDIT", falls inzwischen keine weitere Antwort von jemand anderes kam / kommt
 
Tipp von mir zum "EDIT" - wenn Du den neuen Inhalt als neuen Beitrag schreibst und dann nur den vorhergehenden Beitrag davorkopierst, kriegt der eine neue Nummer und wird auch als "neu" behandelt ... und zwar bei allem (von der E-Mail-Benachrichtigung über die "What's new"-Ausgabe bis hin zu den "Thread was changed"-Mitteilungen per Javascript.). Wenn ein anderer Beitrag dazwischen liegt, bringt das natürlich die Reihenfolge durcheinander - andererseits verlangt auch niemand von Dir in so einer Situation, daß Du den vorhergehenden Beitrag bearbeitest.
 
Tipp von mir zum "EDIT" - wenn Du den neuen Inhalt als neuen Beitrag schreibst und dann nur den vorhergehenden Beitrag davorkopierst, kriegt der eine neue Nummer und wird auch als "neu" behandelt ...
das habe ich jetzt nicht verstanden - wenn ich das mache, dann ist das doch ein doppelter Eintrag, oder wird dadurch der ursprüngliche Beitrag automatisch gelöscht?

Hier jetzt das Ergebnis: irgendwie ignoriert der die "-e 0" Angabe - oder zumindest ändert sich nichts am Verhalten.
Der Aufruf erfolgt jetzt ubiformat /dev/mtd6 -e 0 -y -v - das kann man auch im Log sehen (durch den set -x).
Aber die libscan-Meldungen samt Fehlermeldung aus libmtd sind leider identisch; sehr seltsam - lt. Hilfe aus der Box (ubiformat -h) kennt der aber den -e Parameter...
 

Anhänge

  • E02-test_me.txt
    9.5 KB · Aufrufe: 0
  • E02_192.168.178.11-new_2020-05-13_14-38.txt
    132.8 KB · Aufrufe: 3
wird dadurch der ursprüngliche Beitrag automatisch gelöscht?
Nein, den mußt Du dann natürlich von Hand entsorgen.

====================================================================

Also steht die Aufgabe an, irgendwie die Blöcke in dem passenden MTD zu löschen - und zwar so, daß dabei zuvor nicht gelesen wird. Das alles in der Hoffnung, daß dabei der PEB 2333 wieder so weit "repariert" wird, daß ein Lesezugriff auf die ersten 64 Byte möglich wird.

Ich sehe da zwei mögliche Wege, aber für beide mußt Du Dich vorher (genau!) vergewissern, welches das richtige MTD ist (das sollte auch nicht vom UBI-Layer in Beschlag genommen sein), denn das variiert von der Nummer her, je nachdem, ob aus dem Flash oder aus dem RAM gestartet wurde. Richtig ist die Partition, die als "ubi" in der Ausgabe von "/proc/mtd" steht.

Der erste Weg wäre der, daß man es mittels des "update_kernel" von AVM versucht. Das kann entweder Daten in den Flash schreiben (wenn -i und -o angegeben wurden - Beispiele in der E03-flash_update) oder es kann auch nur löschen, wenn ausschließlich "-o" angegeben wurde. In jedem Falle sind hier die Character-Devices für die MTDs zu verwenden - also "mtdX" und nicht "mtdblockX". Ich weiß nicht, wie das Programm genau vorgeht (ist halt "closed source" von AVM) - aber einen Versuch ist es allemal wert (dem schließt sich dann ggf. wieder das "ubiformat" an).

Die Alternative, von der ich aber nicht genau weiß, ob sie bei der 7590 funktioniert (und erst recht nicht beim 07.12-Kernel), wäre die Verwendung des "/proc/mtd"-Interfaces. Hier wäre ein echo "mtd [I]X[/I] erase all force" > /proc/mtd den Versuch wert - wenn das mit dem "update_kernel" nicht geklappt hat. Weiter dann wieder mit "ubiformat" - ob es hilft, weiß ich auch nicht.

Es wäre denkbar, daß bei den GRX-Modellen überhaupt kein Schreibzugriff auf "/proc/mtd" implementiert ist - die Kernel-Quellen enthalten in "mtdcore.c" jedenfalls keinen Support für "mtd_write_proc()". Wenn der vorhanden ist, kann man über "mtd X erase { nr | all [ force ] }" alle oder einzelne Blöcke eines MTD löschen, bevor man die dann neu beschreibt. Aber ich kann auch verstehen, wenn AVM das in neueren Modellen nicht länger einbaut - die "Sabotage" einer Box über ein passendes Kommando an "/proc/mtd" war einfach zu leicht, denn damit kann man sich auch den Bootloader löschen. Daher ist auch bei der Wahl der MTD-Nummer (sowohl beim "update_kernel" als auch beim "echo > /proc/mtd") höchste Sorgfalt geboten.

=======================================================================

Ich habe mal einen genaueren Blick in die betreffenden Quelltexte geworfen ... wenn ein NAND-Block bereits in der BBT (Bad Block Table) eingetragen ist, wird der beim "ubi_scan()"-Aufruf im Rahmen von "ubiformat" auch übergangen bzw. als "bad" angenommen. Hier ist das Problem im Moment, daß schon der Leseversuch für den EC-Header scheitert und dieses Scheitern aber, solange der Block nicht in der BBT steht, als "richtiger Fehler" interpretiert wird.

Normalerweise würde man so einen Eintrag in der BBT über einen ioctl()-Aufruf (mit MEMSETBADBLOCK als Operation) vornehmen lassen - es gibt aber in den "mtd-utils" kein passendes Tool. Aber es gibt einen Patch für die "mtd-utils", der ein Tool namens "nandmarkbad" nachrüstet - einfach mal googlen. Wenn also alles andere nicht hilft, müßte man sich das Tool (z.B. mit der Freetz-Toolchain) übersetzen und es von Hand für den Block 2333 im MTD4 (bzw. MTD6, je nachdem, woher das System gestartet wurde) aufrufen.

Aber Deine 7590 hat ohnehin einen Flash-Chip mit ONFI (Open NAND Flash Interface), im Gegensatz zu meiner 7580 - daher ist das mit den direkten Vergleichen immer etwas schwierig. Aber soweit ich weiß, gehört auch die BBT-Verwaltung zu den Features, die beim ONFI gefordert sind - daher sollte auch Dein Chip eigentlich eine BBT (im Flash) verwalten und wenn man den Block da als "bad" markiert hat, sollten das alle weiteren Zugriffsversuche auch berücksichtigen.
 
Nein, den mußt Du dann natürlich von Hand entsorgen.
Achso, jetzt habe ich verstanden, wie Du's gemeint hast :)

Der erste Weg wäre der, daß man es mittels des "update_kernel" von AVM versucht.
BINGO - das war die Lösung :cool:
Ich habe das jetzt in mein E02-Script eingebaut (vor dem ubiformat) und jetzt hat es funktioniert, das ubiformat ist anschließend komplett ohne Fehler durchgelaufen.
Code:
echo "[ubi] formatting ubi volumes in /dev/mtd${mtd_ubi_nr} ..."
ubidetach -p /dev/mtd${mtd_ubi_nr}
if [ -x "/sbin/update_kernel" ]; then
  echo "[ubi] using /sbin/update_kernel for cleanup of /dev/mtd${mtd_ubi_nr}"
  /sbin/update_kernel -o /dev/mtd${mtd_ubi_nr}
fi
ubiformat /dev/mtd${mtd_ubi_nr} -e 0 -y -v
l_rc=$?
if [ ${l_rc} -eq 0 ]; then
  ubiattach -p /dev/mtd${mtd_ubi_nr}
  l_rc=$?
  echo "[ubi] formatting ubi volumes done with ${l_rc}"
else
  echo "[ubi] formatting ubi volumes failed with ${l_rc}!"
  return ${l_rc}
fi

Er hat danach (vermutlich im E03-Script, das ja dann auch noch aufgerufen wird) wahrscheinlich noch seltsame Sachen gemacht, aber im Prinzip hat es funktioniert.
Ich habe anschließend noch versucht, das ganze Prozedere ohne "recovered=2" im "firmware_info" auszuführen, um zu sehen wie er da reagiert - das hat zwar auch funktioniert, aber "richtig" gebootet hat er immer noch nicht.

Am Schluss habe ich dann einfacherhalber nochmal das AVM-Recovery arbeiten lassen - danach war die Box wieder komplett erreichbar - inklusive Web-GUI.
Jetzt kann ich mich wieder daran machen, mein Freetz-NG Image draufzuballern und zu sehen, ob das funktioniert - aber das muss bis morgen warten ;)

Vieeeeelen Dank @PeterPawn für Deine Hilfe (und Geduld mit mir) - ich habe auf jeden Fall jetzt sehr viel gelernt!

Der Vollständigkeit halber habe ich mein E02-Script mit dem es dann funktioniert hat sowie die daraus resultierenden Logs angehängt.

Was noch immer komisch ist: die Info-LED hat zu keinem Zeitpunkt des Update / Recovery irgendwie "gezuckt" - da muss ich nochmal gesondert nach schauen.
(beim Einstecken des Stromsteckers geht's zuerst mit der Power-LED los, dann kommt die "Lichtorgel" - da leuchtet die Info-LED orange...)
 

Anhänge

  • E02-test_me.txt
    10 KB · Aufrufe: 1
  • E01_192.168.178.11-new_2020-05-13_16-26.txt
    3.9 KB · Aufrufe: 0
  • E02_192.168.178.11-new_2020-05-13_16-27.txt
    341.3 KB · Aufrufe: 0
  • E01_192.168.178.11-new_2020-05-13_16-29_nachE03Reboot.txt
    5.4 KB · Aufrufe: 0
  • E02_192.168.178.11-new_2020-05-13_16-29_nachE03Reboot.txt
    47 KB · Aufrufe: 0
Na also ... dann viel Spaß und viel Glück mit Freetz in der Zukunft.

Da es hier im weiteren dann um den NG-Fork geht, bin ich auch raus.
 
Na also ... dann viel Spaß und viel Glück mit Freetz in der Zukunft.
Danke nochmal für Deine Hilfen und Erklärungen! :cool:

Da es hier im weiteren dann um den NG-Fork geht, bin ich auch raus.
Schade...
(ich bin hier vor einiger Zeit umgestiegen, weil bei mir die -NG Version besser funktioniert hatte und ich über mehrere Fehler gestolpert bin, die beim "Freetz-NG" gefixt sind, aber beim "Ur-Freetz" bis heute nicht...)

Ich fände ja eigentlich auch deine "Modulversion" spannend - aber ich bin mir nicht sicher, in wieweit, die den "täglichen" Gebrauch verwendbar ist?! :)
 
ich bin mir nicht sicher, in wieweit, die den "täglichen" Gebrauch verwendbar ist?!
Das ist ohnehin noch nicht komplett ... es geht nur langsam vorwärts. Es gibt halt viel Grundlagenarbeit und dann ändert sich das auch noch ständig, weil AVM ja auch nicht die Entwicklung einstellt. Seitdem es die Wrapper-Partitionen der VR9-Boxen nicht mehr gibt, ist es auch schwerer, einfach so etwas in das originale AVM-System einzubauen, ohne es zu entpacken, zu ändern und dann neu zu packen.
 
Leute, ich werd echt noch bekloppt ...
Hab jetzt ne neue 7590 ET (2000 2784) mit der 7.29 FW drauf.

Meine alte 7590 hat leider das Zeitliche gesegnet (2.4 Netz klappt ständig zusammen und Pfeifen aus der Box).
Ich hatte die damals mittels Virtual Box und/oder eva-tools downgraden und mit freetz versorgen können - kann mich aber absolut NICHT mehr an die Vorgehensweise erinnern :(

Mittels Recover konnte ich die Box auf jeden Fall auf die 6.83 flashen - mein Freetz-Image ließ sich darüber nicht installieren...

Hat jemand mal für mich die Kurzfassung?

mittels FTP kann ich die Box auf jeden Fall im Bootvorgang anhalten - ab da weiß ich nun nicht mehr weiter...

EDIT:
Ich habe dann wie folgt versucht zu flashen:
.\EVA-FTP-Client.ps1 -Debug -Verbose -ScriptBlock { BootDeviceFromImage C:\Users\B\Downloads\Freetz\Basis_7590_07.12.de.image.in-memory }

Ergebnis:
Code:
Sicherheitswarnung
Führen Sie ausschließlich vertrauenswürdige Skripts aus. Skripts aus dem Internet können zwar nützlich sein, stellen
jedoch auch eine potenzielle Gefahr für Ihren Computer dar. Wenn Sie diesem Skript vertrauen, lassen Sie mit dem Cmdlet
 "Unblock-File" die Ausführung des Skripts ohne die Warnmeldung zu. Möchten Sie
"C:\Users\B\Downloads\Freetz\EVA-FTP-Client.ps1" ausführen?
[N] Nicht ausführen  [M] Einmal ausführen  [H] Anhalten  [?] Hilfe (Standard ist "N"): M
In C:\Users\B\Downloads\Freetz\EVA-FTP-Client.ps1:207 Zeichen:17
+             Sign up
+                 ~
Das kaufmännische Und-Zeichen (&) ist nicht zulässig. Der &-Operator ist für eine zukünftige Verwendung reserviert.
Verwenden Sie das kaufmännische Und-Zeichen in doppelten Anführungszeichen ("&"), um es als Teil einer Zeichenfolge zu
übergeben.
In C:\Users\B\Downloads\Freetz\EVA-FTP-Client.ps1:212 Zeichen:209
+ ... k Button--medium Button d-lg-none color-fg-inherit p-1">    <span cla ...
+                                                                 ~
Der Operator "<" ist für zukünftige Versionen reserviert.
In C:\Users\B\Downloads\Freetz\EVA-FTP-Client.ps1:235 Zeichen:45
+             <ul class="list-style-none f5" >
+                                             ~
Dateispezifikation nach dem Umleitungsoperator fehlt.
In C:\Users\B\Downloads\Freetz\EVA-FTP-Client.ps1:433 Zeichen:13
+       CI/CD &amp; Automation
+             ~
Das kaufmännische Und-Zeichen (&) ist nicht zulässig. Der &-Operator ist für eine zukünftige Verwendung reserviert.
Verwenden Sie das kaufmännische Und-Zeichen in doppelten Anführungszeichen ("&"), um es als Teil einer Zeichenfolge zu
übergeben.
In C:\Users\B\Downloads\Freetz\EVA-FTP-Client.ps1:492 Zeichen:45
+             <ul class="list-style-none f5" >
+                                             ~
Dateispezifikation nach dem Umleitungsoperator fehlt.
In C:\Users\B\Downloads\Freetz\EVA-FTP-Client.ps1:507 Zeichen:45
+             <ul class="list-style-none f5" >
+                                             ~
Dateispezifikation nach dem Umleitungsoperator fehlt.
In C:\Users\B\Downloads\Freetz\EVA-FTP-Client.ps1:1402 Zeichen:96
+ ... ="" data-disable-with="" data-dropdown-tracking="{&quot;type&quot;:&q ...
+                                                                 ~
Das kaufmännische Und-Zeichen (&) ist nicht zulässig. Der &-Operator ist für eine zukünftige Verwendung reserviert.
Verwenden Sie das kaufmännische Und-Zeichen in doppelten Anführungszeichen ("&"), um es als Teil einer Zeichenfolge zu
übergeben.
In C:\Users\B\Downloads\Freetz\EVA-FTP-Client.ps1:1402 Zeichen:103
+ ... a-disable-with="" data-dropdown-tracking="{&quot;type&quot;:&quot;blo ...
+                                                                 ~
Das kaufmännische Und-Zeichen (&) ist nicht zulässig. Der &-Operator ist für eine zukünftige Verwendung reserviert.
Verwenden Sie das kaufmännische Und-Zeichen in doppelten Anführungszeichen ("&"), um es als Teil einer Zeichenfolge zu
übergeben.
In C:\Users\B\Downloads\Freetz\EVA-FTP-Client.ps1:1402 Zeichen:146
+ ... &quot;type&quot;:&quot;blob_edit_dropdown.more_options_click&quot;,&q ...
+                                                                 ~
Das kaufmännische Und-Zeichen (&) ist nicht zulässig. Der &-Operator ist für eine zukünftige Verwendung reserviert.
Verwenden Sie das kaufmännische Und-Zeichen in doppelten Anführungszeichen ("&"), um es als Teil einer Zeichenfolge zu
übergeben.
In C:\Users\B\Downloads\Freetz\EVA-FTP-Client.ps1:1402 Zeichen:153
+ ... type&quot;:&quot;blob_edit_dropdown.more_options_click&quot;,&quot;co ...
+                                                                  ~
Ausdruck fehlt nach dem unären Operator ",".
Es wurden nicht alle Analysefehler berichtet. Korrigieren Sie die berichteten Fehler, und versuchen Sie es erneut.
    + CategoryInfo          : ParserError: (:) [], ParseException
    + FullyQualifiedErrorId : AmpersandNotAllowed
 
Zuletzt bearbeitet:
Hab jetzt ne neue 7590 ET (2000 2784) mit der 7.29 FW drauf.
Die Artikel-Nr. 2000-2784 ist eine (normale) FRITZ!Box 7590 und keine FRITZ!Box 7590 AX v1, keine 7590 AX v2 und auch keine 7590 ET.

Ich hatte die damals mittels Virtual Box und/oder eva-tools downgraden und mit freetz versorgen können - kann mich aber absolut NICHT mehr an die Vorgehensweise erinnern :(
Sicherlich nicht per Downgrade. Eine so alte Firmware gibt es für die 7590 gar nicht, dass es so funktionieren könnte. Und ist zudem für jemanden der ein Freetz-(NG)-Image installieren möchte imo auch eine der "unwürdigsten" Methoden überhaupt… Würde ich selbst bei älteren Modellen, wo dies theoretisch noch möglich wäre, so nicht handhaben.

Mittels Recover konnte ich die Box auf jeden Fall auf die 6.83 flashen - mein Freetz-Image ließ sich darüber nicht installieren...
Logisch…

Hat jemand mal für mich die Kurzfassung?
-> https://yourfritz.de/desc-eva

Und deine Ausgabe deutet darauf hin, dass du das Script "EVA-FTP-Client.ps1" nicht korrekt bei GitHub heruntergeladen hast (sondern HTML-Quelltext anstatt per "RAW-Download"). Du versuchst da quasi eine HTML-Seite auszuführen anstatt eines PowerShell Script… :rolleyes: Aber auch das ist in der verlinkten Anleitung beschrieben.

BTW:
Warum überhaupt mit so einer alten FRITZ!OS-Version einsteigen bzw. offensichtlich die Verwendung des (abgekündigten) Freetz (anstatt Freetz-NG)? FRITZ!OS Ver. 7.29 könnte ich aktuell noch nachvollziehen aber nicht Ver. 7.12. Aktuell ist zudem bereits FRITZ!OS 7.50 bei der 7590…
 
Zuletzt bearbeitet:
Die Artikel-Nr. 2000-2784 ist eine (normale) FRITZ!Box 7590 und keine FRITZ!Box 7590 AX v1, keine 7590 AX v2 und auch keine 7590 ET.
Also auf der Box steht eindeutig diese Artikelnummer UND dass es wohl eine ET ist ... Wo ist denn der Unterschied zwischen ner 7590 und ner ET (die AX kenne ich)?

Wie gesagt - ich hatte das vor Jahren mal gemacht und konnte mich an keine Methode erinnern. Also habe ich es halt (wie bei der alten 7490) mit einem "Downgrade" versucht.

Es liegt wahrscheinlich echt am fehlerhaften ps-Script. Ich habe das yourfritz-master mal mit Linux gezogen und die Dateien auf den Windows-PC gepackt. Dann werde ich später mein (self-signed) freetz-ng_7.50-Image mal damit versuchen, auf die Kiste zu installieren.
 
Argh - da hätte ich selber drauf kommen können.
Danke Dir;)

...

Hmmm ... Hab jetzt wie folgt geflasht:
.\EVA-FTP-Client.ps1 -Debug -Verbose -ScriptBlock { BootDeviceFromImage C:\Users\B\Downloads\Freetz\7590_07.50.all_freetz-ng-21295M-d94d91781_20230222-202517.image }

Ergebnis:
Code:
DEBUG: Response:
220 ADAM2 FTP Server ready

================
DEBUG: Sent
USER adam2
================
DEBUG: Response:
331 Password required for adam2

================
DEBUG: Sent
PASS adam2
================
DEBUG: Response:
230 User adam2 successfully logged in

================
DEBUG: Sent
SYST
================
DEBUG: Response:
215 AVM EVA Version 1.3578 0x0 0x46409

================
DEBUG: Sent
GETENV memsize
================
DEBUG: Response:
memsize               0x20000000

200 GETENV command successful

================
DEBUG: Memory size found    : 0x20000000 (512 MB)
DEBUG: Memory size used     : 0x08000000 (128 MB)
DEBUG: Image size found     : 0x03093000
DEBUG: Set memory size to   : 0x04f6d000
DEBUG: Set MTD RAM device to: 0x84f6d000,0x88000000
DEBUG: Sent
SETENV memsize 0x04f6d000
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
SETENV kernel_args_tmp mtdram1=0x84f6d000,0x88000000
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
TYPE I
================
DEBUG: Response:
200 Type set to BINARY

================
DEBUG: Sent
MEDIA SDRAM
================
DEBUG: Response:
200 Media set to MEDIA_SDRAM

================
DEBUG: Uploading file 'C:\Users\B\Downloads\Freetz\7590_07.50.all_freetz-ng-21295M-d94d91781_20230222-202517.image' to
'0x84f6d000 0x88000000' ...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,178,1,12,2)

================
DEBUG: Sent
STOR 0x84f6d000 0x88000000
================
DEBUG: Response:
150 Opening BINARY data connection

================
DEBUG: Sent
SETENV memsize 0x20000000
================
DEBUG: Sent
UNSETENV kernel_args_tmp
================
DEBUG: Sent
QUIT
================
Ausnahme beim Aufrufen von "Invoke" mit 0 Argument(en):  "Error uploading image file."
In C:\Users\B\Downloads\Freetz\eva_tools\EVA-FTP-Client.ps1:638 Zeichen:21
+                     $ScriptBlock.Invoke()
+                     ~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], ParentContainsErrorRecordException
    + FullyQualifiedErrorId : RuntimeException

EDIT:
Nach Installation von Powershell 7 kommt die Meldung so:
Code:
ParentContainsErrorRecordException: C:\Users\B\Downloads\Freetz\eva_tools\EVA-FTP-Client.ps1:638
Line |
 638 |                      $ScriptBlock.Invoke()
     |                      ~~~~~~~~~~~~~~~~~~~~~
     | Exception calling "Invoke" with "0" argument(s): "Error uploading image file."
 
Zuletzt bearbeitet:
Dem Dateinamen des Versuches aus #55 zufolge deutet alles darauf hin, dass du versucht hast kein in-memory Image hochzuladen.

Während deinem Versuch in Beitrag #51 hattest du dazu wohl ein in-memory Image verwendet aber leider nicht das passende Script…
 
  • Like
Reaktionen: BenGurion_
Und dann bitte auch einen frischen Checkout des YourFritz-Repos verwenden (oder einen neuen Download des EVA-FTP-Client.ps1-Skripts) - ich habe vorhin die Änderung, daß die Wartezeit auf die Quittung nach dem Upload von der Größe der übertragenen Daten abhängig ist (< 1 MB => 5", > 1 MB => 15"), in den Hauptzweig übernommen (https://github.com/PeterPawn/YourFritz/commit/f0b0942846ffcc9ff8a5e8c038350fbd2f63e215). Damit sollten dann die (neuerdings auftretenden, weil die Images deutlich größer geworden sind) Timeouts als Ursache für Abbrüche der Vergangenheit angehören, solange man nicht gerade eine Ethernet-Verbindung mit nur 10 MBit/s verwendet.

Denn dann dauert eben schon die Übertragung 100x so lange, wie mit einer 1 GBit/s-Verbindung und da sich die Geschwindigkeit der Ethernet-Verbindung nicht zuverlässig ermitteln läßt (spätestens ein Switch im Datenweg kann dann seinerseits auch die Geschwindigkeit wieder ändern), muß man an dieser Stelle Kompromisse eingehen und mit weniger als 100 MBit/s (was immer noch 10x langsamer ist als eine GE-Verbindung) sollte man auch nicht arbeiten müssen.

Dabei braucht dann ein Image von knapp 40 MB (so zu sehen bei der aktuellen 07.50 für die 7590, andere Images sind tatsächlich noch größer, aber die Behandlung von FIT-Images ist hier ja noch gar nicht vorgesehen) ungefähr 3 bis 4 Sekunden bei 100 MBit/s - darauf basiert(e) die Annahme, daß 5 Sekunden für die Übertragung ausreichend sein sollten. Offenbar ist aber der Overhead noch deutlich größer als angenommen (viele Pakete, viele ACKs, wenig Optimierung seitens des FTP-Servers in EVA und die Bestätigung kommt ja auch erst, wenn der Kernel erfolgreich entpackt werden konnte) und so machen die erwähnten 40 MByte als Image auch bei einer 100 MBit/s-Ethernet-Verbindung ab und an schon mal Späne (denn der Fehlercode für "falsches Image-Format" taucht da im Protokoll ja noch gar nicht auf, obwohl er tatsächlich (anhand des Dateinamens) zu erwarten sein dürfte).

Das sollte bei 15 Sekunden nicht mehr so sein - für eine 10 MBit/s-Verbindung (wo die 40 MByte um die 35 bis 40 Sekunden auf dem Draht brauchen) reicht das aber immer noch nicht. Da müßte man dann (sofern man WIRKLICH nur mit 10 MBit/s verbinden kann, was heute fast nicht mehr vorkommen sollte) den Wert für das Timeout immer noch manuell anpassen.
 
  • Like
Reaktionen: BenGurion_
Juhu .... Es hat geklappt :)

Danke Euch beiden!

Muss ich noch irgendwas beim Backup/Restore beachten, damit ich alle Settings auf die neue Fritze bekomme?

EDIT: Hab jetzt das backup mit Passwort und WVM-Settings gezogen und konnte alles auf die neue Fritze überspielen. Sieht aktuell alles super aus - 2.4er WLAN geht wieder (inkl. mesh) und die Box pfeift auch nicht.

Jetzt bin ich endlich wieder auf dem aktuellen Stand.
 
Zuletzt bearbeitet:
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.