Weiß jemand was diese Einträge bedeuten?
Das mit der "ptest"-Variablen ist "normal", weil AVM da schon immer etwas inkonsequent war bei deren Inhalt.
So wird der alte Wert in der Variablen durch das Kommando:
Code:
290 echo "ptest " >$CONFIG_ENVIRONMENT_PATH/environment
in der "/etc/init.d/S42-ptest" versucht zu löschen (Zeile 290 ist aus der 113.07.11 und es verschiebt sich immer mal ein wenig, aber "die Gegend" sollte stimmen) ... was im Prinzip auch funktioniert. Nur macht es eben beim procfs-Interface für das TFFS einen Unterschied, ob man im "echo"-Kommando nach dem Variablennamen noch ein Leerzeichen angibt oder nicht ... wie man in "tffs_proc.c" in der Funktion "avm_urlader_setenv_sysctl()" nachlesen kann, wird ohne dieses Leerzeichen die Variable gelöscht und mit dem Leerzeichen auf einen Wert der Länge 0 gesetzt.
Code:
root@FB7490:~ $ grep "ptest" /proc/sys/urlader/environment
ptest
root@FB7490:~ $ echo "ptest" > /proc/sys/urlader/environment
root@FB7490:~ $ grep "ptest" /proc/sys/urlader/environment
root@FB7490:~ $ echo "ptest " > /proc/sys/urlader/environment
root@FB7490:~ $ grep "ptest" /proc/sys/urlader/environment
ptest
root@FB7490:~ $ grep ptest /proc/sys/urlader/environment | busybox hexdump -C
00000000 70 74 65 73 74 09 0a |ptest..|
00000007
root@FB7490:~ $
Wie man oben auch sehen kann, erzeugt die Anwesenheit der Zeile mit "ptest" in der Ausgabe also zwischen dem Namen und dem Newline-Zeichen noch ein "TAB" (hex 09).
Wie liest AVM das also wieder aus beim nächsten Start? So:
Code:
24 export CONFIG_ENVIRONMENT_PATH=/proc/sys/urlader
25 PTEST=`cat $CONFIG_ENVIRONMENT_PATH/environment | grep ptest | tr , ' '`
26 if [ -z "$PTEST" ] ; then
27 PTEST=`cat /proc/cmdline | grep ptest | tr , ' '`
28 fi
Die Variable "$PTEST" enthält also mindestens noch den Namen und das Tabulator-Zeichen ... wenn da irgendwelche komma-separierten Infos im Wert stehen, werden diese Kommata in Leerzeichen umgewandelt.
Seit einiger Zeit spielt diese "ptest"-Variable aber auch eine Rolle bei der Installation einer Firmware ... nur kommt sie dort erst ins Spiel, wenn die Installation bereits durch ist.
-----------------------------------------------------------------------------------------------------------------
Nun ist dieser ganze "ptest"-Kram ja ohnehin zusammengewürfelt ... hier treffen sich Teile, die bei der Produktion einer Box auszuführen sind, mit Optionen, welche den Providern zusätzliche Protokoll-Möglichkeiten beim Test einer neuen Firmware einräumen (psupportd=
irgendwas - der Wert interessiert nicht weiter, weil nur bis zum Gleichheitszeichen verglichen und dann immer auf "1" gesetzt wird in der "S42-ptest") ... eine strikte Trennung zwischen den (internen) Möglichkeiten für AVM und den Zusatzangeboten für Tests durch die Provider (die dafür offenbar spezielle Programme erhalten von AVM, die auf anderen Rechnern laufen und mit der FRITZ!Box in diesem "Testzustand" kommunizieren - denn sonst käme auch ein Provider nur auf beschwerlichen Wegen an die Ausgaben auf "/dev/console" bzw. hätte Probleme, diese vernünftig zu speichern - komme ich nochmal drauf zurück) ist dort jedenfalls nicht zu erkennen.
Ich habe nicht in die 3490 gesehen (den Vergleich mit der 7490 kann ja jeder selbst vornehmen) ... wenn darin nicht noch zusätzlicher Inhalt in der "S42-ptest" auftaucht, sollte das Vorhandensein von "ptest" im Environment jedenfalls nicht der Auslöser sein ... nach dem nächsten Systemstart steht das ohnehin wieder drin (s.o.).
Wobei Fehler dort nicht vollkommen ausgeschlossen sind, denn auch das Starten des "ptestd"-Daemons bei den DOCSIS-Modellen mit dem Parameter "--client_ip=192.168.178.20" ist - behaupte ich mal ganz kühn - ein Fehler, den AVM dort eingebaut hat und der in "nicht-Cable"-Modellen nur deshalb keine Auswirkungen hat, weil dort der "ptestd" nicht Bestandteil der (Release-)Firmware ist. In den Cable-Modelle wird er aber auch in der Release-Version zur Kommunikation zwischen den beiden System im Gerät benutzt ... nur da eben normalerweise ohne den "--client_ip"-Parameter. Eingeschleppt hat AVM das Problem (wenn es denn eines ist in den Augen von AVM, denn i.d.R. hat der gemeine FRITZ!Box-Benutzer keinen Zugriff auf die Zusatzprogramme für den Client) mit der Labor-Reihe, die in die 07.0x mündete.
-----------------------------------------------------------------------------------------------------------------
Warum gehe ich jetzt so ausführlich auf diese Variable ein? Weil ich mehrfach schon erläutert habe, wie man durch das Beobachten von solchen Variablen, die vom System bei jedem Start geschrieben bzw. geändert werden, auch - zumindest grob - ermitteln kann, wie weit das System bei seiner Initialisierung kommt. Hier kann man also mit den Augen (für die genaue Beobachtung der LEDs) in Kombination mit einer Stoppuhr (oder gleich einem Smartphone, weil man das aus dem eigenen Video viel leichter ermitteln kann, da man es mehrfach ansehen kann, während man die Abläufe hier niederschreibt) und dem Vorher-Nachher-Vergleich von Variablen im Bootloader (denn man darf dann natürlich nur einen einzigen Start ausführen und nicht erneut versuchen, das System zu initialisieren, weil man dann wieder den Vorher-Zustand nicht mehr sicher kennt) schon wahre Wunder bewirken ... selbst wenn man das Problem damit wohl nicht reparieren kann. Aber die (Er-)Kenntnis, wo es überhaupt liegt, hilft natürlich vehement bei der Entwicklung einer Strategie für seine Lösung.
-----------------------------------------------------------------------------------------------------------------
Zumal ich - als neutraler Leser - wieder einmal nicht erkennen kann, was hier wirklich passiert ist. Zwar wird immer wieder mal mit "Recovery-Programm" und "linux_fs_start" um sich geworfen (und prinzipiell ist das Geschriebene auch nicht falsch), nur steht da nie, welches Recovery-Programm nun eigentlich auf welches Partitionset losgelassen wurde. Daraus resultieren dann auch sehr merkwürdige Dialoge:
Kann es sein, dass Dein Recovery defekt ist?
Das Recovery kann nicht defekt sein, da ich am Anfang das Partitionsset (0) überschrieben habe, da hat es funktioniert. Nur im Partitionsset (1) eben nicht.
Beim Umschalten auf das funktionierende partitionsset (0) wird der Eintrag "firmware_info" wieder mit dem Wert 140.07.01 versehen, der Eintrag "ptest" bleibt stehen.
Offenbar steht also im Partitionset, welches bei "linux_fs_start=0" verwendet wird, ein FRITZ!OS 07.01 ... da stellt man sich als "Außenstehender" halt die Frage, warum man dann nicht einfach mal mit dem Recovery-Programm für die 07.11 versucht, im anderen Partitionset die neue Version zu installieren? Dafür muß man natürlich das passende (und funktionierende) Recovery-Programm haben, dieses kann dann ja aber nicht das Recovery-Programm sein, mit dem das Partitionset 0 (wenn wir es so nennen wollen) beschrieben wurde, wenn da immer noch eine 07.01 installiert ist ... außer dieses Recovery-Programm hat eben auch "versagt".
Etwas mehr Präzision bei der Beschreibung hilft also sowohl beim Vermeiden von Mißverständnissen als auch gegen "Unverständnis" ob der Dialoge, die sich dann ergeben können.
-----------------------------------------------------------------------------------------------------------------
Ich bin dann aber auch etwas erstaunt, warum Du nicht auf eine (zumindest für mich) naheliegende Möglichkeit für einen Kreuztest kommst (und es auch noch kein anderer vorgeschlagen hat). Da wir hier ja über eine 3490 reden und dort der Einsatz des Recovery-Programms (im Gegensatz zu den GRX-Modellen, wo die UBIFS-Initialisierung bei "recovered=
n" dann beide Systeme unbrauchbar macht, weshalb ich immer mit "eva_to_memory" (o.ä.) arbeiten würde, da hier das "recovered=
n" nicht automatisch gesetzt wird) tatsächlich nur das System in der aktiven Partition (nach dem Inhalt von "linux_fs_start") beeinflußt, kann man ja auch einfach mal
ein noch ein anderes Recovery-Programm (älter oder eben doch die 07.11) auf das vermeintlich defekte Partitionset loslassen ... mit einer noch älteren Version kann man dann zumindest mal ausschließen, daß die Box tatsächlich defekt ist.
Es ist natürlich nicht ausgeschlossen, daß AVM beim Zusammenstellen einer Firmware-Version auch mal Fehler macht ... daß das nicht alles von Alpha bis Omega durchautomatisiert ist (bzw. da auch mal geändert wird, wie jetzt gerade erst wieder bei den Namen der Images), ist ja offensichtlich. Die 3490 ist wohl auch nicht sooo weit verbreitet und da kann dann irgendeine ungewöhnliche Einstellung bei einem Kunden schon mal solitär sein und von anderen gar nicht bemerkt werden.
Da ist es dann wichtig, wirklich nur eine Variable im eigenen Vorgehen zu ändern, damit man tatsächlich sicher sein kann, daß es genau diese ist, welche zum Problem führt. Hier bieten sich also mehrere Möglichkeiten ... von der Installation der 07.11 per Recovery im ersten Partitionset (damit weiß man dann, daß die Box mit 07.11 überhaupt arbeitet) bis zur Installation einer älteren Version in Partitionset 1, damit man sicher sein kann, daß es nicht an der 07.01 generell, dem Recovery-Programm oder vielleicht doch an einem (zu sehr beschädigten) NAND-Flash liegt.
-----------------------------------------------------------------------------------------------------------------
Die Ausweichmöglichkeiten im NAND sind begrenzt (der Controller ist da auch rudimentär und Aufgaben wie Wear-Leveling und Defekterkennung obliegen der Software) und gerade für den Kernel gibt es vermutlich keine vernünftige Möglichkeit der "nicht-linearen Speicherung", weil der Bootloader m.E. ebenfalls eher rudimentären Support für NAND-Flash bietet (genaues weiß man dank CS - was "closed source" heißen soll und nicht "Chip Select" - ja nicht) ... beim Schreiben ja gar wohl gar nicht, denn deshalb installiert ja der ins RAM geladene Kernel sich selbst und beim Lesen wohl wirklich nur linear.
Wenn da also mehr kaputtgeht im NAND, als durch einfache Operationen behoben werden kann (ich bin nicht mal sicher, daß der Bootloader die OOB-Infos beim Laden des Kernels verwendet), halte ich ein Problem für den Bootloader nicht für komplett ausgeschlossen. Nur sind eben die 8 MB für den Kernel im zweiten Partitionset nur ein kleiner Teil des gesamten NAND-Flashs - selbst wenn man beide Kernel-Partitions betrachtet, sind deren 16 MB bei 512 MB gesamt nicht die Welt und die Wahrscheinlichkeit eines Fehlers ist eher gering - zumal dort eher selten geschrieben wird, denn so viele Updates kriegt eine normale Box beim Kunden nun auch wieder nicht.
Aber auch das sieht man dann eben wieder anhand der Variablen ... wenn "firmware_info" angefaßt wird, wurde auch der Kernel erfolgreich geladen und das Root-Dateisystem gemountet ... dann ist zwar ein Fehler innerhalb des SquashFS immer noch nicht vom Tisch (m.W. gibt es dort keine Prüfsumme über das gesamte FS), aber die Verwaltungsinformationen (die im SquashFS verteilt liegen, wobei die Pointer auf die Verwaltungsblöcke am Ende des FS stehen) waren dann schon mal lesbar, weil "firmware_info" erst in "S01-head" (kurz vor deren Ende) neu geschrieben wird mit der Versionsnummer des laufenden Systems.
Da hier ja offenbar bereits (mehrfach) mit "recovered=2" gestartet wurde (wo dann der NAND-Flash für den NAS-Speicher ohnehin gelöscht sein dürfte), ist es auch egal, ob man nun mit dem AVM-Recovery-Programm arbeitet (das dann ohnehin jedesmal auch ein neues TFFS-Image in beide Partitionen schreibt) oder ob man etwas schonender nur ein Image in die Box lädt und dieses startet.
-----------------------------------------------------------------------------------------------------------------
Wobei die Übung, die man beim Umgang
ohne das Recovery-Programm erlangt, später auch nützlich sein kann, wenn man z.B. ein AVM-System so modifizieren will, daß es den Installationsvorgang im Flash protokolliert. Denn hier schließt sich wieder der Kreis zur "S42-ptest" bzw. zur Variablen "ptest". Denn diese wird ebenfalls in der "sbin/flash_update" untersucht (das Skript liegt im YAFFS2-Dateisystem unter "/wrapper", falls es jemand im SquashFS suchen sollte) und mit ihrem Inhalt kann man u.a. dafür sorgen, daß das Protokoll der Installation im Anschluß per TFTP auf einen Server übertragen wird, den man im LAN bereitstellt.
Hier kommen dann auch wieder die "Spezialprogramme" von AVM ins Spiel, jedenfalls ab der 07.11 - denn wenn es ein Programm "psupportd_sendmsg" in der Firmware gibt (was bei der 07.11 als erster Release-Version der Fall ist), dann wird anstelle des TFTP-Clients aus der BusyBox dieses verwendet. Wenn man das Protokoll also ohne die AVM-Programme haben will, muß man dieses Programm aus dem zu installierenden Image löschen und dieses dann "von Hand" installieren. Genau dabei hilft einem dann die Routine, die man beim Umgang mit dem Bootloader erworben hat.
-----------------------------------------------------------------------------------------------------------------
Es gibt also noch viele Optionen beim Versuch, die Ursache des Problems zu ermitteln ... wie immer ist Systematik und auch eine gewisse Ausführlichkeit bei der Dokumentation der Ergebnisse die beste Voraussetzung, um bei anderen vielleicht noch die eine oder andere Idee zu produzieren, was man versuchen/testen/ausschließen könnte.
5
