7490 - ständige Reboots

Status
Für weitere Antworten geschlossen.

sf.pkg

Neuer User
Mitglied seit
25 Apr 2016
Beiträge
19
Punkte für Reaktionen
4
Punkte
3
Ein gepflegtes Hallo in die Runde.

Ich habe ein Problem mit einer 7490 (keine Providerbox) durch dauernde Reboots.

Die Kurzfassung zur Geschichte der Box...sie lag ca. 3 Jahre im Schrank und ich bin davon ausgegangen, dass sie funktionstüchtig ist.
Die erweiterte Fassung kann ich bei Bedarf auch noch zum Besten geben, allerdings lässt die auch keine weiteren Rückschlüsse zu.

Bisher habe ich verschiedene Recoverys (6.03, 6.60, 7.01, 7.12, 7.21, zuletzt 7.27) zur Box geschickt. Das Programm meldete bis auf wenige Ausnahmen, nach denen ich den Vorgang einfach wiederholte, "FRITZ!Box 7490 erfolgreich wiederhergestellt! Die Wiederherstellung ist nach einem Neustart des Gerätes abgeschlossen.".

Nachdem das nichts half habe ich mit der Powershell ein 7.21er und ein 7.27er in-memory zur Box geschickt jeweils in beiden Partitionen. Sollte linux_fs_start noch nicht gesetzt worden sein, so habe ich dies gemacht. Dies ergab auch keine Änderung.

Danach habe ich per Linux-PC ebenfalls ein 7.21er und ein 7.27er über image2ram und eva_to_memory zur Box geschickt. Auch hier stehe ich immer noch vor dem gleichen Problem. Die Box führt ständig Reboots durch.

Vielleicht kann mir ja von Euch jemand sagen, was hier falsch läuft.
 

Anhänge

  • eva_to_memory_seriell.txt
    76.5 KB · Aufrufe: 21
  • image2ram-eva_to_memory.txt
    611 Bytes · Aufrufe: 7
  • powershell.txt
    1.9 KB · Aufrufe: 6
  • recovery_bootlog_seriell.txt
    161.1 KB · Aufrufe: 8
Tip von einem Laien: Netzteil schon mal getauscht ?
 
Ja. Schon 2x.
Das erste war ein 5A-Netzteil und das 2. ist ein 2,5A-Netzteil. Beide funktionieren zuverlässig an anderen Geräten.
 
Kondensator Deckel noch flach.
 
Rein optisch sieht die Ober- und Unterseite i.O. aus beim Blick durch die dicke Linse. Ich kann dort weder eine verbrannte Stelle noch einen aufgeblähten C entdecken.
 
Ich habe mir jetzt zwei Protokolle angesehen, das mit eva_to_memory und das vom Recovery-Programm. Daß die Serielle zur Verfügung steht, ist schon mal gut ... aber die Erwartungshaltung, daß sich durch die Benutzung anderer Programme etwas ändern würde, ist (fast) beleidigend (nicht zuuu ernst nehmen), denn es unterstellt ja, daß "Nachbauten" nicht genauso arbeiten würden, wie "das Original" von AVM (was es ja nur für Windows gibt und was noch deutlich mehr macht, als nur irgendeine Firmware - und dann nicht mal eine "beliebige" - zu installieren).

Aber ich drücke mal ein Auge zu ( ;) ) und versuche mal eine Erklärung für die jeweiligen Protokolle.

Jeder Startversuch, in dessen Protokoll diese Zeilen auftauchen:
Rich (BBCode):
[    1.930000] [ifx_jffs2_parser_function] exit on mtd ram-filesystem
[    1.990000] 2 find_squashfs partitions found on MTD device ram-filesystem
[    1.990000] Creating 2 MTD partitions on "ram-filesystem":
[    2.000000] 0x000000290d00-0x0000020c0d00 : "rootfs_ram"
[    2.010000] 0x000000000000-0x000000290d00 : "kernel_ram"
[    2.010000] mtd-ram mtd-ram: registered mtd device
ist einer, bei dem eine Firmware in den Hauptspeicher geladen und dort gestartet wurde. Das sind die (zusätzlichen) Zeilen, die man sieht, wenn der Filesystem-Scanner im Kernel die ins RAM geladenen Daten gefunden hat. Üblicherweise führt deren Vorhandensein jetzt dazu, daß über das Skript /sbin/flash_update nichts weiter geschieht, als das System aus dem RAM in den Flash-Speicher zu schreiben - danach startet das System neu. Daher sind auch die "Soft-Reboots" beim jeweils ersten Start vollkommen normal. Beim nächsten Start gibt es dann die Daten im RAM nicht mehr und das System wird nun aus dem Flash-Speicher geladen. Damit sind auch Fehlernachrichten, die beim ersten Start NICHT aufgetreten sind, kein Zeichen dafür, daß danach schon alles gut gehen wird - das System wird nur bis zu einem gewissen Punkt initialisiert (praktisch eigentlich nur der Kernel, aus dem Dateisystem wird fast nichts genutzt außer dem erwähnten Skript und den darin aufgerufenen Programmen).

Beim zweiten Start sind in beiden Protokollen Fehler beim Lesen des SquashFS-Dateisystems zu sehen ... hier rächt es sich jetzt, wenn man alles durcheinander testet und dann letztlich doch vergißt, die Umstände, unter denen eine bestimmte Protokoll-Datei entstanden ist, hinreichend genau zu beschreiben.

Da kaum davon auszugehen ist, daß der gesamte NAND-Flash defekt ist und außerdem angenommen werden kann, daß die Daten im RAM noch korrekt waren, macht es deutlich mehr Sinn, die Vorgänge einmal mit dem Wert 0 für linux_fs_start auszuführen und einmal mit dem Wert 1 - und dafür dann die jeweiligen Protokolle bereitzustellen (natürlich mit passender Kennzeichnung, welches wozu gehört). Dazu noch ein kleiner Tipp: Wenn man direkt nach der Nachricht: [avm_debug] redirecting kernel-messages (/dev/debug) auf der seriellen Console einfach noch einmal die Enter-Taste drückt, wird in Folge des damit ausgeführten Starts einer Shell-Instanz auch die weitere Ausgabe der Kernel-Message auf der Console erfolgen - das vermeidet dann Pausen zwischen Sekunde 16 und irgendwelchen (viel) später doch wieder einsetzenden Ausgaben.

Wobei ich auch ziemlich verblüfft bin, daß/wenn eine (unmodifizierte) Firmware sich 708 Sekunden Zeit läßt, bevor der Watchdog, der den Start überwacht, zuschlägt (oder meinetwegen auch ein paar Sekunden weniger, weil der nicht gleich in der ersten Sekunde scharf gemacht wird) ... das sieht dann fast wieder danach aus (ist aber im Log durch die fehlenden Zeilen nicht zu erkennen), als ob ein Mounten (das ein Lesen der Verwaltungsstrukturen beinhaltet, aber kein komplettes Lesen ALLER Daten) noch möglich war und daher der Init-Watchdog regulär abgeschaltet wurde, bevor dann spätere Zugriffe doch noch zu einer "kernel panic" führen.

Ich würde jetzt erst einmal (systematisch und auch so "protokolliert" hier für Hilfewillige) testen, ob tatsächlich der gesamte Flash betroffen ist (manchmal hilft hier ja auch dessen Management mit, besonders bei Flash mit ONFI-Support, indem tatsächlich defekte Blöcke auch als solche markiert und durch "spare blocks" ersetzt werden), denn es werden ja einmal mtdblock0 und mtdblock1 benutzt und für linux_fs_start 1 dann mtdblock2 und mtdblock3. Den beiden Protokollen, die ich mir angesehen habe (s.o.), zufolge, wurden beide mit linux_fs_start 0 erstellt. Wenn dann tatsächlich beide Sets nicht funktionieren, kann/müßte man ggf. mit passenden Tools (mit einer selbst zusammengestellten Firmware) noch einmal versuchen, den NAND-Flash genauer anzusehen - ich kann mich an einen Fall hier erinnern (der liegt noch gar nicht sooo lange zurück, max. 2 Jahre würde ich sagen), wo sich auf einer Box (allerdings einer, die mit dem UBI-Layer arbeitete) auch partout kein System installieren ließ (auch nicht mit AVM's Recovery-Programm), weil sich die UBI-Strukturen nicht einrichten lassen wollten.

Da half es dann, den Flash mit passenden Kommandos zuvor noch einmal explizit zu löschen. Wobei das bei der 7490 eigentlich erfolgt, soweit ich mich erinnere (bei der 07.27 würde ich dafür aber die Hand auch nicht ins Feuer legen wollen und müßte erst noch einmal nachsehen) - aber anstelle weiterer Spekulationen (und etwas anderes können Überlegungen nicht sein, solange sie nicht auf Protokollen oder einer "Nachschau" basieren) sollte man das erst einmal Schritt für Schritt angehen und schauen, was beim anderen Partition-Set passiert. Zumindest die YAFFS2-Strukturen (das verwendete SquashFS-Image liegt ja erst innerhalb dieser Partition als Datei vor) passen ja anscheinend noch - auch die gehen eigentlich erst mal alle Blöcke durch (wobei es da auch noch einen Checkpoint-/Cache-Mechanismus gibt, der das Mounten beschleunigen soll) und dabei müßten Fehler auch schon auffallen, wenn es sich um "echte" Probleme des Flash-Speichers handelt.
 
Aber ich drücke mal ein Auge zu
Danke. ;)

Jetzt habe ich beides noch einmal durchgespielt. Im Moment ist es so, dass die Box in beiden Partitionen hängen bleibt mit durchgehend leuchtender Power/DSL-LED.
Wenn man direkt nach der Nachricht: [avm_debug] redirecting kernel-messages (/dev/debug) auf der seriellen Console einfach noch einmal die Enter-Taste drückt
...das habe ich so schnell wie möglich...
 

Anhänge

  • PS_start_0.txt
    3.1 KB · Aufrufe: 7
  • PS_start_1.txt
    4.1 KB · Aufrufe: 5
  • seriell_start_0.txt
    23.3 KB · Aufrufe: 6
  • seriell_start_1.txt
    224.9 KB · Aufrufe: 4
Code:
13.730000] end_request: I/O error, dev mtdblock0, sector 15360
sieht nach defekten Flash aus.
 
Versuch einmal den Flash-Speicher mit Kältespray ordentlich abzukühlen und dann starte einen erneuten Versuch - hilfts nicht schadt's auch nicht.
 
Zuletzt bearbeitet:
Könnte auch Eiswürfel in Plastikfolie oder Cellophan helfen (nur damit kein Wasser auf den Print bzw. unter den Chip kommt).
 
Das sieht alles recht wild aus ... und am Ende so, als wäre entweder bereits das verwendete Image defekt oder der Hauptspeicher der Box oder vielleicht doch auch die verwendete LAN-Schnittstelle - und wenn diese Fehler nicht reproduzierbar sind (erst recht nicht an denselben Adressen), dann sollte man tatsächlich noch einmal die Stromversorgung der Box in den Blick nehmen - solche "instabilen" Probleme sind dann doch häufig auf unzuverlässige Versorgung zurückzuführen. Aber dazu sollte man (solange es sich mit simplem Tausch des Netzteils nicht regeln läßt) dann doch erst mal prüfen, ob es nun immer dieselben Fehler sind oder doch immer wieder andere/neue.

Schon direkt beim ersten Start nach dem Hochladen des Images in den Hauptspeicher treten jetzt Probleme beim Lesen eines SquashFS-Images auf ... und zwar für beide Partition-Sets. Der Witz ist nur, daß zu diesem Zeitpunkt noch gar kein Flash-Speicher im Spiel ist (auch wenn die Zeile aus #8 auf einen (weiteren) Fehler in mtdblock0 hinweist, der aber erst mal ignoriert werden sollte, denn der ist bei linux_fs_start 1 auch nicht vorhanden - da wird mtdblock0 ja auch nicht verwendet), denn es wird erst einmal nur das "äußere" SquashFS-Image gemountet (das ist auch erst wieder ein SquashFS-Image, seitdem AVM die Rolle rückwärts gemacht hat und kein gefaketes SquashFS-Image (ein ext2-Image mit einem Pseudo-Header) mehr verwendet wird) und dessen Daten werden dann in die (zuvor gelöschte) YAFFS2-Partition kopiert - etwas anderes als das "äußere" SquashFS-Image wird beim "Flashen" der Firmware gar nicht gemountet und kann daher auch nicht gelesen werden. Was andererseits auch auffällt (weshalb ich den Fehler auch für "nicht stabil" halte), sind die wechselnden "Blocknummern" im SquashFS-Image (das sich ja nur im RAM befindet), bei denen die Lesefehler auftreten:
Rich (BBCode):
[    6.920000] Freeing unused kernel memory: 264K (8092e000 - 80970000)
[    8.420000] SQUASHFS error: xz_dec_run error, data probably corrupt
[    8.430000] SQUASHFS error: squashfs_read_data failed to read block 0xfeefb8
[    8.440000] SQUASHFS error: Unable to read data cache entry [feefb8]
[    8.440000] SQUASHFS error: Unable to read page, block feefb8, size 19f4
[    8.450000] SQUASHFS error: Unable to read data cache entry [feefb8]
[    8.460000] SQUASHFS error: Unable to read page, block feefb8, size 19f4
Rich (BBCode):
[    6.770000] Freeing unused kernel memory: 264K (8092e000 - 80970000)
[    6.910000] SQUASHFS error: xz_dec_run error, data probably corrupt
[    6.910000] SQUASHFS error: squashfs_read_data failed to read block 0x1e16804
[    6.920000] SQUASHFS error: Unable to read data cache entry [1e16804]
[    6.930000] SQUASHFS error: Unable to read page, block 1e16804, size 7880
[    6.930000] SQUASHFS error: Unable to read data cache entry [1e16804]
[    6.940000] SQUASHFS error: Unable to read page, block 1e16804, size 7880
- wie oben schon geschrieben, stammen diese Zeilen aus dem Teil des Protokolls, wo die RAM-Partitionen aufgelistet sind ... also aus dem Start, wo der Flash-Speicher nur gelöscht und beschrieben wird und gar nicht gelesen. Deshalb halte ich das hier:
Rich (BBCode):
[   13.720000] request botched: dev mtdblock0: type=1, flags=12248000
[   13.720000]   sector 15360, nr/cnr 8/65544
[   13.720000]   bio 85b638c0, biotail 85b638c0, buffer 839cd000, len 4096
[   13.730000] end_request: I/O error, dev mtdblock0, sector 15360
auch eher für einen Fehler beim Löschen/Schreiben und nicht beim Lesen - und ich habe trotzdem keine Ahnung, was da "verpfuscht" wurde. Dazu müßte man in den Kernel-Quellen nach der Nachricht und den Umständen, wann diese ausgegeben wird und welcher Wert was bedeutet, suchen. Jedenfalls läuft das jetzt darauf hinaus, daß schon die in den Flash geschriebenen Daten offenbar nicht korrekt sind - davon war allerdings in den Protokollen in #1 noch nichts zu sehen, daher stellt sich die Frage, ob die Probleme wachsen oder ob da doch noch etwas anders war.

Ich glaube zwar nicht an ein Image-Problem, würde aber (schon wg. des guten Gewissens, daß man keine mögliche Fehlerursache ausgelassen hat bei der Prüfung) noch einmal mit dem unsquashfs4-be (https://github.com/PeterPawn/yf_bin/tree/761344186579a26a7f60791f76f0f938b19b3a44/squashfs) - das sollte unter jedem 64-Bit-Linux funktionieren - das Image entpacken lassen ... beim Einsatz der Option -scan (oder -k) funktioniert das auch mit einem Image, was davor noch einen Kernel enthält. Wenn das Entpacken problemlos möglich ist, stimmen die Daten in der Image-Datei.

Dann käme (wenn man's Schritt für Schritt machen wollte) der LAN-Port ins Spiel - der kann entweder defekt sein (oder auch nur das verwendete Kabel - hier lohnt ggf. auch mal ein anderer Port an der Box, wobei 1+2 denselben (internen) PHY verwenden und 3+4 jeweils einen externen haben) oder auch von einem Problem mit der Stromversorgung betroffen sein.

Wann hast Du eigentlich die serielle Schnittstelle verbunden und wie genau? Der VCC-Pin sollte NICHT verbunden werden, der verwendete Wandler (ich gehe mal davon aus, daß Du einen RS232-USB-Wandler verwendest) sollte seine eigene Stromversorgung haben, ggf. aus dem angeschlossenen USB-Port. Fehler hier könnten natürlich auch Probleme machen - denn bei ernsthaften Problemen mit der Stromversorgung, die zu Fehlern im RAM oder bei anderen Komponenten führen (z.B. eben dem LAN-Port), würde ich ab und an auch mal ein Problem auf der Seriellen erwarten (und damit ein "komisches" Zeichen bei der Ausgabe), auch wenn deren Pegel mit 3,3 V arbeiten. Notfalls würde ich auch mal zum Multimeter greifen und die Versorgungsspannungen auf dem PCB messen - mit etwas Pech sind die Schaltregler hinüber bzw. die Werte liegen außerhalb der Toleranzen. Mit passendem Equipment kann man vielleicht auch mal eine eigene Stromversorgung (hinter den Reglern) anlegen - aber es scheint sich tatsächlich immer mehr in Richtung Hardware-Problem zu verlagern - was mich an Deiner Stelle trotzdem nicht davon abhalten würde, das erst noch einmal genauer zu untersuchen, bevor ich die Box auf den Müll haue.

So eine genauere Untersuchung (auch ohne jegliche Hardware-Kenntnisse und/oder -Werkzeuge) könnte z.B. damit beginnen, die Firmware so zu ändern, daß anstelle des Flashens nur gewartet wird (ggf. den Watchdog abschalten, wobei der iirc bei der 7490 da noch gar nicht aktiv ist, weil das Flashen aus der /etc/inittab in der Wrapper-Partition aufgerufen wird) - damit kann man dann eine Shell auf der Seriellen starten und dort mit entsprechenden BusyBox-Kommandos prüfen, ob im RAM tatsächlich eine 1:1-Kopie der Daten steht nach dem Upload und ob sich das SquashFS-Image manuell mounten läßt oder nicht - ja, sogar das Kopieren der Daten aus dem gemounteten (Wrapper-)Dateisystem kann man manuell testen.
 
Ui, das ist viel. Ich werde mal versuchen, das nach und nach abzuarbeiten. Als Wandler habe ich diesen

DSD TECH SH-U09C5 USB zu TTL UART Konverterkabel mit FTDI Chip Unterstützung 5V 3.3V 2.5V 1.8V TTL

Ich habe aber auch noch einen anderen da, die Du selbst in Deinen Boxen eingebaut hast von AZD. Den könnte ich natürlich auch mal nehmen.

Netzwerkkabel werde ich noch mal tauschen und den Eingang wechseln. NT tausche ich nun auch noch mal aus.

Das 7.27 habe ich direkt vom AVM-FTP, beim 7.21er weiß ich es nicht mehr. Wo kann ich denn aus sicherer Quelle ein vergangenes Image laden, welches auch ganz sicher funktionieren muss, solang es kein anderes Hardwareproblem gibt? Muss ja nicht das neueste sein.
 
Am besten im "Suche Firmware ..."-Thread anfragen und sich evtl. Firmwares von mehreren Leuten schicken lassen. Die meisten Dateien dürften alte Originale von AVM sein; bei mehreren Kopien kannst Du per Dateivergleich "faule" oder defekte Dateien aussortieren.
 
Versuch einmal den Flash-Speicher mit Kältespray ordentlich abzukühlen
Welchen? Die 7490 hat 2.

Am besten im "Suche Firmware ..."-Thread anfragen und sich evtl. Firmwares von mehreren Leuten schicken lassen.
Ich würde hier die originalen von AVM bevorzugen und für die 7490 braucht man dazu keine Anfragen erstellen da diese dort schon im Update 5 zur Verfügung gestellt werden.
 
Ich meinte auch weniger das AVM-Archive (das mit dem "Image" ist halt keine wirklich genaue Bezeichnung, zumal die inneren Werte ja dann auch noch auf .image enden), als vielmehr das verwendete "in-memory"-Image. Fehler sind zwar extrem unwahrscheinlich, aber das Entpacken dieses Images (wenn man ein Linux-System hat) mit dem schon fertigen Tool kostet i.d.R. keine fünf Minuten (das wäre schon lang) und damit kann man zumindest sicher sein, daß ein Entpacken möglich ist. Wie schon erwähnt, ist das in meinen Augen ohnehin mehr die "Gründlichkeit", die am Ende verhindern soll, daß man sich ärgert, weil man nicht ganz vorne bei den Fehlerursachen begonnen hat mit der Suche.

Ansonsten kann man bei Images, die man von Fremden bezieht, ja auch einfach selbst die Signatur prüfen: https://www.ip-phone-forum.de/threa...gnieren-der-avm-firmware.286213/#post-2166188 + https://github.com/PeterPawn/YourFritz/tree/main/signimage - der öffentliche Schlüssel von AVM für die 7490 ist dieser:
Rich (BBCode):
~ # cat /etc/avm_firmware_public_key1
00cbdcfcc6ac9a1657a1c6f197e3056f1d68b8bb7deb480249e5f0ded677c54fde10be5a14b1e6a395483bd4bee608c09d385b1e90564ca84b9272926c45bfd328d7da876567e3e15f719800a53ecc21af583431d0c40806ca89f6f958e188ec69572df09e24de71eaa0782c01877158f286afd95037e
7eb059367c466095944e1
010001
 
Mh, dann müßte man mit dem Schlüssel überprüfen können, ob ein Image fehlerfrei ist ... oder verwechsel' ich da was?
 
Dann fange ich mal an mit unsquashfs...
Ich habe mir dazu einmal das Zwischenupdate 7.12 gezogen. Mit dem funktioniert es nicht, nachdem ich es mit image2ram umgewandelt habe.
Code:
kurt@kurt-HP-630:~/yourfritz-master/eva_tools$ ./image2ram < /home/kurt/Downloads/7490-07.12.image > /home/kurt/Downloads/7490-07.12.image.in-memory
kurt@kurt-HP-630:~/yourfritz-master/eva_tools$
Mit dem 7.21 und 7.27, was ich schon hatte, funktioniert es.
Code:
root@kurt-HP-630:/home/kurt/yf_bin-master/squashfs# ./unsquashfs4-be -k /home/kurt/Downloads/7490-07.27.image.in-memory
Found a valid superblock at offset 0x00290D00 while scanning /home/kurt/Downloads/7490-07.27.image.in-memory.
Filesystem on /home/kurt/Downloads/7490-07.27.image.in-memory is xz compressed (4:0)
Parallel unsquashfs: Using 2 processors
95 inodes (590 blocks) to write

[===============================================================|] 590/590 100%

created 8 files
created 10 directories
created 86 symlinks
created 1 devices
created 0 fifos
root@kurt-HP-630:/home/kurt/yf_bin-master/squashfs# rm -r squashfs-root
root@kurt-HP-630:/home/kurt/yf_bin-master/squashfs# ./unsquashfs4-be -k /home/kurt/Downloads/7490-07.12.image.in-memory
Unable to find something looking like a SquashFS superblock in /home/kurt/Downloads/7490-07.12.image.in-memory.
root@kurt-HP-630:/home/kurt/yf_bin-master/squashfs# ./unsquashfs4-be -k /home/kurt/Downloads/7490-07.21.image.in-memory
Found a valid superblock at offset 0x00290400 while scanning /home/kurt/Downloads/7490-07.21.image.in-memory.
Filesystem on /home/kurt/Downloads/7490-07.21.image.in-memory is xz compressed (4:0)
Parallel unsquashfs: Using 2 processors
95 inodes (582 blocks) to write

[===============================================================|] 582/582 100%

created 8 files
created 10 directories
created 86 symlinks
created 1 devices
created 0 fifos
root@kurt-HP-630:/home/kurt/yf_bin-master/squashfs#

Den Wandler habe ich getauscht, ein anderes Netzwerkkabel hängt im Moment an ETH4, ein weiteres anderes passendes NT habe ich jetzt auch dran. Die Suche danach hat am längsten gedauert.

Ich mach dann mal morgen weiter. War ein langer Tag...
 
  • Like
Reaktionen: PeterPawn
Daß sich das Image der 07.12 so nicht entpacken läßt, ist normal ... da wird noch das (oben schon mal angerissene) "Pseudo-SquashFS" verwendet, was in Wahrheit ein ext2-Image ist und damit kann das Programm natürlich nichts anfangen - das versteht nur "echtes" SquashFS-Format.
 
Bisher habe ich verschiedene Recoverys (6.03, 6.60, 7.01, 7.12, 7.21, zuletzt 7.27) zur Box geschickt. Das Programm meldete bis auf wenige Ausnahmen, nach denen ich den Vorgang einfach wiederholte, "FRITZ!Box 7490 erfolgreich wiederhergestellt! Die Wiederherstellung ist nach einem Neustart des Gerätes abgeschlossen.".
Du hast doch schon gleich am Anfang die Recoverys ohne Fehler installiert, denkst du die waren alle Fehlerhaft sodass du den Schlüssel überprüfen musst?
 
Status
Für weitere Antworten geschlossen.
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.