[Problem] Powerline 1260 kein Zugriff möglich

[NDiIPP]

Laut ftp.log wird das (in-memory) Image erfolgreich in den RAM des Gerätes hochgeladen, mehr kann man nicht erwarten vom Recovery-Tool bzw. mehr erreicht man beim manuellen hochladen eines in-memory Images per FTP auch nicht. Anschließend sollte das System aus dem RAM starten und sich dann selbst vom RAM in den NAND-Flash schreiben. Darauf hat man aber eben keinen direkten Einfluss, dass muss das Gerät schon selbst machen.

Die Frage wäre also, scheitert es bereits beim Flash-Versuch oder erst der reguläre Start der FW aus dem Flash-Speicher…

 

[AugeK]

Da die Kiste neu startet wenn der Balken beim Laden irgendwo zwischen 50 und 80% ist gehe ich davon aus dass das Laden scheitert

 

[NDiIPP]

Das von dir gezeigte ftp.log behauptet das Gegenteil:

[...]
0:18:798: now send image mtd1 to ram
0:18:813: send image (size=18627072) for mtd1
0:30:614: recv: 226 Transfer complete
0:30:614: load to ram (mtd1) ok
1:06:561: ----EOF---

 

[AugeK]

Ich bin durchaus in der Lage zu erkennen wenn das Netzwerk Symbol auf "keine Verbindung " springt oder die LED an der Kiste genau so leuchten/blinken wie beim Neustart.
Das Recovery behauptet auch nach einem Neustart wäre das Recovery abgeschlossen, die Kiste bootet aber nicht hoch, sie startet dann aber nicht mal von allein neu.

Nachklapp: ist es normal dass der 1260 irgendwo zwischen 50 und 80% einen Neustart macht?
Gefühlt passiert das nicht immer an der gleichen Stelle.
Der Fortschrittsbalken geht recht zügig auf 50%, danach geht es sehr zäh weiter.
Das ist dann der Punkt wo der Neustart sich ankündigt.

 

[NDiIPP]

Das Recovery behauptet auch nach einem Neustart wäre das Recovery abgeschlossen, die Kiste bootet aber nicht hoch, sie startet dann aber nicht mal von allein neu.

Wie ich schon schrieb, das Recovery-Tool ist gar nicht dazu in der Lage den Erfolg des Recovery zu erkennen, denn das hat nach dem Start des Images aus dem RAM gar keine Verbindung mehr zum betreffenden Gerät (aber erst danach erfolgt der eigentliche Schreibvorgang des Images in den Flash) und kann so weder einen Erfolg noch Misserfolg feststellen.

Es bleibt jedoch dabei, dass zumindest laut dem von dir gezeigten ftp.log das Hochladen des Images in den RAM erfolgreich war. Mehr kann das Recovery-Tool sowieso nicht machen bzw. erreichen.

 

[AugeK]

Ich zweifele schlicht daran, dass das Hochladen in den RAM erfolgreich war, da das Gerät neu startet bevor der Fortschrittsbalken komplett durchgelaufen ist.
Bei allen anderen Geräten die ich recovert habe war das nicht der Fall, da ist der Balken komplett durchgelaufen und erst danach hat es neu gestartet.
Neustarts mitten drin hatte ich da nie.

 

[stoney]

Ich werfe hier einfach mal etwas ein, da ich selbst keinen 1260 habe....

linux_fs_start - also vll. mal das Partitionsset ändern, falls überhaupt möglich....

manueller Upload des Images als in-memory.image

 

[AugeK]

Zunächst mal Danke an Stoney, endlich mal ein klarer, leicht nachvollziehbarerTip!
Habe linux_fs_start mal getestet:
Das Kommando wird angenommen und auch als ausgeführt angezeigt, die Einstellung ist aber nach Neustart wieder weg.

Allerdings ergibt sich ein neues Problem:

0:51:386: recv: 200 Media set to MEDIA_SDRAM
0:51:387: error (write image): 10054
0:51:400: error on ram-(nand)-update
0:51:518: exit: errorcode=10054
0:51:518: ----EOF---

Das Recovery läuft nicht mehr durch, wegen eines Problems mit mtd1


Das mit "recovered=2" ist auch neu


Nachklapp:
Läuft wieder durch, mit dem "recovered=2", was auch immer das heißt.
Am Endergebnis ändert sich leider nichts

 

[stoney]

Das recovered=n bedeutet so weit ich mich erinnere, dass das Recovery soweit "durch" war

Stell mal mit linux_fs_start um, verabschiede Dich mit "quote BYE" und lass dann das Recovery nochmals laufen

 

[AugeK]

Hab ich schon gemacht, bringt leider nix.

Habs eben trotzdem doch noch mal versucht, man kann ja nie wissen:


Versuch mit 7.56 würde laufen wollen, aber wieder reboot vor Abschluss

 

[NDiIPP]

Das recovered=n bedeutet so weit ich mich erinnere, dass das Recovery soweit "durch" war

Fast richtig. Das "recoverd=2" wird m.W.n. bereits vom Recovery-Tool gesetzt, bevor das Image in den RAM hochgeladen wird, also genauer beim Schreiben in mtdnand (bzw. eben mtd8 laut GUI des Recovery-Tool), was im ftp.log aus Beitrag #20 an folgender Stelle geschehen ist:

0:14:632: update flash-partition (mtdnand)
0:14:648: send image (size=1760) for mtd8
0:15:381: recv: 226 Transfer complete
0:15:381: flash write (mtd8) ok
0:15:506: successfully update of mtd8

.
Also noch bevor das Recovery-Tool "durch" ist (ganz zu schweigen vom Recovery-Vorgang selbst, den das Recovery-Tool selbst schon nicht mehr mitbekommen kann).

Stell mal mit linux_fs_start um, verabschiede Dich mit "quote BYE" und lass dann das Recovery nochmals laufen

Das bringt nichts (mehr). Aktuelle Recovery-Tools von AVM entfernen beim Recovery-Vorgang die Variable (entspricht dann dem, was man in #30 im Screenshot sieht, also "501 environment variable not set). Abgesehen davon, dass ein "not set" praktisch gleichbedeutend mit dem Wert "0" ist und somit auch ohne Recover keine Änderung bewirken wird. Wenn überhaupt müsste man den Wert also auf 1 setzen und dürfte kein Recovery-Tool verwenden. Leider weiß man dadurch aber sowieso nicht mehr, welches Partitionsset zuvor überhaupt aktiv war.

Hinzu kommt, dass bei Modellen mit UBIFS und erfolgreich durchgeführten Recovery-Vorgang anschließend im anderen Partitionsset keine funktionierende Firmware mehr vorh. ist (Filesystem, Kernel wäre noch vorh. aber das reicht eben nicht).

 

[AugeK]

Wenn ich jetzt mal so ins Blaue spekuliere dann ist mtd1 im RAM nachchdem der Ladebalken bei 50% ist, also der Teil der schnell geht.
Ab 50% geht das deutlich langsamer, vermutlich der Teil wo mtd1 ins NAND kopiert wird, und bei ca 80% erfolgt ein Kaltstart der 1260.
Dementsprechend würde das Schreiben ins NAND nicht durchlaufen.
Könnte ein Hinweis auf einen Defekt des NAND sein. Ich vermute, dass alle Teile der Firmware in exakt einem Baustein sitzen und bei einem Tausch auch der ftp der 1260 nicht mehr erreichbar wäre?

 

[NDiIPP]

[…] vermutlich der Teil wo mtd1 ins NAND kopiert wird,

Nein. Wie ich schon mehrmals schrieb, dieser Vorgang wird und kann nicht vom Recovery-Tool überwacht werden. Dieser Schreib-Vorgang in den NAND-Flash findet statt, wenn das Recovery-Tool bereits behauptet fertig zu sein.

[…] und bei einem Tausch auch der ftp der 1260 nicht mehr erreichbar wäre?

Ja.

 

[AugeK]

Ok, das heißt dann wohl dass das Recovery Tool nach ca 50% Probleme hat mtd1 in den RAM zu kopieren?
Wird der beim Booten überprüft oder ist der im log eingetragenen Wert statisch?
Würde mich mal interessieren wodurch der Reboot ausgelöst wird. Läuft da ein fester, vordefinierter Timer?

 

[NDiIPP]

Ok, das heißt dann wohl dass das Recovery Tool nach ca 50% Probleme hat mtd1 in den RAM zu kopieren?

Demgegenüber steht der erfolgreiche Abschluss dieses Vorganges laut ftp.log aus #20.

Wird der beim Booten überprüft oder ist der im log eingetragenen Wert statisch?

Was genau meinst du? RAM? NAND-Flash?

Würde mich mal interessieren wodurch der Reboot ausgelöst wird. Läuft da ein fester, vordefinierter Timer?

Normalerweise wird der Reboot beim Recovery eines NAND-Flash Modell von der aus dem RAM gestarteten Firmware ausgelöst, nachdem diese die Firmware vom RAM in den NAND-Flash geschrieben hat.

 

[AugeK]

Nach dem Reboot läuft der Ladebalken weiter, das Recovery glaubt offensichtlich dass das Laden weiter geht.
Ob das aber wirklich so ist?

 

[NDiIPP]

Hier mal das Ende einer ftp.log eines erfolgreichen Recovery-Vorgang einer 7412 (ebenfalls ein NAND-Flash only Modell wo auch TFFS und Bootloader im NAND-Flash liegt):

[...]
0:11:510: ---> write image (mtdnand) <---
0:11:622: open ftp 192.168.178.1 port 21
0:11:829: open ftp data 192.168.178.1 port 3084
0:11:844: clear flash-partition (mtdnand)
0:12:382: flash clear (mtdnand) ok : now send image
0:12:490: update flash-partition (mtdnand)
0:12:505: send image (size=2012) for mtd8
0:13:257: flash write (mtd8) ok
0:13:383: successfully update of mtd8
0:13:446: nand: load filesystem and kernel image to RAM (size: 20368384)
0:13:446: ---> read environment <---
0:13:546: open ftp 192.168.178.1 port 21
0:13:958: recv: 220 ADAM2 FTP Server ready
0:13:989: send: USER adam2
0:13:989: recv: 331 Password required for adam2
0:14:005: send: PASS adam2
0:14:005: recv: 230 User adam2 successfully logged in
0:14:037: send: SYST
0:14:037: recv: 215 AVM EVA Version 1.2834 0x0 0x47409
0:14:053: send: TYPE I
0:14:053: recv: 200 Type set to BINARY
0:14:068: send: MEDIA SDRAM
0:14:068: recv: 200 Media set to MEDIA_SDRAM
0:14:068: send: P@SW
0:14:068: recv: 227 Entering Passive Mode (192,168,178,1,12,15)
0:14:068: open ftp data 192.168.178.1 port 3087
0:14:116: send: RETR env
0:14:116: recv: 150 Opening BINARY data connection
0:14:178: recv: 226 Transfer complete
0:14:306: environment successfully readed(1469 bytes)
0:14:337: send: BYE
0:14:337: recv: 221 Thank you for using the FTP service on ADAM2
0:14:337: ramload: savekernel activ for NAND
0:14:343: ---> write image mtd1 mtd1-base/size(440000/400000) ram-base/size(80000000/8000000) SquashFS(263c00) <---
0:14:445: open ftp 192.168.178.1 port 21
0:14:680: open ftp data 192.168.178.1 port 3076
0:14:696: RAM-Load Image to 86c8c400 Filesystem: 86ef0000
0:14:728: now send image mtd1 to ram
0:14:743: send image (size=20368384) for mtd1
0:47:509: load to ram (mtd1) ok
0:48:754: ----EOF---

Interessant ist dabei die Diskrepanz bei der vergangenen Zeit zwischen den letzten beiden Zeilen im Vergleich zum Log aus #20.

Edit:
Auf irgendetwas wartet da also das Recvery-Tool vielleicht noch. Aber das eigentliche Hochladen des Images in den RAM sollte da bereits abgeschlossen sein. Vielleicht erfolgt kein Start dieses Images aus dem RAM…

 

[AugeK]

Habe Die 7.56 und 7.57 versucht, bei Beiden läuft es nicht.
Mache mal ein Video davon.

Da ist es:

153.6 MB file on MEGA

mega.nz

Am Netzwerk Symbol des Laptops ist deutlich zu sehen dass die Netzwerkverbindung mehrfach unterbrochen wird.

 

[NDiIPP]

Vielleicht warten aktuelle Recovery-Tools von AVM ja tatsächlich darauf, die Box nach dem (zu erwartenden) Neustart eines solchen Recovery erneut zu kontaktieren (ggf. auch erst nach dem 2. Neustart), um den Erfolg des Flash- bzw. Recovery-Vorgang zu verifizieren (könnte man bspw. damit überprüfen ob bei der Variable "firmware_info" nur noch die Version der jeweiligen Recover-Firmware steht ohne recoverd=n).

Könnte ich mir jedenfalls vorstellen, da vermutlich viele Anwender die Box evtl. vorzeitig von der Stromversorgung trennten bevor die Box mit dem Recovery-Vorgang tatsächlich fertig war (die Recovery-Tools behaupte(te)n ja schon fertig zu sein, bevor der eigentliche Flash-Vorgang angefangen hat, man soll ja "nur" den Neustart des Gerätes abwarten).

 

[AugeK]

Das mit recovered=2 hatte ich bisher nicht, das ist neu.

Selbst wenn ich die Kiste 1 Stunde in Ruhe lasse läuft sie nicht.

Video vom Neustart, kannst du dir gern als Dauerschleife vorstellen:

102.61 MB file on MEGA

mega.nz