Da macht dann offenbar die Dateisystem-Erkennung noch Probleme, wenn das eingesetzte blkid-Kommando irgendwelche Optionen nicht kennt. Ich schaue es mir demnächst an ... im Moment kann ich gerade nicht.
Das Pfad-Problem dürfte aber ein "Phantom-Fehler" sein, denn wenn da keine weiteren Änderungen erfolgt sind am AVM-Original, ist /sbin/blkid nur ein Symlink auf /usr/sbin/blkid und der Pfad im originalen Skript stimmt eigentlich.
Warum schreibe ich solche Sachen überhaupt (meistens) mit absoluten Pfaden und verlasse mich nicht einfach darauf, daß das System schon selbst die richtige Datei findet? Weil bei Existenz zweier
wirklich unterschiedlicher Versionen, die auch noch über komplett andere Aufrufoptionen verfügen, die Reihenfolge in der PATH-Variablen dann (solange es außerhalb der Busybox ist) entscheidet, welche Version gefunden und benutzt wird.
Am einfachsten wird es wohl wieder sein, einfach eine Busybox mit ins "bin"-Verzeichnis zu legen (habe ich ja für "patch" bereits gemacht, damit ist die jetzt vorhanden) und künftig alle etwas "hakeligen" Kommandos nur noch auf der Basis dieser Busybox aufzurufen (und notfalls eben zusätzliche Kopfstände im Skript-Code zu veranstalten, die mit einem anderen Binary nicht erforderlich wären).
Das verhindert dann die Abhängigkeiten von den im aktuellen Image enthaltenen Kommandos ... aber dann müßte/würde ich modfs auf die Behandlung von Versionen > 06.36 beschränken (also eigentlich sogar auf SquashFS4), weil die ganzen "regression tests" mit alten Images mir zu anstrengend sind in der Wiederholung. Am Ende habe ich eigentlich mehr Zeit in die ganzen Tests bei der 0.3.1 investiert (die Versionsnummer
im Skript passe ich an, danke für den Hinweis) als in das Schreiben, weil es so viele unterschiedliche Kombinationen gab (s. Tabelle in #1).
Das würde dann den Bruch der Kompatibillität mit Versionen vor 06.36 bedeuten und dafür ist es im Moment wohl noch zu früh, solange nicht alle (in hwrevs aufgeführten) Modelle die Weihen der 06.5x-Versionen erhalten haben. Immerhin gibt es die ja nun für die 7362SL, das ist schon mal ein Schritt weiter.
Daß der Inhalt von #1 inzwischen nicht mehr allzu übersichtlich ist, sehe ich ja ein ... aber mir fehlt auch die Zeit, das noch einmal "aufzuarbeiten". Am Ende wird es wohl auf eine etwas kürzere Version als README.md im GitHub (dann primär in Englisch und ggf. noch eine in Deutsch, wenn ich wirklich sehr viel Muße haben sollte) hinauslaufen anstelle irgendwelcher weiteren Änderungen/Hinweise in #1.
Wenn sich jemand berufen fühlen sollte, das Wesentliche/Aktuelle aus #1 ins IPPF-Wiki zu transferieren, lese ich gerne Korrektur für entsprechende Entwürfe (auch vor der "Veröffentlichung"), wenn der-/diejenige daran Interesse haben sollte.
Es gibt schon einen Grund, warum Developer eher selten die Nutzeranleitungen für ihre eigenen Elaborate schreiben (sollten) ... immerhin habe ich bei "modfs-Starter" versucht, die Fehler hier im Thread zu vermeiden; auch wußte ich natürlich im Sept.2014 nicht, wie sich das weiter entwickeln würde - damals dachte ich ja noch an eine Zusammenführung mit Freetz in irgendeiner Form.
EDIT: Ok, das mit dem "blkid"-Kommando ist wohl noch komplizierter ... das schaue ich mir noch genauer an. Womöglich bin ich da meinem eigenen "copy_binaries" aufgesessen, weil ich natürlich auf meiner Box mit modifizierter Firmware teste anstelle des AVM-Originals. Zwar versuche ich immer, mich von der Existenz der verwendeten Kommandos auch in "stock firmware" zu überzeugen, aber da steht ja eindeutig "not found" in der Fehlermeldung, damit ist natürlich die Symlink-Story Unsinn.
EDIT2:
Ne, mit dem Skript ist alles in Ordnung, das verwendete System zum Aufruf von "modfs" enthält offenbar Änderungen ggü. dem AVM-Original. In einer "ausgepackten" (unmodifizierten) Struktur der AVM-Firmware sieht das bei mir so aus:
Code:
113.06.51 $ find . -name "blkid" -exec ls -l '{}' \;
lrwxrwxrwx 1 root root 17 Feb 4 21:32 ./sbin/blkid -> ../usr/sbin/blkid
lrwxrwxrwx 1 root root 17 Feb 4 21:32 ./yaffs2/sbin/blkid -> ../usr/sbin/blkid
-rwxrwxrwx 1 root root 62672 Feb 3 16:37 ./usr/sbin/blkid
Da stimmt also meine oben aufgestellte Behauptung bzgl. des "blkid"-Kommandos und der Symlinks - außer beim Auspacken mit "extract_7490_new_filesystem" würde da bereits etwas durcheinander gebracht (das nur als mögliche andere Fehlerquelle, weil ich ein vorsichtiger Mensch bin und die Pferde ja immer direkt vor der Apotheke stehen).
Für die 06.50 gilt (bei mir) dasselbe:
Code:
113.06.50 $ find . -name "blkid" -exec ls -l '{}' \;
lrwxrwxrwx 1 root root 17 Dec 12 05:00 ./sbin/blkid -> ../usr/sbin/blkid
lrwxrwxrwx 1 root root 17 Dec 12 05:00 ./yaffs2/sbin/blkid -> ../usr/sbin/blkid
-rwxrwxrwx 1 root root 62672 Dec 8 13:50 ./usr/sbin/blkid
... es liegt also auch nicht daran, daß dort von der 06.50 auf die 06.51 "gearbeitet" wird.
Wo mir bekannt ist, daß es Probleme gibt, ist der Übergang von der 06.30 auf die 06.50 bei der 7412 ... da paßt das "blkid"-Kommando nicht und man sollte die 7412 erst mit der 06.50 aktualisieren und anschließend SIAB per EVA nachrüsten (wie ich es irgendwo beschrieben habe), wenn man dort "modfs" verwenden will mit dem "install"-Parameter. Das mache ich bei der nächsten Änderung wahrscheinlich gleich mit, das ist aber auch ein Punkt, der bei der Aufgabe der Kompatibilität mit Versionen vor 06.36 unter den Tisch fallen würde.
EDIT3 (last one here):
Das Herausstellen des Verweises auf #190 in #1 in rot war offenbar nicht ausreichend, ich werde noch einen entsprechenden Hinweis in #1 ganz am Beginn einfügen. Die "Verwirrung" mit "Debug" und "Protokollierung" tut mir ja leid ... da diese Protokollierung aber mit der Environment-Variablen "MODFS_
DEBUG" gesteuert wird, ist das (für mich zumindest) synonym (und hoffentlich bei einer Suche auch so zu finden, selbst wenn ich das jetzt nicht getestet habe).
