Fritzbox 6490 Cable Bootloop

[stoney]

Ist es eine CM Box oder IP-Client?

Hast Du mal versucht die Box nur mit Strom zu versorgen und sonst alle anderen Kabel abgezogen?

Hast Du mal versucht auf linux_fs_start 0 + firmware_version kdg zu booten?

 

[ice012345]

Ist es eine CM Box oder IP-Client?

Ganz normal als Kabel-Modem(CM Box), 6490 kann garnicht IP-Client aber ich weiß was du meinst(LAN1)

Hast Du mal versucht die Box nur mit Strom zu versorgen und sonst alle anderen Kabel abgezogen?

Ja ist das gleiche

Hast Du mal versucht auf linux_fs_start 0 + firmware_version kdg zu booten?

Ja habe ich.
Ich habe schon in beide Partionen linux_fs_start 0|1 beschrieben, bei beiden ist der 141.06.85 AVM drauf.
Ich kann umstellen welche partion ich will sie startet immer bis zu der selbe stelle hoch danach Neustart.

 

[ice012345]

@PeterPawn hättest du vielleicht eine idee, woran es liegt das es nach knapp eine minute (nach dem start der Box) Neugestartet wird? Trotz neu aufspielen von TFFS-image?

 

[PeterPawn]

Man liest so viele dieser Beschreibungen, deshalb habe ich die Fakten auch nicht alle präsent bzw. ich könnte die auch mit einer anderen Frage verwechseln - soviel vorweg.

Wenn hier irgendwo eine "provideradditive.tar" dem TFFS-Image hinzugefügt wurde, wäre mein erster Ansatz, diese wegzulassen - zumal die zu installierende Firmware ja ohnehin damit nichts mehr anstellen mag bzw. nur einzelne Files entpackt.

Ansonsten klingt so eine Beschreibung (Box startet ein Stück, bleibt dann aber hängen und bootet neu) für mich am ehesten nach einem Problem mit der Synchronisation zwischen den Systemen ... das könnte z.B. dann passieren, wenn eines der Systeme nicht den richtigen Kernel oder das richtige Dateisystem findet und hängenbleibt, was dann das andere System zum Reboot veranlaßt.

Klingt erst einmal so, als wäre das extrem unwahrscheinlich ... vor allem, weil die Box ja zuvor mit der 06.85 schon gestartet ist und erst beim Update auf 06.87 dann erste Probleme machte. Aber wenn man sich verdeutlicht, was beim Update-Vorgang passiert (das ist ja dann das, was in dieser kurzen Zeit der Abwesenheit ausgeführt werden sollte), dann kann das fast nur noch ein Problem mit der Partitionierung des eMMC-Devices sein (die würde der Bootloader aber m.W. auch aus dem Backup im SPI wiederherstellen) oder es trat ein Problem beim Schreiben der Firmware-Files auf.

Insofern würde ich das alles noch einmal von vorne beginnen und neben der Firmware für die aktiven Partitionen auch noch ein frisches TFFS-Image (nur mit dem Environment) in die beiden TFFS-Partitionen schreiben lassen. Man muß natürlich aufpassen, daß man dann auch wirklich die Partitionen (als aktiv) beschreibt, die im TFFS-Image auch so gekennzeichnet sind ... wer ein TFFS-Image mit "linux_fs_start=0" flasht und sein System in die Partitionen für die "1" schreibt, wird beim Startversuch halt auch auf Granit beißen. Also am besten zuerst das TFFS-Image schreiben lassen (hier dann auch mal in beide Partitionen, weil der Inhalt der zweiten ja "unklar" ist) und danach die Box noch einmal bis zum Bootloader neu starten lassen ... dann sollten die ersten MTD-Parttitionen auch zur aktuellen Einstellung von "linux_fs_start" passen.

Mehr fiele mir hier auch nicht ein ... eigentlich können die Einstellungen in einem "frischen" TFFS-Image nicht falsch sein und damit auch keinen Neustart zur Folge haben und auch wenn ich nicht weiß, wie da verschiedenen Firmware-Versionen oder falsche Dateien in eine Partition gelangt sein sollen, ist das für mich immer noch die plausibelste Erklärung. Wenn wirklich alle Stränge reißen und man eine defekte Hardware-Komponente annehmen will oder muß (z.B. WLAN), dann kann man immer noch darüber nachdenken, dem TFFS-Image ein paar weitere Default-Einstellungen mitzugeben, bei denen möglichst viele Komponenten erst einmal deaktiviert sind. Darüber würde ich aber erst dann nachdenken, wenn ich mir 100% sicher wäre, daß tatsächlich die Hardware schuld ist.

 

[ice012345]

Wenn hier irgendwo eine "provideradditive.tar" dem TFFS-Image hinzugefügt wurde, wäre mein erster Ansatz, diese wegzulassen - zumal die zu installierende Firmware ja ohnehin damit nichts mehr anstellen mag bzw. nur einzelne Files entpackt.

O.K ohne Provideradditive neue TFFS-image. Kann ich das mit der Script von dir "tffs_add_file"? Wenn ja warscheinlich ohne node 29 oder weil mit node 29 kommt fehler?

freetz@DESKTOP-XXX:/mnt/c/Users/XXX/YourFritz/tffs$ ./tffs_add_file /mnt/c/test/support.txt -o 5 29 > /mnt/c/test/mtd.img
Missing file name for node number '29'.

(das ist ja dann das, was in dieser kurzen Zeit der Abwesenheit ausgeführt werden sollte),

Ich musste plötzlich ganz dringend

Insofern würde ich das alles noch einmal von vorne beginnen und neben der Firmware für die aktiven Partitionen auch noch ein frisches TFFS-Image (nur mit dem Environment) in die beiden TFFS-Partitionen schreiben lassen

Also mit "tffs_add_file" Script ohne die provideraddtive richtig? in mtd3 und mtd4?

Man muß natürlich aufpassen, daß man dann auch wirklich die Partitionen (als aktiv) beschreibt, die im TFFS-Image auch so gekennzeichnet sind ... wer ein TFFS-Image mit "linux_fs_start=0" flasht und sein System in die Partitionen für die "1" schreibt, wird beim Startversuch halt auch auf Granit beißen

Wie kann ich mit der Script "tffs_add_file" bei erzeugen der TFFS-image die Partition wählen linux_fs_start 0|1 oder erzeugt diese Automatisch für die Partition linux_fs_start 0?

 

[PeterPawn]

Ich würde ja einfach die "29" am Ende weglassen beim Aufruf von "tffs_add_file" ... wobei hier ohnehin der Weg über das Aufsplitten in die einzelnen Dateien mit anschließendem "build_tffs_image" der schlauere wäre, denn "tffs_add_file" löscht ja die anderen, alten Einstellungen genau nicht - insofern ist dessen Verwendung hier (erst recht bei dem Fehlerbild) sogar vollkommener Unfug und könnte auch schon eine Erklärung liefern, warum da irgendwelche Schleifen "gefahren" werden.

Dann sieht man auch gleich, welcher Wert von "linux_fs_start" nun im TFFS-Image gesetzt wird (steht ja in der Eingabe-Datei mit dem Environment) und die letzte Frage beantwortet sich damit auch von selbst ... obwohl man das bekanntlich bei der 6490 gar nicht wirklich wissen muß, denn die Zuordnung der MTD-Nummern im Bootloader ist ja überhaupt nicht vom Wert von "linux_fs_start" abhängig ... nur das Mapping auf die entsprechenden eMMC-Partitionen wird davon beeinflußt.

 

[ice012345]

ch würde ja einfach die "29" am Ende weglassen beim Aufruf von "tffs_add_file" ... wobei hier ohnehin der Weg über das Aufsplitten in die einzelnen Dateien mit anschließendem "build_tffs_image" der schlauere wäre

O.K. mit der "build_tffs_image"
mit env.txt , count.txt und nametable? oder nur env.txt?

Wenn mit count.txt, war da nicht irgendwas mit die "u" zu "o" ändern?

 

[PeterPawn]

Sorry ... Du wolltest einen Tipp und keine Fragestunde veranstalten, wenn Du die Info problemlos auch selbst ermitteln kannst - ich habe auch nicht jedes einzelne Skript im Kopf, was ich jemals geschrieben habe und muß in aller Regel genauso erst nachsehen, wenn ich solche Fragen beantworten wollte.

Das mit dem "u" zeigt schon ein Blick in die Skript-Datei (Zeile 70 in "counter_to_tffs", gibt sogar eine extra Kommentarzeile dafür) und auch die erste Frage beantwortet der Blick in die Datei "build_tffs_image" unmittelbar, denn da steht das sogar im Header.

 

[ice012345]

Sorry ... Du wolltest einen Tipp und keine Fragestunde veranstalten

Hast recht Sorry, Danke.

Das mit dem "u" zeigt schon ein Blick in die Skript-Datei (Zeile 70 in "counter_to_tffs", gibt sogar eine extra Kommentarzeile dafür)

habe ich gefunden.

auch die erste Frage beantwortet der Blick in die Datei "build_tffs_image" unmittelbar, denn da steht das sogar im Header.

Das ist mir schon klar.

Die frage kam weil du

TFFS-Image (nur mit dem Environment)

geschrieben hattest.

 

[PeterPawn]

Das "nur mit dem Environment" meinte eher "ohne provideradditive.tar und andere alte Einstellungen" ... wobei das ja wieder die Stelle wäre, wo ich dann später ansetzen würde, wenn man tatsächlich das Ansprechen einzelner (defekter) Hardware-Komponenten verhindern wollte. Dann müßte man natürlich entsprechende zusätzliche Dateien (z.B. eine "wlan.cfg" mit abgeschalteten WLAN-Modulen, denn die wären im Normalfall an) auch noch in die TFFS-Images einbinden lassen ... aber soweit waren wir ja noch gar nicht wirklich.

 

[stoney]

Ich habe schon in beide Partionen linux_fs_start 0|1 beschrieben, bei beiden ist der 141.06.85 AVM drauf.

Was genau hast Du da wo hin geschrieben?

 

[ice012345]

@stoney
Ich habe mal mit der Partition linux_fs_start 1 gestartet und per EVA-FTP filesystem.image und kernel.image zu jeweiligen Partitionen geflasht und auch mit Partition linux_fs_start 0

@PeterPawn
Leider immer noch keine erfolg. Neue TFFS-image gebaut mit der Script "build_tffs_image" ohne Provideradditive.
(./tffs_from_supportdata /<pfad_zur>/support\ FRITZ.Box\ 6490\ Cable\ 141.xxxxxx.txt /tmp/tffs_dump/ 1) für linux_fs_start 0 gewählt.
Box mit linux_fs_start 0 gestartet und per "eva_store_tffs" TFFS-image auf mtd3 und mtd4 geschrieben. Box neustarten lassen bis Bootloader geladen wurde. Box neu gestartet und per EVA quote MEDIA FLSH,bin,pas und put befehle filesystem und kernel in die aktiven Partitionen geschrieben, quote REBOOT
Das selbe ergebnis: Box startet Power dauer an ca. 5 sekunden dann blinkt sie, nach ca.10 mal blinken der Power LED kommt WLAN LED mit blinken dazu, ca.15 mal blinkt WLAN danach Neustart. Also immer wenn WLAN aktiviert werden soll.

 

[PeterPawn]

Die "1" beim "tffs_from_supportdata" hat absolut nichts damit zu tun, was in "linux_fs_start" steht und was nicht - die selektiert lediglich zwischen dem Dump von MTD3 oder MTD4 als Quelle für das (alte) TFFS-Image.

Entweder Du hast die Arbeitsschritte sehr komisch beschrieben oder am Ende doch noch etwas falsch gemacht ... nach dem "tffs_from_supportdata" braucht es das "Zerlegen" des Images mit "dissect_tffs_dump" und anschließend das Zusammensetzen aus den dabei entstandenen Dateien mit "build_tffs_image". Das nach "tffs_from_supportdata" ausgegebene Image enthält ja wieder die alten Daten, denn das ist nichts anderes als das (automatische) Auslesen eines TFFS-Images aus den erweiterten Support-Daten.

Dann steht auch (nochmal) in der Text-Datei mit dem Environment, welchen Wert "linux_fs_start" nun wirklich hat - der unterstellte Zusammenhang zum "Index" beim "tffs_from_supportdata" ist absolut falsch.

Es wäre vermutlich sinnvoller, wenn Du anstelle der Beschreibung in Prosa einfach das Console-Protokoll (in "CODE"-Tags) einfügen würdest - man sieht dann auch viel besser, ob das die richtige Reihenfolge der Abläufe ist oder nicht. Da Du dabei ohnehin noch einmal von vorne beginnen mußt, kannst Du auch problemlos noch das "tffs_from_supportdata" dort erneut ausführen. Wenn Du zwischendrin noch die "Zwischendateien" mit "cat" anzeigen läßt, sieht man auch gleich im Protokoll,. was nun wirklich in der "linux_fs_start"-Variablen steht - die "geheimen" Daten kannst Du ja wieder maskieren.

Wenn Du also nicht tatsächlich bereits den Weg über "dissect_tffs_dump" gegangen bist und das nur vergessen hast zu erwähnen, dann war das erneut der falsche Ansatz - ich weiß auch nicht so genau, wo das in dieser Form beschrieben sein könnte. Wenn der Neustart jedenfalls so lange nach dem Versuch der Aktivierung des WLAN erfolgt, ist das auch kein Hardware-Problem mit einem WLAN-Adapter, das würde viel früher zuschlagen und nicht erst nach dem 15. Blinken der WLAN-LED.

 

[f666]

Falls du es partout nicht hin bekommst, könntest du ein Kabel nacheinander an die seriellen Konsolen anlöten und nachsehen, was die beiden Kerne so treiben.

 

[ice012345]

Die "1" beim "tffs_from_supportdata" hat absolut nichts damit zu tun, was in "linux_fs_start" steht und was nicht - die selektiert lediglich zwischen dem Dump von MTD3 oder MTD4 als Quelle für das (alte) TFFS-Image.

Das habe ich tatsächlich falsch verstanden.

Entweder Du hast die Arbeitsschritte sehr komisch beschrieben oder am Ende doch noch etwas falsch gemacht ... nach dem "tffs_from_supportdata" braucht es das "Zerlegen" des Images mit "dissect_tffs_dump" und anschließend das Zusammensetzen aus den dabei entstandenen Dateien mit "build_tffs_image". Das nach "tffs_from_supportdata" ausgegebene Image enthält ja wieder die alten Daten, denn das ist nichts anderes als das (automatische) Auslesen eines TFFS-Images aus den erweiterten Support-Daten.

Ja klar, ich habe es nur sehr kurz erläutert. Natürlich habe ich nach dem "tffs_from_supportdata" mit "dissect_tffs_dump" zerlegt und anschließend mit "build_tffs_image" ohne provideradditive wieder zusammengesetzt.

Es wäre vermutlich sinnvoller, wenn Du anstelle der Beschreibung in Prosa einfach das Console-Protokoll (in "CODE"-Tags) einfügen würdest

kann ich machen, wird dann erst Wochenende werden.

 

[ice012345]

Kurz habe ich es nochmal probiert

freetz@DESKTOP-1:~$ cd /mnt/c/Users/1/fritzbox/
freetz@DESKTOP-1:/mnt/c/Users/1/fritzbox/$ cd tffs
freetz@DESKTOP-1:/mnt/c/Users/1/fritzbox/tffs$ mkdir /mnt/c/test
freetz@DESKTOP-1:/mnt/c/Users/1/fritzbox/tffs$ mkdir /mnt/c/test/tffs_dump
freetz@DESKTOP-1:/mnt/c/Users/1/fritzbox/tffs$ ./tffs_from_supportdata /mnt/c/test/support.txt /mnt/c/test/tffs_dump/ 1
freetz@DESKTOP-1:/mnt/c/Users/1/fritzbox/tffs$ ./dissect_tffs_dump < /mnt/c/test/tffs_dump/tffs_1.dump
/tmp/tmp_1518614504_44
freetz@DESKTOP-1:/mnt/c/Users/1/fritzbox/tffs$ mv /tmp/tmp_1518614504_44 /mnt/c/test/tffs_dump/tffs_1
freetz@DESKTOP-1:/mnt/c/Users/1/fritzbox/tffs$ ./build_tffs_image /mnt/c/test/nametable /mnt/c/test/env.txt /mnt/c/test/count.txt /mnt/c/test/tffs_dump/tffs_1/*.bin > /mnt/c/test/mtd.img
freetz@DESKTOP-1:/mnt/c/Users/1/fritzbox/tffs$

in der env.txt steht linux_fs_start 0

Danach habe ich mit „eva_store_tffs“ in mtd3 und mtd4 die mtd.img datei geschrieben, log datei von „eva_store_tffs“ hat mit transfer complete beendet.
Jetzt ein Neustart bis bootloader geladen hat(bis power led blinken anfängt) ist es soweit richtig?

Danach denke ich die filesystem und kernel, für ARM mtd0 und mtd1, für ATOM mtd6 und mtd7 richtig?

 

[PeterPawn]

Hier geht einiges durcheinander ... anders als ich es dachte in Erinnerung zu haben (und anders als es in den ersten Kommentarzeilen dort steht), kann das "dissect_tffs_dump" ja gar kein Environment aus dem TFFS-Dump erstellen und auch weder Counter-Datei noch Name-Table. Das müßte ich erst mal nachrüsten ... ist mir irgendwie nie aufgefallen, aber ich verwende auch andere Versionen dieser Skriptdateien und die veröffentlichte Version war eigens dafür gemacht (was man schon an den vorhandenen ausführlicheren Kommentaren ersehen kann), ist aber wohl nie so richtig fertig geworden, damit die der Beschreibung in den ersten Zeilen gerecht werden kann.

Wo kommen bei Dir denn dann die Dateien in "/mnt/c/test" her, die Du zum Erzeugen des Images mit "build_tffs_image" verwendest? Die mußt Du ja dann irgendwoanders gefunden haben oder hast Du die selbst von Hand aus dem Dump gepuhlt? Ich finde jedenfalls im Repo selbst gar kein Skript, was aus einem TFFS-Dump die Environment-Datei oder die Counter erstellen würde - das gibt es auch nicht abseits von "dissect_tffs_dump" (und es gehört "thematisch" ohnehin dort hinein).

Abgesehen davon ist natürlich hier Deine Angabe des vierten Parameters (bzw. auch aller anderen, die durch Globbing daraus entstehen) beim "build_tffs_image" wieder komplett falsch ... damit werden ja dann wieder die alten Einstellungen, die zuvor aus den Support-Daten (bzw. dem dort enthaltenen TFFS-Image) extrahiert wurden, in das neuen Image mit eingebunden. Wozu sollte das gut sein? Du willst doch diese Einstellungen gerade löschen ... das war es ja, was ich mit "nur das Environment" ausdrücken wollte weiter oben.

 

[ice012345]

Wo kommen bei Dir denn dann die Dateien in "/mnt/c/test" her, die Du zum Erzeugen des Images mit "build_tffs_image" verwendest? Die mußt Du ja dann irgendwoanders gefunden haben oder hast Du die selbst von Hand aus dem Dump gepuhlt?

Die env.txt habe ich aus der Box gelesen und die drinne enthaltene dateien mit meine saubere erweiterte supportdaten wo ich erstellt hatte(wo die Box noch funktionierte) vergliechen. nametable und count.txt denke ich mal ist immer gleich oder nicht?

Abgesehen davon ist natürlich hier Deine Angabe des vierten Parameters (bzw. auch aller anderen, die durch Globbing daraus entstehen) beim "build_tffs_image" wieder komplett falsch ... damit werden ja dann wieder die alten Einstellungen, die zuvor aus den Support-Daten (bzw. dem dort enthaltenen TFFS-Image) extrahiert wurden, in das neuen Image mit eingebunden. Wozu sollte das gut sein? Du willst doch diese Einstellungen gerade löschen ... das war es ja, was ich mit "nur das Environment" ausdrücken wollte weiter oben.

O.K. Wenn ich denn vierten parameter (/mnt/c/test/tffs_dump/tffs_1/*.bin) nicht brauche wozu mache ich dann "tffs_from_supportdata" die vierte parameter sind doch diese daten wo ich durch "tffs_from_supportdate" gewinne????

 

[PeterPawn]

Ich wußte ja nicht, daß Du eine Environment-Datei, die Zähler (die sind ohnehin witzlos in diesem konkreten Fall und könnten auch handgemacht werden) und eine Name-Table bereits hattest und dachte außerdem (s.o.), daß "dissect_tffs_dump" diese Dateien ebenfalls aus dem Dump erstellen würde. Woher würdest Du diesen Dump denn nehmen, wenn nicht aus der Ausgabe von "tffs_from_supportdata"?

Solange Du also die drei tatsächlich für ein "frisches" TFFS-Image benötigten Dateien aus einer anderen Quelle hast (Dein Text in #56:

ja habe erweiterte supportdaten und habe mir TFFS Image daraus(env,count,nametable,provideradditeve) gebacken

hatte mich das nicht vermuten lassen und dazu kam noch mein Irrtum bei der Annahme, daß "dissect_tffs_dump" die Dateien tatsächlich gesondert extrahieren würde), solange brauchst Du selbstverständlich kein "dissect_tffs_image" vor dem "build_tffs_image" und damit auch kein "tffs_from_supportdata".

Es ist allerdings nicht ganz selbstverständlich, nach dem zu urteilen, was man von anderen hier ab und an mal liest ... also laß es mich noch einmal betonen: Die verwendeten Daten für das Environment müssen natürlich von der eigenen Box sein oder zumindest zur eigenen Box "passend gemacht" werden - es gibt (oder gab) hier auch falsche Anleitungen, die dafür auf irgendwelche Anhänge/Code-Blöcke aus fremden Beiträgen zurückgreifen wollten. Deine scheinen aber wirklich zu Deiner Box zu gehören ... also alles gut. Ich will nur nicht, daß der Nächste hier irgendwo liest, Deine Box würde wieder arbeiten und dann zu Deinem Environment greift für seine eigene Box. Irgendwo in einem früheren Beitrag hier ist es ja dann doch zu sehen - ich hatte oben nur ausdrücklich betont, daß ich eigentlich nicht zurückblättern wollte zum Lesen und alles vor #64 nur aus dem Gedächtnis bzw. dem "Gefühl" bezog, weil ich mir auch nicht bei jedem Beitrag ansehe, von wem der nun ist und ob das alles derselbe Fragesteller war.

Wenn's mich packt, ergänze ich vielleicht nachher auch noch das Extrahieren von "env" und "count" (und auch der Name-Table) im "dissect_tffs_dump" - lange genug hätte es ja dann gebraucht.

 

[stoney]

Wenn's mich packt, ergänze ich vielleicht nachher auch noch das Extrahieren von "env" und "count" (und auch der Name-Table) im "dissect_tffs_dump" - lange genug hätte es ja dann gebraucht.

Gerne kannst Du auch alle anderen tollen Scripts von dir ausführlich erklären