2. Die skripte setzen vorraus dass /bin/sh eine bash ist, von was man eigentlich nicht ausgehen sollte (bei debian ist das z.B. eine dash). Wenn man bash will sollte man auch /bin/bash schreiben. Also alle skript header in eva_tools und tffs auf #!/bin/bash aendern.
Ok, ist ein Standpunkt, den ich nicht teile ... außerdem hoffe ich, daß die Skripte tatsächlich auch mit der "ash" aus der Busybox zufrieden sind. Wenn ich wirklich die "bash" vorausgesetzt hätte, hätte ich einiges wesentlich einfacher machen können (z.B. /dev/tcp verwenden) - es ist Absicht, daß das nicht der Fall ist und somit die Dateien auch auf einer STB oder einem RasPi o.ä. verwendet werden können. Es gibt wirklich nur sehr wenige Systeme, welche die eingeschränkte Syntax nicht verstehen.
Klar, man kann auch "tcsh" oder "ksh" verwenden (wenn wir mal den "Debian-Sonderfall" außen vorlassen, daß die "dash" am Ende "nur" POSIX-kompatibel ist und selbst die "ash" einige (sinnvolle) Erweiterungen ggü. POSIX bietet, tut mir ja leid für die Benutzer einer Debian-basierten Distribution, aber das Linux-Universum besteht auch noch aus anderen Komponenten und die kennen die "dash" am Ende meist gar nicht), aber es zieht sich (hoffentlich) wie ein roter Faden durch das gesamte "YourFritz"-Repository, daß die Dateien auch jede Menge zusätzlichen Aufwands in Kauf nehmen, damit sie auch direkt auf einer FRITZ!Box laufen können (zumindest mit geringem Anpassungsaufwand) und da ist die aktuelle Shell eben das "ash"-Applet.
Die Konvention ist es eigentlich auch, daß der /bin/sh-Link auf die aktuell verwendete Shell zeigt. Die "ash" ist (in Grenzen, wenn man aufwändige Konstrukte vermeidet) kompatibel mit der "bash" und die Benutzer einer anderen Shell kennen das Problem in aller Regel bereits, denn "bash" ist nun mal der "Quasi-Standard" und viele andere Skript-Dateien laufen mit anderen Shell-Dialekten ja auch nicht. Und als Debian-Benutzer sollte man auch an diverse Inkompatibilitäten gewöhnt sein ... das gilt auch für den Unterschied der Pakete "netcat-traditional" und "netcat-openbsd".
Ich hatte zwar mal die Angewohnheit, in solchen Skript-Dateien die Existenz aller benötigten Programme am Beginn zu testen (es gibt noch Rudimente in einigen Dateien im Repository bzw. auf yourfritz.de und schon der unterschiedliche Ablageort einiger Dateien (/bin vs. /usr/bin) macht es fast unmöglich, da Dateien für sämtliche Geschmacksrichtungen von Linux passend zu machen), aber das macht das "Mitlesen" nicht einfacher und so bin ich (solange es kein "load & run"-Skript ist) davon wieder weg.
Hier
sollen die Verwender ja gerade vorher nachsehen, was da passiert und dann fällt ein "nc", welche sich nicht von seiner Standardeingabe trennen mag (also den "-d"-Parameter nicht kennt, das geht dem Busybox-Applet genauso) recht schnell auf. Hier macht es sich aber bemerkbar, daß ich tatsächlich meist als "Dokumentation" irgendeinen Thread hier verwende und solche Voraussetzungen entweder im Text im Header der Datei beschreibe oder sogar "nur" in dem betreffenden Beitrag hier ... auf der anderen Seite ist es auch nervig, jede Kleinigkeit bis ins Detail zu beschreiben (für Leser und Autoren).
fesc schrieb:
Auserdem sollte man sicher gehen dass "." in der PATH variable ist (PATH=$PATH:. oder set path=($path .) ).
Ich hoffe mal, daß ich das an der anderen Stelle (die meinte ich als ich vom "vergessenen Link" oben schrieb, war m.E. KingTutt oder Riverhopper geantwortet und da ging es um die Verwendung von "provider additive"-Sicherungen) angemerkt hatte ... aber ich sehe eigentlich zur Zeit nur in der "Zusammenfassung" mehrerer Skript-Dateien in "build_tffs_image" eine Stelle, wo das relevant wäre (die anderen Dateien sollten event. mit "./scriptname" aufgerufen werden). Die andere Klippe (die "yourfritz_helpers"-Datei muß im aktuellen Verzeichnis liegen) ist noch direkt in der GitHub-Ansicht zu sehen, denn das war der Kommentar des
letzten Commits dort.
Aber ich werde darüber nachdenken, ob ich diese Stelle nicht wirklich ändere ... mal sehen - ich sehe Vor- und Nachteile in der Verwendung von "./scriptname" (vor den letzten Commit stand da noch "bin/scriptname" drin, weil die anderen Skript-Dateien bei mir tatsächlich in einer Hierarchie an anderer Stelle lagern) und da keine Linux-Installation 1:1 wie die andere aussieht (wir reden hier ja nicht von der Box selbst), ist das etwas zuviel Aufwand (der auch nicht über "autoconf" o.ä. abgefangen werden kann/soll, denn das gibt es auf der Box dann wieder nicht), es wirklich so umzusetzen, daß es auf jedem denkbaren System sofort verwendbar ist.
fesc schrieb:
2.5 Box booten und in eva anhalten (bei blinken "ftp 192.168.178.1, adam2/adam2 einloggen, mit quit wieder raus).
Man kann auch "eva_discover" aus "eva_tools" verwenden (gibt es inzwischen auch in einer PowerShell-Variante für die Windows-Benutzer), dann erspart man sich ggf. das Umkonfigurieren der lokalen Netzwerkeinstellungen auf dem verwendeten Gerät, weil man dem Bootloader die Adresse vorgeben kann.
fesc schrieb:
4. Files in richtiges format fuer die tffs tools umwandeln:
sed -i -e 's/\([^ ]*\)[ ]*\(.*\)/name=\1 value="\2"/' /tmp/env.txt
sed -i -e 's/\([^ ]*\)[ ]*\(.*\)/name=\1 value="\2"/' /tmp/count.txt
Diesen Schritt verstehe ich nicht ... nach meiner Ansicht sollten die Dateien "environment_to_tffs" und "counter_to_tffs" aus dem Verzeichnis "tffs" genau diese Aufgabe übernehmen.
fesc schrieb:
5. Die Werte in count.txt die von der 6490 kommen mag das tffs skript nicht. Also ggf. count.txt editieren und alles von "u" auf "0" setzen.
Anm: diese Zeile gibt einen Fehler da $value nicht gesetzt ist:
eval $name=$(( -1 << $value ))
Ok, das ist mir auch aufgefallen, daher enthält "counter_to_tffs" dafür auch eine
"Spezialbehandlung".
fesc schrieb:
8. Image auf mtd3 und mtd4 schreiben. Ich nehme an hier ist es extrem wichtig wirklich mtd3/4 zu tippen!
In der Tat ... die 6490 mag die Namen nur in kleiner Schreibweise, bei Großschreibung stellt sie sich blöd.
fesc schrieb:
name=crash value="[0]0,529fbc50,48217088[1]4821614c,529fbc7c,529fbc60[2]352e2a9,54bc6f00,1[3]48563a44,60,0"
Das ist der Punkt des letzten Absturz mit "kernel panic" ... das System enthält extra recht umfangreichen Code, der (immer unter der Annahme, daß da die Strukturen noch stimmen) in so einem Falle entweder einen langen Stack-Dump erzeugt und in einem TFFS-Node sichert oder nur die wichtigsten Registerinhalte in der Variablen "crash" ablegt. Zumindest sieht man - wenn man mittels UNSETENV den Wert löscht -, ob er älteren Datums ist oder tatsächlich bei jedem Startversuch neu gesetzt wird. Sinnvoll verwenden kann man ihn nur mit einem Debugger oder den Linker-Protokollen des verwendeten Kernels.
