FRITZ!Box 6490 "kdg" unbranden

Egal, ob ich das script "blank" aufrufe oder mit "-o 5 29" oder noch mit /tmp/prov...tar oder noch mit > /tmp/mtd.img
Hast Du es denn auch mal mit der Angabe einer Support-Datei als erstem Parameter versucht?

Wenn ja, einfach den konkreten Aufruf (oder auch mehrere) in einem CODE-Block zeigen ... weniger Prosa ist da weitaus hilfreicher - aus dem zitierten Teil kann man sich jetzt vier verschiedene Aufrufe selbst zusammensuchen?

Wenn nein, hätte ja das Lesen der angezeigten Daten helfen können.

Ob ja oder nein, geht aus Deinem Text leider gar nicht hervor.
 
Zuletzt bearbeitet:
Sry ... unklar formuliert ...
ich habe es auf einem älteren Netbook unter Ubuntu 14.04 mit folgenden Kombiantionen versucht:
Code:
./tffs_add_file supportdata.txt
Code:
./tffs_add_file supportdata.txt -o 5 29
Code:
./tffs_add_file supportdata.txt -o 5 29 /tmp/prov...tar
In allen Fällen erhielt ich nur den "usage"-screen

Allerdings habe ich das ganze nun noch einmal unter Ubuntu 16.04 auf einem halbwegs aktuellen i3-Notebook testen können.
Und da wurde mir mit dem "standard"-Kommando
Code:
./tffs_add_file supportdata.txt -o 5 29 /tmp/prov...tar > /tmp/mtd.img
dann tatsächlich nach einiger Zeit eine mtd.img erzeugt.
Selbige habe ich dann auch über die eva-tools flashen können:
Code:
./eva_store_tffs mtd3 /tmp/mtd.img

Allerdings ist nach dem Reset der Box von "DVB-C" noch immer nichts zu sehen ;(

Also weiter suchen, wo mein Fehler liegt ...
 
Zuletzt bearbeitet:
@Bursche:
Suche Dir am besten die erste Beschreibung meinerseits, warum das mit dieser "0x10" überhaupt funktioniert (war irgendwann in der ersten Hälfte 2015, iirc) und vergleiche das (insb. die featovl.cfg-Inhalte, die dabei entstehen müssen) mit Deinem Vorgehen und mit dem Inhalt Deiner Box. Überprüfe, ob die Trigger, die überhaupt erst zur Verarbeitung der avmfeature.conf führen, durchlaufen wurden und Du weißt, ob die Box vor oder nach dem Trigger-Event ist.

Da die avmfeature.conf ja bei ihrer Auswertung gelöscht wird (das hast Du ja sicherlich gelesen, ich habe es mehrfach erwähnt in verschiedenen Beiträgen zur avmfeature.conf), wäre vielleicht eine daneben liegende "Marker-Datei" keine so schlechte Idee, mit der man auch bei gelöschter avmfeature.conf nachträglich noch sehen kann, daß die provideradditive.tar auch entpackt wurde.

Wobei die passende "featovl.cfg" tatsächlich von der Box selbst erzeugt werden sollte - aber in Verbindung mit einem weiteren Neustart ... und da von dem wieder mal nichts in Deiner "Beschreibung" zu sehen ist (es könnte auch noch am "Ergebnis" des Flashens liegen, nicht umsonst erzeugt das eine Protokoll-Datei, die man prüfen könnte, wie Dir der Blick ins Skript sicherlich zeigte), bin ich mir auch nicht so richtig sicher, was Du nun falsch gemacht haben könntest.

Auf die eigene "Dokumentation" des Inhalts Deiner "provideradditive.tar" hast Du ja auch verzichtet ... ich bin mir nicht so ganz sicher, ob das Erzeugen des Images bei Verwendung eines Dateinamens "prov...tar" überhaupt fehlerfrei erfolgt ist. Aber auch für die Kontrolle des Images gibt es irgendwo eine "Anleitung" - vielleicht probierst Du die einmal.

Egal, wie immer gilt: Nicht einfach stur irgendwelche "Anleitungen" abarbeiten (die verschiedenen Aufrufversuche von tffs_add_file überzeugen mich noch nicht wirklich davon, daß Du gelesen und verstanden hast, sorry - die Erklärung mit dem anderen System überzeugt mich als allerletztes) und sich wundern und nachfragen, wenn etwas nicht das erwartete Ergebnis bringt, sondern erst dann überhaupt darüber nachdenken zu handeln, wenn man es verstanden hat, was da passiert. Ansonsten geht es Dir am Ende noch so, daß schon das Lesen von E-Mails mit "rm / -rf" (steht für "read mail / -really fast") auf Deinem Linux-System unerwartete Ergebnisse erbringt.

Und wenn Du tatsächlich erwartest, daß ein anderer Deinen Handlungen folgen kann und Dir ggf. einen Hinweis auf gemachte Fehler gibt, dann braucht der in aller Regel ein "Protokoll" Deines Handelns. Wenn Du das immer wieder nur in Prosa beschreibst: "Allerdings ist nach dem Reset der Box von "DVB-C" noch immer nichts zu sehen ;(" (was das ja ganz offensichtlich nur "vom Ergebnis her" betrachtet und außer "jeht nich" so vollkommen ohne jede weitere Information daherkommt), dann wird irgendwann die Geduld der Helfer auch erschöpft sein ... das Ergebnis wäre vermutlich "Stille" auf weitere Nachfragen Deinerseits. Hat man erst den Stempel des "Dummkopfs" erhalten, ist es bis zu "Ist ohnehin Zeitverschwendung, dem zu antworten ..." nicht mehr so ganz weit. Vielleicht liest Du auch mal (abseits des eigentlichen Themas) hier nach, was da über "schlampige Denker" steht, woran man sie erkennen kann und wie Du es besser machen könntest.

Wie wenig klar Du Dich tatsächlich ausdrückst, wird Dir vielleicht bewußt, wenn Du Dir Deinen "cliffhanger" noch einmal durchliest ... vielleicht siehst Du ja einen Unterschied, wenn Du die folgenden Interpretationen betrachtest:

"Also werde ich weiter suchen, wo mein Fehler liegst ..."

oder

"Also weiter suchen, wo mein Fehler liegt ... fangt an, ich höre."

Beides ist Dein eigener Text, nur etwas weiter ausformuliert und doch ein vollkommen anderer Sinn dahinter.

Wir können hier nur das lesen, was Du wirklich schreibst und nicht das, was Du Dir dabei gedacht haben magst. Da sind Mißverständnisse geradezu vorprogrammiert und etwas mehr "Eifer" (und gründlicheres Nachdenken) kann das von vorneherein verhindern.
 
Erneut bitte ich um Verzeihung, wenn ich nicht so ausführlich schreibe, wie Peter es erwartet.
Ich habe auch nicht auf weitere Antworten gewartet sondern weiter recherchiert in diesem Thema.

Da die avmfeature.conf ja bei ihrer Auswertung gelöscht wird (das hast Du ja sicherlich gelesen, ich habe es mehrfach erwähnt in verschiedenen Beiträgen zur avmfeature.conf), wäre vielleicht eine daneben liegende "Marker-Datei" keine so schlechte Idee, mit der man auch bei gelöschter avmfeature.conf nachträglich noch sehen kann, daß die provideradditive.tar auch entpackt wurde.
Die Idee mit dem "Marker" nehme ich glatt schon mal auf ;)

Suche Dir am besten die erste Beschreibung meinerseits, warum das mit dieser "0x10" überhaupt funktioniert (war irgendwann in der ersten Hälfte 2015, iirc) und vergleiche das (insb. die featovl.cfg-Inhalte, die dabei entstehen müssen) mit Deinem Vorgehen und mit dem Inhalt Deiner Box. Überprüfe, ob die Trigger, die überhaupt erst zur Verarbeitung der avmfeature.conf führen, durchlaufen wurden und Du weißt, ob die Box vor oder nach dem Trigger-Event ist.
Mit der Thematik werde ich mich als nächstes auseinandersetzen.

ein "Protokoll" Deines Handelns
Tja, ich hoffte, es war deutlich genug formuliert, dass ich eine prov...tar erzeugt habe (ja, den Weg dahin und deren Inhalt habe ich hier nicht gesondert dargestellt ...) und anschließend mittels tffs_add_file eine mtd.img erzeugen konnte, die ich dann via eva "geflashed" habe.

Letztlich habe ich jedenfalls die mtd.img nochmals erzeugt und via eva_store_tffs in mtd3 geschrieben.
Dann die Box nicht per reset neu gestartet sondern erneut via FTP eingeloggt und mittels "quote REBOOT" und "quit" den Reboot angestoßen und den FTP beendet.
Danach ist die Box neu gestartet und hing - meiner bescheidenen Meinung nach - in einem BootLoop fest.
Nachdem die Box dann zum vierten Mal einen autom. Neustart durchführte habe ich den Stromstecker gezogen.
Nach dem Nächsten Bootvorgang war dann selsamer Weise wieder alles OK.
Ich kam wieder in die WebGUI und - wider meiner Erwartung - war auch der Eintrag DVB-C zu sehen.

Obwohl ich eigentlich schon glücklich darüber bin, dass es geklappt hat - danke an dieser Stelle an alle, die hier Ihre Erfahrungen teilen - werde ich das ganze noch einige Male durchexerzieren und hoffentlich auch im Bereich der Fehlersuche etwas dazu lernen.
Mit ist nämlich schleierhaft, was diesen BootLoop ausgelöst hat und vor allem, warum er nach dem "HardReset" weg war.
 
Erneut bitte ich um Verzeihung, wenn ich nicht so ausführlich schreibe, wie Peter es erwartet.
Es ist gar nicht notwendig, sich zu entschuldigen und es geht auch gar nicht um eine Erwartungshaltung meinerseits. Man kann eben nur helfen, wenn man die Fakten auch wirklich kennt und wieviele Lücken und damit Spielraum für Fehler Deinerseits und (falsche) Interpretationen eines Lesers auf der anderen Seite verblieben sind, wollte ich Dir aufzeigen.

Immerhin hat es ja dann zumindest doch noch funktioniert (damit ist es als "proof of concept" bestätigt) und wenn Du jetzt nach dem optimalen Weg suchen willst und daraus am Ende gar eine Beschreibung von Deiner Seite entstehen sollte (s. #19, letzter Satz), dann gilt diese "Forderung" meinerseits nach mehr Präzision erst recht.

Auch bei Deinem "Bootloop" fehlt ja irgendwie wieder die Information, wie lang so ein einzelner Schleifendurchlauf denn war (sieht man an den LEDs, wenn man's nicht selbst einschätzen kann, hilft die Stoppuhr und die (ausführliche) Beschreibung des LED-Zustand in Relation zur Zeit anderen, etwas zu erkennen) - es ist ein riesiger Unterschied, ob die Box synchronisiert hat am Kabel oder nicht. Daß mindestens ein Neustart vollkommen normal und "erwartbar" ist, wenn man nicht parallel zur "provideradditive.tar" noch eine passende "featovl.cfg" ins Image packt (damit kann man den Neustart nach Änderung der "featovl.cfg" durch das FRITZ!OS ja umgehen), steht ja auch irgendwo.

Viel Erfolg ... ich bin auf Deine Anleitung für andere gespannt (und das meine ich tatsächlich ernst - ist halt eine "community" hier und da kann jeder etwas beitragen).
 
Hast du den eine Anleitung schon fertig?
 
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.