Fritzbox 6490 Cable Firmware Update?

[MGT]

Edit4: mtd.img hat eine Größe von 8KB. Kann das diesmal sein?

Edit3: Nach ziemlich genau 80 min ist das Skript durchgelaufen. (Oder gibt es hier einen Timeout?)

Edit2: ./build_tffs_image rödelt jetzt schon über 60 min... Wenn das gestern auch schon so war, dann hatte ich mich da gründlich verschätzt, was die Dauer anging (hatte halt nebenbei TV geschaut)

Edit: Fehlerbild immer noch das gleiche.... Hatte diesmal PATH=$PATH:. nicht gesetzt gehabt,.... ./build_tffs_image rödelt jetzt schon über 10 min...


Text war:

Hi PeterPawn,

vielen Dank für deine Antworten.
Dann hat mich mein Bauchgefühl nicht getäuscht.

Ich habe es eben nochmal versucht. Dabei ist mir aufgefallen, das ich die Schritte nicht mit ROOT durchgeführt hatte, sondern als user FREETZ.
Kann es daher kommen?
Zumindest habe ich es eben nochmal als ROOT versucht und nun spuckt mir der Schritt ./build_tffs_image ein paar Fehlermeldungen aus:

./build_tffs_image: Zeile 37: nametable_to_tffs: Befehl nicht gefunden
./build_tffs_image: Zeile 41: environment_to_tffs: Befehl nicht gefunden
./build_tffs_image: Zeile 45: counter_to_tffs: Befehl nicht gefunden

--> gibt es da einen Zusammenhang mit der Tatsache, dass ich erstmal alle Scipte auf /bin/bash im Header abändern musste, damit die Skripte auch unter Freetz (Ubuntu/Debian) lauffähig sind?


Info an alle Leser: Lösung für diese Fehlermeldungen ist das Setzen von "PATH=$PATH:."

Allerdings weiß ich immer noch nicht, warum die Erstellung des mtd.img so lange dauert und ob ich es dennoch verwenden könnte ...

 

[PeterPawn]

Ne, in "build_tffs_image" gibt es praktisch nichts, was auch nur annähernd 80 Minuten laufen könnte (vielleicht auf einem 8086, aber darüber reden wird ja sicherlich nicht?). Das Dekodieren von Base64-Dateien erfolgt ja dabei gar nicht ... selbst wenn das alles in Shell-Befehlen nachgebildet werden müßte, dauert das niemals so lange - da ist irgendetwas anderes schwer daneben.

Ich werde die aktuellen Versionen aus dem Repository mal gelegentlich bei mir testen ... aber mir fehlt so jede Idee, was das sein soll bzw. wo da in den Skript-Dateien ein Problem liegen sollte - das wäre vermutlich ja auch schon anderen aufgefallen, würde ich mal annehmen wollen.

Wie sieht es denn aus mit dem von mir angesprochenen "verständigen Test" - also meinetwegen dem Debuggen einer Skript-Datei (Aufruf der "bash" mit "-x" als Option) oder irgendwelchen anderen Maßnahmen zum Eingrenzen der Ursache? Bist Du dazu in der Lage oder geht es nur nach "Schema F" und wehe es funktioniert dann etwas nicht so, wie es erwartet wird?

 

[MGT]

Zuerst zu deinen Fragen:
Wir sprechen von einer VM auf einem Intel Core 2 Duo P7350 / 2 GHz.
Die VM zweigt dabei 2GB RAM von 4GB RAM ab.
Die txt Datein count und env sehen meinem Verständnis nach gut aus. Damit meine ich: interessant Infos im Klartext gut lesbar und formatiert vorhanden. Die werden also richtig generiert.
Zum Thema debuggen: ich habe zwar Wirtschaftsinformatik studiert, allerdings sind meine letzten Programmieraktivitäten schon fast 20 Jahre her. Ich war nie wirklich ein guter Programmierer. Kann zwar noch Quelltext lesen, aber traue mir nicht mehr zu, dass ich via debugging auf eine Fehlerursache schließen könnte.
Dafür bin ich einfach auch zu Lange aus dem Thema draußen :-(

Wenn etwas nicht funktioniert, dann forsche ich nach. Sonst wäre ich auch nicht zu den o.g. infos gelangt. Aber ohne Fehlermeldung und einfach nur aufgrund der langen Dauer der Dateierstellung bin ich jetzt mit meinem Latein am Ende.


Meine Fragen:
Passt jetzt die Größe von 8KB?
Das Script läuft ja "irgendwie" durch. Oder ist doch ein Timeout möglich?
Kann ich dir die mtd.img mal zum Gegenprüfen zukommen lassen?
Warum kann mal eigentlich die Datei nicht von einer anderen 6490 verwenden?

 

[PeterPawn]

1. Das weiß ich nicht ... die Größe ist vom Inhalt abhängig.

2. Ich wüßte nicht, wo das Skript so viel Zeit verbringen sollte ... erst recht nicht, was es dann irgendwann als Abbruchbedingung geben sollte. Etwaige Beschränkungen eines Jobs (ulimit) legt das Host-System selbst fest.

3. Nein ... aber Du kannst sie ja selbst mittels "dissect..." noch einmal zerlegen lassen und das Ergebnis mit den Eingabedaten vergleichen.

4. Weil das Environment die Daten für genau diese eine (eigene) Box enthält ...

 

[Pokemon20021]

Erst bei dem Schritt 6.62-avm auf 6.63-avm kommt der Fehler 8 (bzw. Fehler 0). Dieses Update habe ich aber aus der WIN10-Umgebung über Webbrowser und dem eingebauten Webinterface der Box sowohl online als auch offline (Download-Image) angestoßen. Erst mit der Prozedur newfirmware.image und den beiden Scripten - ebenfalls angestoßen in der WIN10-Umgebung - hat das Update auch auf 6.63 funktioniert.

@reinhard-gehlen: Nur um sicher zu sein; Frage hast Du Schritt 6.) aus Tetzlav Doku zurückgebaut, d.h. umbenannt oder gelöscht ?

6. Box neu starten und dann via ftp oder Fritz!NAS die beiden scripte von @PeterPawn aus #967 (UNBEDING LESEN!) run_update und update_firmware aus YourFritz/autoupdate nach /var/media/ftp/

Hintergrund:
Eigentlich ist (so wie ich es bisher verstanden habe) die provideradditive.tar mit Payload "Custom-Version of /var/post_install" nicht für Online-Update vorgesehen;
https://github.com/PeterPawn/YourFritz/blob/master/autoupdate/run_update

# First the script looks for a file 'newfirmware.image'. If this cannot be found, the script          #
# '[COLOR=#0000FF]check_update' will be used to search for a newer version, which will be loaded, if any is found.   [/COLOR]#

evtl. kann Entwickler PeterPawn etwas dazu sagen, ob hier "Nebenläufigkeiten, RaceConditions, ..." bei Online-Update in Verbindung mit modifiziertem /var/post_install auftreten können und dieses Fehlverhalten/Fehlermeldung hervorrufen können;

EDIT: Text angepasst "Frage zu Schritt 6 hinzugefügt"

 

[reinhard-gehlen]

@reinhard-gehlen: Nur um sicher zu sein; Frage hast Du Schritt 6.) aus Tetzlav Doku zurückgebaut, d.h. umbenannt oder gelöscht ?


Hintergrund:
Eigentlich ist (so wie ich es bisher verstanden habe) die provideradditive.tar mit Payload "Custom-Version of /var/post_install" nicht für Online-Update vorgesehen;
https://github.com/PeterPawn/YourFritz/blob/master/autoupdate/run_update


evtl. kann Entwickler PeterPawn etwas dazu sagen, ob hier "Nebenläufigkeiten, RaceConditions, ..." bei Online-Update in Verbindung mit modifiziertem /var/post_install auftreten können und dieses Fehlverhalten/Fehlermeldung hervorrufen können;

Ja, ich hatte nach dem Update von 6.50-kdg auf 6.62-avm die (vom Script automatisch umgenannte, alte) newfirmware.img und die beiden Scripte aus dem Fritz!NAS gelöscht bevor ich das Online-/Offline-Update auf 6.63-avm angestoßen habe.

Den Schritt nochmal ein neues tffs-Image zu bauen würde ich gerne ausprobieren.

In der Beschreibung von @tezlav (#1047) ist ja in Schritt 3 auf die "original" /var/post_install verlinkt (s.a. #968 ). Daraus wäre dann ohne die Ergänzung von @PeterPawn (vgl. #967, Erweiterung um den Payload) eine provideradditive.tar zu bauen.

Was ich nicht ganz nachvollziehen kann: Die Script-Erweiterung um den Custom-Payload testet doch als erstes auf die Existenz des update_firmware-Scriptes. Wenn nicht vorhanden passiert doch nichts hinsichtlich eines Updates. Wo soll da ein Seiteneffekt zum Standard-Update-Prozess der Box herkommen?

Was muss ich bei der NODE-Nummer beachten, wenn ich ein neues tffs-Image baue?

./tffs_add_file ./erweiterte_supportdaten.txt -o 5 29 /tmp/provideradditive.tar > /tmp/mtd.img


Was ich allerdings noch nicht ausprobiert habe und was ich vor einem neuen tffs-Image noch machen werde ist

# First the script looks for a file 'newfirmware.image'. If this cannot be found, the script          #
# 'check_update' will be used to search for a newer version, which will be loaded, if any is found. #

D.h. wenn ich nur die beiden Scripte in der Partition 6.62-avm ins NAS lade müsste nach meinem Verständnis das Firmware-Image automatische gezogen werden. Wenn dem so ist, würde ich die beiden Scripte (ohne das jeweilige Firmware-Image-File) im NAS belassen und so auch zukünftige Firmware-Update behandeln.

VG

P.S. aus hoffentlich nachvollziehbaren Gründen habe ich diesmal komplett auf irgendwelche Werkseinstellungs-Resets verzichten, um die neuen Zertifikate nicht zu verlieren, auch wenn das bei den neueren Firmwareversionen eigentlich nicht mehr der Fall sein sollte.

 

[MGT]

Danke, PeterPawn.

Ich hatte bisher VirtualBox als VM Maschine verwendet. Nachdem ich nun VMPlayer verwendet habe mit dem gleichen VM Image (freetz), hat die Erstellung von mtd.img nur ein paar Minuten gedauert.
Habe diese dann erfolgreich in mtd3 und mtd4 überspielt.
Da ich ja beim ./build_tffs_image wie beschrieben die 001d.bin als 3.Parameter mit reingenommen hatte, sollte doch beim nächsten Booten bei Vorhandensein von run_update und update_firmware sowie newfirmware.image das Update ausgeführt werden, oder?

Leider ist beim Hochfahren kein Update angestoßen worden. Die Box hat ganz normal in kdg 6.31 gebootet. (bis auf die Abfrage nach neuem PW/ Installationsassistenz ist gestartet)
Ich hatte die 3 Dateien via Fritz.NAS rüberkopiert in das Fritz.NAS Hauptverzeichnis in der Annahme, dass dies das Verzeichnis für /var/media/ftp ist, oder?
(Btw: wie komme ich an /var/media/ftp ran? Telnet ist ja nicht vorhanden und via FTP komme ich in kein höheres Verzeichnis?!)

--> Was habe ich übersehen :-(

 

[reinhard-gehlen]

https://www.heise.de/newsticker/mel...ehler-individuelle-Einstellungen-3601440.html

Ich möchte nicht wissen, wieviele Boxen dadurch ihre neuen Zertifikate verloren haben, wenn sie noch nicht auf FW 6.31 und höher waren.

 

[MGT]

hmm... hat keiner der Experten mehr eine Idee? :-(
Wäre doch gelacht, wenn wir das nicht hinbekommen würden. Nur leider gehen mir die Ideen aus...

 

[PeterPawn]

@MGT:
Wenn Du das mal so aufschreiben könntest, daß man sich nicht erst einen Knoten ins Hirn machen muß, um es zu verstehen, dann kriegst Du vermutlich auch Feedback.

Für mich liest sich das so, als hättest Du eben nicht ausreichend gelesen und verstanden, was bisher schon "veröffentlicht" wurde. Das Aktualisieren der Firmware erfolgt nämlich erst beim nächsten Herunterfahren der FRITZ!Box (erst da wird die geänderte "post_install" gestartet) und vielleicht wird ja jemand anderes aus Deiner Beschreibung der Abläufe schlau ... ich werde es jedenfalls nicht. Einmal ist von "beim nächsten Booten" und dann wieder von "beim Hochfahren" die Rede ... das sind irgendwie alles eher "unbestimmte" Zeitpunkte. Vermutlich kann man das wesentlich besser, logischer und nachvollziehbarer beschreiben ... und dann findet sich bestimmt auch jemand, der sich die Mühe macht, es verstehen zu wollen.

 

[MGT]

Auch für einen Nicht-(Wirtschafts-)Informatiker sollte klar sein: Booten = Hochfahren; d.h. synonym zu betrachten.

Aber ich gebe dir Recht, der Zeitpunkt ist undeutlich beschrieben und ob ich hier einen Hard-Reset gemacht habe oder nicht.
Das hole ich gerne nach.
Und ja, mea culpa: Ich habe nicht die kompletten 71 Seiten durchgearbeitet, wohl aber die Suche intensiv bemüht!... ansonsten hätte ich nicht die Infos erhalten, die ich ja versucht habe als Ablaufplan zusammenzustellen. ... und damit das nicht egoistisch ist, habe ich auch für die "Nachwelt" an meinen Bemühungen teilhaben lassen für all diejenigen, die ebenso versuchen Ihre kdg 6.31 zu debranden + updaten.

Also hier nochmal in strukturierter Reihenfolge:

0) VM-Ware Image von Freetz runterladen
1) diesmal VM Ware Player anstatt VirtualBox verwendet
2) git clone git://github.com/PeterPawn/YourFritz
3) Skripte von YourFritz auf bash anpassen (/bin/sh -> /bin/bash) und Path setzen (PATH=$PATH:.)
4) 001d.bin organisieren (provideradditive) (z.B. https://www.drop***com/s/w0f34vlsu2fyrzf/001d.bin?dl=1)
5) Box booten und in eva anhalten (bei blinken "ftp 192.168.178.1, adam2/adam2 einloggen, mit strg-D wieder raus)
6) env.txt, count.txt erstellen analog nach (http://www.ip-phone-forum.de/showthr...#post2162540):
/eva_get_environment env 192.168.178.1 > /tmp/env.txt
./eva_get_environment count 192.168.178.1 > /tmp/count.txt
7) tffs image inkl. 001d.bin erzeugen (als 3. Parameter):
build_tffs_image tffs_name_table /tmp/env.txt /tmp/count.txt /home/freetz/001d.bin > /tmp/mtd.img
8.) ./eva_store_tffs mtd3 /tmp/mtd.img
./eva_store_tffs mtd4 /tmp/mtd.img
9) "Box neu starten" (== O-Ton user tetzlav; ich interpretiere das als "hochfahren" bzw. "neu booten" ;-) . Ich habe dies durch stromlos machen und erneutes Stromzuführen erreicht.
10) Nach der Erreichbarkeit des Webinterfaces (= erfolgreiches Hochfahren):
run_update und update_firmware aus YourFritz/autoupdate via FTP [Edit: neu am 20.01.17] direkt von der VM zur fritzbox übertragen. Zur Sicherheit chmod 755 durchgeführt.

war - als falscher Weg: "von laufender WMware Maschine gezogen auf Windows-Rechner und dann via Fritz!NAS in das default-Verzeichnis kopiert. (danach via FTP auf 6490 und die Rechte dort wieder auf chmod 644 angepasst)

(ich interpretiere nach Lektüre diverser Foren-Stellen dieses Verzeichnis eben als "/var/media/ftp/" -> oder wie komme ich sonst an diesen Pfad?! Via FTP komme ich nirgends anderswo hin?!)
11) AVM 6.61 == newfirmware.image via Fritz!NAS nach /var/media/ftp (== default Verzeichnis) kopiert
12) Fritzbox via Webinterface neu gestartet = hochgefahren = gebootet
13) Satz mit "x" = War wohl nix --> immer noch kdg 6.31 vorhanden.

Die Box hat beim Booten auch nicht den Anschein gemacht, dass hier versucht wird eine Firmware zu installieren. Also keine verlängerte Bootdauer oder wildes Blinken von INfo-Led...

Ich hoffe, ich konnte mich verständlicher ausdrücken.

Danke für eure Kommentare im Voraus.

Gruß,
MGT

 

[PeterPawn]

Überprüfen der "/var/post_install" anhand der Support-Daten - deren Zeitstempel sollte mit dem der Datei aus der 001d.bin (vorher entpacken) übereinstimmen. Ist das nicht der Fall, wird offenbar keine geänderte "post_install"-Datei entpackt.

Ist das aber die richtige und wird das "run_update" korrekt aufgerufen, gibt es explizit die Möglichkeit, den Ablauf von "run_update" zu überwachen ... genau dafür habe ich ja die Protokollierung ins Netzwerk eingebaut. Wie das geht, steht im Beitrag zu dem Skript in diesen Thread.

Und noch einmal zum Thema "Booten/Hochfahren" ... der entscheidende Punkt ist ja, daß das Skript eben nicht beim "Hochfahren" ausgeführt wird, sondern beim "Herunterfahren" (um mal in dieser Terminologie zu bleiben) und Deinen bisherigen Texten war nicht zu entnehmen, daß Dir dieser Umstand bewußt ist.

Da das "Booten" hingegen (im Sinne von "Neustart") durchaus beide Vorgänge umfassen kann (also das "Herunterfahren" und das anschließende "Hochfahren"), kommt es eben auch darauf an, zu welchen Zeitpunkt man das NAS womit befüllt hat. Es gibt einen definierten Zeitpunkt, zu dem die Existenz der Dateien essentiell ist und das ist eben genau nicht der Zeitpunkt des "Hochfahrens".

Wenn ich #1409 jetzt richtig verstanden habe (die komplette Aufzählung wäre gar nicht notwendig gewesen, ich habe ja klar geschrieben, wo ich Probleme mit der Nachvollziehbarkeit hatte und warum das so war), dann stimmen allerdings die Zeitpunkte der Kopieraktionen - und auch die Annahme, daß es sich bei "/var/media/ftp" um das Basisverzeichnis des NAS handeln würde, ist (in Grenzen) richtig - das gilt aber nur dann, wenn der eingerichtete/verwendete Benutzer vollen Zugriff auf alle NAS-Verzeichnisse hat ... ansonsten landet er automatisch in seinem Basisverzeichnis.

Damit sind die Möglichkeiten für offensichtliche (und "gern genommene") Fehler dann aber auch erschöpft ... auf den Vorschlag der Kontrolle des erzeugten TFFS-Images mit "dissect_..." bist du nicht eingegangen (oder hast vergessen es zu erwähnen), der nächste denkbare Punkt nach einem falschen Image ist eine falsche "provideradditive.tar" (das steht hier im ersten Absatz) und ab dem erfolgreichen Aufruf von "run_update" kann man sich das Protokoll ansehen anstatt zu raten.

Da ich keine Ahnung habe, was in der "001d.bin" am Ende steht, nehme ich einfach einmal an, daß da irgendwo "update_firmware" als "Switch" aufgerufen wird, der doppelte Verzweigung in Richtung "run_update" verhindern soll.

Ich weiß am Ende nicht, was man da noch kommentieren sollte ... der Ablauf und Aufruf von "run_update" ist ausführlichst beschrieben, das Repository enthält im "autoupdate"-Folder eine README.md, die auf den entsprechenden Beitrag in diesem Thread verweist und irgendwelche konkreten Fragen (abseits von NAS-Basis == /var/media/ftp) kann ich nicht erkennen - die Frage "Geht nicht, warum?" kann ich gar nicht (zwingend valide) beantworten, selbst wenn ich wollte.

 

[MGT]

Es scheitert bereits beim 1. Schritt:
Wenn ich die Support-daten richtig interpretiere (habe dort schlicht nach Datumsangabe von post_install gesucht), dann stimmt dieses Datum nicht mit den Datumsangaben innerhalb von 001d.bin zusammen.
Nach deiner Aussage wird also "offenbar keine geänderte "post_install"-Datei entpackt."

--> heißt das, dass meine Box ein hoffnungsloser Fall ist?

Und ich hatte ja eine bereits eine konkrete Frage gestellt die an dieser Stelle damit nochmal wiederholen möchte: was könnte ich übersehen haben?

 

[Pokemon20021]

Es scheitert bereits beim 1. Schritt:
Wenn ich die Support-daten richtig interpretiere (habe dort schlicht nach Datumsangabe von post_install gesucht), dann stimmt dieses Datum nicht mit den Datumsangaben innerhalb von 001d.bin zusammen.
Nach deiner Aussage wird also "offenbar keine geänderte "post_install"-Datei entpackt."

welchen Timestamp/Size hat denn Deine /var/post_install ?

freetz@Pi-1:~$ tar tvpf /tmp/provideradditive.tar
-rw-rw-r-- 0/0         0 2016-11-02 11:55:47 ./provider_additive_enables_post_install.txt
lrwxrwxrwx 1000/1000         0 2016-11-02 15:54:32 symlink_to_var -> /var
-rwxr-xr-x 0/0      9919 2016-11-02 12:09:19 symlink_to_var/post_install
freetz@Pi-1:~$

Richtig wäre, wenn nach "eva_store_tffs" folgende Zeile in der Supportdata.txt erscheint:

-rwxr-xr-x    1 root     root          9919 Nov  2 12:09 post_install

auch vermisse ich die Antwort auf:

den Vorschlag der Kontrolle des erzeugten TFFS-Images mit "dissect_..." bist du nicht eingegangen (oder hast vergessen es zu erwähnen)

einfach mal:

cd YourFritz/tffs
./dissect_tffs_dump < /tmp/mtd.img

eingeben, dann sollte auch die provider-additive in Form der Datei 001d.inflated enthalten sein.

 

[MGT]

Danke, das hilft mir schonmal einen Schritt weiter.

Timestamp /var/post_install wie vermutet identisch wie bei dir:
02.11.2016
(da ich ja die provideradditive.tar bzw. die 001d.bin von tetzlav verwende)

Infos aus Supportdata.txt:
Nov 2 2016 post_install

Bei Ausführung von ./dissect_tffs_dump < /tmp/mtd.img kommt allerdings:
"unexpected error reading TFFS dump"

Nun interpretiere ich das, dass die provideradditive zwar erfolgreich modifiziert und übertragen wurde, aber dennoch das IMG irgendwie doch nicht passt?...
Was kann ich da tun?

 

[PeterPawn]

Das liegt daran, daß das erzeugte Image keinen "leeren" Eintrag am Ende enthält. Beim Schreiben in den Flash-Speicher entsteht durch dessen Aufbau (leere Zellen sind alle "1") automatisch nach den geschriebenen Daten ein weiteres 16-Bit-Feld mit 0xFFFF - das ist bei einem "Dump" dann das Ende der gespeicherten Daten. Dieser Eintrag ist eben normalerweise bereits vorhanden (jedes nicht beschriebene Byte im Flash ist 0xFF) und braucht daher nicht geschrieben zu werden.

Entweder man hängt also noch dieses 0xFFFF an das erzeugte Image an, bevor man es noch einmal zur Kontrolle zerlegen läßt oder man benutzt noch einmal das (inzwischen erweiterte) "build_tffs_image", das nunmehr ans Ende noch einen solchen leeren Eintrag schreibt, so daß man das Image direkt wieder an "dissect_tffs_image" verfüttern kann.

Ansonsten habe ich ja bereits geschrieben, daß man dann (sofern die "post_install" den richtigen Inhalt hat und es bis zum Aufruf von "run_update" kommen müßte) einfach mal die Protokollierung anwerfen kann (und das auch tun sollte).

 

[zar77]

Hallo Gemeinde,

folgendes Problem...ich hatte eine ehemals kdg-FB-6490 erfolgreich auf 6.63 geupdatet. Mein Provider konnte die Box danach priovizionieren ;-) allerdings ohne Telefon, weil keine mta-mac gesendet wurde. Bei dieser Box fehlten jedoch ca. 1,5 Mbit im upload obwohl auf der Übersichtsseite die richtige Geschwindigkeit stand.
Jetzt habe ich mir noch eine ehemals kdg-Box gekauft und diese mit der 6.51 bespielt --> siehe hier
Jetzt klappt die Telefonie, dass upload-Problem besteht weiterhin.
Mit dem "alten" Arris-Modem, funktioniert der upload.

Jetzt habe ich mich an avm gewandt und die wollen ein support-file haben. Kann ich denen das "ruhigen Gewissens" senden oder lieber davon Abstand nehmen?
Hat einer von euch vlt. einen Lösungsvorschlag?

Danke für die eventuellen Antworten im Voraus.
Gruß Zar

 

[MGT]

so langsam bin ich am Verzweifeln. Via netcat erhalte ich gar keine Signale von der Box. Kann also nicht "zuhören", was das Skript macht (oder eben auch nicht...)
Aber da die Box immer sehr schnell alle 5 LEDs aufleuchten läßt, wenn ich im Web-Frontend den Neustart anstoße, kann ich irgendwie nicht glauben, dass das Skript überhaupt angestoßen wird.
Aber wenn ja in der post_install das gleiche Datum angezeigt wird wie die Daten in der provideradditive.tar, so sollten doch dann auch die Inhalte identisch sein?!
Kann man was beim Kopieren der Skripte ins NAS falsch machen?
Ich bitte um weitere Denkanstöße! Danke

 

[PeterPawn]

Was machst Du denn genau mit "netcat", daß das nicht funktionieren will?

EDIT: Die Abfragen am Beginn der "post_install" bzw. in "update_firmware" brauchen vermutlich unter 0,1 Sekunden ... ich würde es ernsthaft bezweifeln, daß man den Unterschied zwischen der originalen "post_install" und der modifizierten anhand des Verhaltens der LEDs erkennen kann. Am Ende dürfte nicht einmal die Abarbeitung von "run_update" bis zur Zeile 154 (da erfolgt dann das Entpacken der neuen Firmware, wenn bis zu diesem Punkt kein Fehler auftrat) eine merkliche Verzögerung nach sich ziehen - da sieht man also maximal ein erfolgreich gestartetes Update anhand der LEDs und aus dem geschilderten "Lagebild" anhand der LEDs darauf zu schließen, daß da "run_update" keinesfalls aufgerufen werden kann, ist einfach Nonsens.

Ansonsten muß man eben über eine andere Lücke kontrollieren, ob die "provideradditive.tar" nun ausgepackt wird oder nicht - eine Möglichkeit wäre es ja auch, zusätzlich zur "post_install" noch eine weitere Datei ins TAR-File zu nehmen, die dann nach /symlink_to_var/media/ftp entpackt wird. Existiert diese Datei nach dem Löschen einer event. schon vorhandenen Kopie und einem anschließenden Neustart der Box, dann wird die "provideradditive.tar" ja offenkundig korrekt entpackt - da bleibt dann nur noch der Inhalt von "post_install" oder einer von dort aufgerufenen Skript-Datei als mögliche Fehlerursache übrig ... aber das ist doch irgendwie alles "selbsterklärend" und wer tatsächlich das Prinzip verstanden hat und nicht nur "nach Rezept kochen" will, der sollte doch auch genug Phantasie haben, um sich passende Kontrollen für die einzelnen Schritte zu überlegen.

Die Forderung nach "Denkanstößen" ist jedenfalls Unfug ... es gibt so viele denkbare Fehlerquellen, daß deren Aufzählung Stunden in Anspruch nehmen würde; da ist das eigene Verfolgen der ausgeführten Schritte und die Prüfung von deren Ergebnissen allemal leichter und dafür braucht es ja eigentlich keine solchen Tipps. Wenn jemand keine Idee hat, wie er eine bestimmte Überprüfung ausführen soll und dann danach fragt, kann ich das noch verstehen ... die Aufforderung an die hier Schreibenden, unter Zuhilfenahme ihrer Glaskugeln nun zu raten, was bei Dir schieflaufen könnte, ist irgendwie fehl am Platze; jedenfalls in meinen Augen und damit bin ich dann (bis zu konkreteren Fragestellungen) auch raus.

 

[MGT]

Nun, wenn ich eine konkrete Frage hätte, dann würde ich Sie ja stellen.
ich habe durch deinen Text neue Denkanstöße erhalten. Danke dafür.
Ich finde es aber ziemlich unverschämt und überheblich, wenn du über die Unwissenheit von Foren Teilnehmern derart sprichst.
Gut, in deiner Expertenrolle kannst du dir diese Überheblichkeit sogar erlauben.
Nur bedenke bitte: wenn alles so trivial wäre, wie es für dich erscheint, dann wären ja alle Foren-Suchenden in Wahrheit Experten und es würde dieses Forums nicht bedürfen.

Alles ist einfach, wenn man weiß wie es geht.
nur weil du es weißt, macht es das für andere nicht einfacher.

Ehrlich, ich brauche da deine demoralisieren Aussagen nicht und wäre dir dankbar, wenn du weiterhin trotzdem konstruktiven Input geben würdest. Ich hatte mir hier im Forum Hilfe erhofft.
Danke für dein Engagement, da die Community nicht so weit wäre wie es ist.
Allerdings: kann noch jemand anderes von den Experten Input geben?
Vielleicht war jemand, der hier mitliest schonmal in einer ähnlichen/ gleichen Situation?

Also modifizierte post_install / provideradditive vorhanden, aber dennoch keine Ausführung der Skripte im NAS-Hauptverzeichnis?