Scheint wohl doch der TFFS zu sein!?
Oder doch die Mondphase?
Dann ist's in 14 Tagen vielleicht auch wieder anders?
Wie wäre es denn damit, daß man einfach versucht, die
logischen Erklärungen zuerst näher zu untersuchen?
Nun habe ich ja selbst nicht mit den Gerätschaften hantiert ... aber mir fällt aus dem Stand auf, daß bei einer "Fehlerbeschreibung":
Die Box läuft mit dem Freetz Image nur nach dem diese mit EVA-FTP-Client geflasht wurde und durch das Tool gebootet wurde.
Nach einem Neustart startet die Box nicht mehr.
(auch wenn ich schon durchaus plausiblere und informativere Beschreibungen gelesen habe) ja wohl durchaus ein unterschiedliches "Handling" unterstellt werden kann.
Denn zum Flashen dürfte die Box zuvor jeweils stromlos gemacht worden sein ... jedenfalls kennt man das so von den Bootloadern für die GRX-Boxen, daß dieses notwendig ist. Beim ersten Start des Systems aus dem RAM erfolgt die Abarbeitung der Init-Skripte auch nur bis zur E03-flash_update, danach startet die Box erneut.
Beim zweiten Start führt sie dann das Initialisieren all der Komponenten aus, für die das nicht "herausgepatcht" wurde - und offensichtlich wird dabei dann irgendetwas nicht aufgerufen, was mit der originalen Firmware initialisiert würde.
Wenn da jetzt anstelle von "Neustart" irgendetwas "Nützliches" stehen würde (eine kleinere Auswahl der möglichen Gründe, hatte ich hier mal aufgeführt:
https://www.ip-phone-forum.de/threads/Änderung-im-bootloader-der-grx5-boxen.296445/), könnte man an die Stelle der "erfahrungsgestützten Spekulation" ob des Vorgehens bei einem solchen Neustart, auch das Wissen setzen, welches mit einer - nur ein klein wenig ausführlicheren - Beschreibung des Vorgehens verbunden sein könnte (zumindest in der idealen Welt, in der Fragesteller ihr Problem so schildern, daß die Hilfewilligen damit auch etwas anfangen können).
Wenn das aber tatsächlich "nur" ein "Software-Reboot" wäre, wie man zumindest spekulieren darf, dann liegt es doch deutlich näher anzunehmen, daß die fragliche Komponente (oder sogar eine andere) dabei nicht ordnungsgemäß zurückgesetzt würde und daher beim zweiten Versuch der Initialisierung dann doch wieder ein Problem auftritt?
--------------------------------------------------------------------------------------------------------------------------------
Warum muß ich das jetzt so ätzend festhalten (außer, damit es sich eher "einprägt")?
Weil es absolut nicht den geringsten Sinn ergibt (zumindest in meinen Augen), wie hier vorgegangen wird ... das ist für mich "unsystematisches Probieren" und daraus resultierende reine Spekulation, was hier wohl die Ursache des Problems sein könnte. Dabei kommen dann auch Vermutungen heraus, wie diese:
Scheint wohl doch der TFFS zu sein!?
Was ist denn bitte "ein TFFS"?
Es gibt ein "Tiny Flash File System" ... das ist ein spezielles Datenformat für einen Flash-Speicher, welches von AVM benutzt wird (schon seit Jahren und es wurde wohl auch von AVM entwickelt), um die Einstellungen der FRITZ!Boxen zu speichern. Wieso ist das also "maskulin" (die Frage hat mehr mit Grammatik als mit "Gendern" zu tun) und was soll denn bitte schön der konkrete Fehler sein, den "der TFFS" hier hat? Das ist jedenfalls - wie bereits festgehalten, auch in diesem Thread - weder ein spezielles Bauteil, noch als "Dateisystem" (was wohl die deutsche Entsprechung eines "file system" wäre) einigermaßen plausibel ein "er".
Wie wäre es denn, wenn man an die Stelle dieses unsystematischen Probierens und Spekulierens bei der Interpretation der vermeintlichen Ergebnisse mal die Auswertung von Protokollen setzt? Wenn das System spätestens beim zweiten (Warm-)Start mit voller Initialisierung abstürzt, dann wird ja mindestens beim ersten Startversuch wohl auch der Zugriff auf die Protokolle (Crash- und Panic-Log, ggf. sogar die gesamte Support-Datei) möglich sein und da steht - wenn es nicht ganz, ganz außergewöhnliche Probleme gibt, die eine Speicherung aus Sicherheitsgründen verbieten, damit dadurch nicht noch mehr kaputtgemacht wird, als ohnehin schon an Schaden besteht - dann auch drin, warum die FRITZ!Box neu gestartet wurde.
Was sollte einen jetzt davon abhalten, einfach mal dort nachzuschauen, welche Aktion das System zum Reboot veranlaßt?
Mir fällt da absolut nichts ein ... und das ist nur der Punkt "Protokolle auswerten, anstatt einfach fröhlich drauflos zu prökeln". Schon ein versuchter Kaltstart beim Reboot (dann vielleicht mal ohne den Versuch der Installation eines neuen Systems) und vorallem dessen nachvollziehbare Beschreibung hier im Thread, würde sich in meinen Augen wohltuend von den anderen Aktionen abheben ... wenn es tatsächlich keinen Unterschied machen sollte, wäre sogar das wieder eine nützliche (wenn auch unerwartete) Information.
--------------------------------------------------------------------------------------------------------------------------------
Außerdem würde ich nicht allzuviel auf Erkenntnisse geben, die aus dem Start der Box mit einem Image mit allen "remove patches" resultieren ... zwar wurde in "freetz-ng" tatsächlich die Warnung entfernt, daß die "remove patches" seit dem "responsive design" praktisch nicht mehr gewartet wurden und es gibt auch ein paar wenige Anpassungen dieser Patches im Fork, aber diese Patches basieren insgesamt auf sehr, sehr alten Zusammenhängen in der Firmware, als bei AVM tatsächlich noch fast jedes Binary seine eigenen Funktionen enthielt.
Das Zusammenfassen gemeinsamer Funktionen in Bibliotheken in den letzten Versionen ist aber nachweisbar bei AVM-Firmware und ich wage mal die Behauptung, daß
@cuma die geänderten und ggf. auch die neuen Zusammenhänge zwischen den AVM-Komponenten gar nicht ausreichend geläufig sind, um mit diesem Wissen dann "remove patches" zu bauen, die tatsächlich auch in jedem Falle funktionieren.
Zumal diese Patches eben bei den aktuellen Modellen kaum noch eingesetzt werden (müssen), weil einfach genug Platz im Flash vorhanden ist und sie damit tatsächlich nur noch in solchen "Spezialfällen" wie hier, wo wohl irgendeine Hardware-Komponente einen Schaden hat, einen Sinn ergeben.
Damit fehlt aber für das Funktionieren der "remove patches" - schon in einer ansonsten tadellos funktionierenden Box - die empirische Basis ... wenn diese Patches nur sehr vereinzelt eingesetzt werden, sind auch die Kombinationen (mit/ohne AHA, mit/ohne DECT ... mit/ohne NAS, WLAN, Telefonie, etc) nur sehr vereinzelt in freier Wildbahn anzutreffen und daher würde ich mich schon bei einer voll funktionsfähigen FRITZ!Box nicht automatisch darauf verlassen, daß die Patches tatsächlich 100% so funktionieren, wie sie sollen und nicht am Ende sogar irgendeiner dieser Patches dafür verantwortlich ist (bei der Masse der angewandten Änderungen), wenn ein "Software-Reboot" gegen die Wand fährt.
Simples Beispiel wäre der "remove WLAN"-Patch (
http://trac.boxmatrix.info/freetz-ng/browser/freetz-ng/trunk/patches/scripts/360-remove_wlan.sh) ... der wurde auch erst vor 6 Tagen und zwar nach dieser Meldung im GitHub:
https://github.com/Freetz/freetz/issues/161 geändert in "freetz-ng" (
http://trac.boxmatrix.info/freetz-ng/changeset/15520/freetz-ng) - die Warnung war trotzdem schon vorher nicht mehr vorhanden.
Genauer: Alleine durch das Entfernen der Warnung am 13.02.2019 (
https://trac.boxmatrix.info/freetz-ng/changeset/15159/freetz-ng) bzw. durch das Beschränken der Warnung auf Labor-Versionen, ändert sich nicht ein Bit am tatsächlichen Inhalt der Patches und das Problem in dem "remove WLAN" existierte bis vor 6 Tagen weiterhin ... und zwar schon seit der ersten 06.5x-Version, was mittlerweile 3 bis 3,5 Jahre sind (EDIT: bzw. an dieser konkreten Stelle existierte das Problem sogar noch länger - ich habe es nur bis zur 06.30 (07/2015) zurückverfolgt, da war es auch schon vorhanden).
Nur hat es keiner bemerkt, keiner gemeldet oder keiner behoben ... einfach weil es mit neueren Boxen viel zu selten zum Einsatz kommt. Wer will schon das WLAN in seiner Box stilllegen, solange er keine Platzprobleme hat? Praktisch niemand - außer er hegt den Verdacht, es könnte genau dieses WLAN sein, was bei ihm die Probleme macht, weil dessen Hardware irgendwie defekt ist.
Was will ich damit sagen? Es ist zwar korrekt und sicherlich auch hilfreich, die entsprechenden Funktionen in der angepaßten Firmware stillzulegen, dazu reicht es aber bereits aus, wenn man einfach die Environment-Variablen (in der "rc.conf") entsprechend setzt ... man muß dafür nicht eine einzige Datei aus dem AVM-Image löschen lassen. Und dieses Setzen der Environment-Variablen kann man sogar über die "featovl.cfg" machen ... dann kann man sogar mit der originalen AVM-Firmware
systematisch testen, welche Komponente denn nun Späne macht. Man braucht dazu praktisch nur eine der Inhouse-Versionen von AVM - mit denen kann man dann per Shell nach Belieben den Inhalt der "featovl.cfg" (solange es sich um Variablen handelt, die mit "CONFIG_" beginnen) abändern.
Man kann (und sollte!) einfach aus dem Verhalten der Box mit einer Firmware, deren korrekte Funktion man nicht zuerst einmal mit einer definitiv funktionsfähigen Hardware getestet hat, nicht mit der notwendigen Präzision auf irgendeinen Fehler schließen ... das schließt zwar nicht aus, daß man früher oder später auch mal einen Treffer landet, aber der wäre dann rein zufällig und verleitet einen u.U. sogar wieder zu den vollkommen falschen Schlußfolgerungen. Wenn der Bär im Gebüsch hockt, trifft ihn die Schrotflinte mit einiger Wahrscheinlichkeit (sofern man tatsächlich das richtige Gebüsch kennt) - nur wird der über den Beschuß mit Schrotkugeln i.d.R. "not amused" sein und dann braucht man doch wieder anderes "Werkzeug", um sich den (nunmehr wütenden) Bären vom Hals zu halten.
--------------------------------------------------------------------------------------------------------------------------------
Also: Etwas mehr Systematik wäre sicherlich hilfreich ... sowohl bei der Auswahl der Werkzeuge für die Diagnose als auch bei der Auswertung der Ergebnisse. Liest man sich #72 durch, findet man da innerhalb von 22 Minuten praktisch jedes beliebige Ergebnis, wobei sich auch vieles direkt widerspricht. Das hilft weder demjenigen, der das Problem akut hat, noch einem hilfewilligen Leser und schon gar nicht späteren Suchenden, die das dann gar nicht mehr "in der Entwicklung" mitbekommen (wenn sie nicht ständig auf Datum und Uhrzeit eines Beitrags starren), sondern nur noch in "kondensierter Form".
Und ganz ehrlich ... schon mir würde eine "Zusammenfassung" dieses Threads schwerfallen und das, obwohl ich ihn seit dem ersten Tag mitgelesen habe. Morgen wird er eine Woche alt und die bisher gesammelten (und verbürgten, reproduzierbaren und reproduzierten) Erkenntnisse beschränken sich auf "
irgendeine Hardware-Komponente funktioniert
vielleicht nicht" - weder ist bekannt, welche das ist, noch welches Problem sie konkret hat. Das ist nach fast einer Woche schon einigermaßen dünn ... und viele weitere Beiträge werden daran auch nur dann etwas ändern, wenn diese etwas mehr an Informationen aufs Tapet bringen.
Just my 2 cents ... und die Hoffnung meinerseits, daß mein "Appell", die Fehlersuche doch mit
etwas Systematik fortzusetzen (jetzt kommt man ja zumindest mal an die Protokolle) nicht vollkommen ungehört verhallt.
