Laß uns diese Diskussion nicht wieder anfangen ... daß es hier kein Thread ist: "Wie bediene ich den 'vi' und wie kann ich auf der FRITZ!Box eine Datei 'custom_modscripts' bearbeiten?", ist mir persönlich sehr recht.
Ich meinte auch weniger die Leute, die sich trotz fehlenden Basiswissens unbedingt ihren Router modifizieren wollen (trotz der damit verbundenen Gefahren, man eröffnet ja - vor allem bei unsachgemäßem Vorgehen mit eigenen Diensten - auch wieder zusätzliche Angriffsmöglichkeiten), sondern die Probleme, die bei der Anwendung von "modfs" tatsächlich auftreten könn(t)en.
Wenn sich jemand um die Vermittlung von Standardkenntnissen zur Bedienung von Linux verdient machen möchte, habe ich damit auch kein Problem - aber es muß/soll eben nicht dieser Thread sein und (imho) es gibt eigentlich genug andere Stellen im Internet, wo das bereits ausführlich und in hoher Qualität (das reicht von der Verständlichkeit bis zur korrekten Wiedergabe von Fakten) erfolgt. Wenn sich jemand tatsächlich für so gut hält, daß er solche Angebote toppen kann, möge er das tun - ist er/sie aber schlechter, braucht es kein weiteres negatives Beispiel ... auch davon gibt es genug.
Und nein, man kann nicht einmal eine allgemeine Empfehlung solcher Quellen abgeben, weil die Eignung für eine bestimmte Person immer auch von deren Vorkenntnissen (und auch den Sprachkenntnissen) abhängt - nur falls jemand fragen wollte, wo man so etwas findet. Ansonsten gibt es häufig genug bei irgendwelchen Computerzeitschriften auch solche Linksammlungen oder andere Empfehlungen/Tests, auch dabei reicht die Zielgruppe von "beginners" bis zu "experts".
-Solange nicht klar wird, warum bei Dir der manuelle Aufruf der Skript-Datei das richtige Ergebnis liefert und das aber beim Aufruf über die Lua-Seite nicht mehr der Fall ist, weiß ich auch nicht, wie ich bei der Fehlersuche weiterhelfen soll.
Die einzige Idee, die ich hätte, wäre das Hinzufügen zweier Zeilen in der Datei "/usr/bin/guibootmanager" (das kann vor dem "case" am Ende der Datei stehen oder auch irgendwo am Beginn nach der ersten Zeile mit dem SheBang) - das darf aber erst dann erfolgen, wenn die Modifikationen bereits abgewandt wurden (außer man ändert gleich das "modscript").
Code:
exec 2>/var/media/ftp/bootmanager_$$.log
set -x
Dann wird bei jeder Ausführung (aka jedem Seitenaufruf der "reboot.lua") auf dem NAS-Speicher eine Protokoll-Datei (mit einer Nummer im Namen) erzeugt (wie deren Inhalt in etwa ausssieht, steht schon weiter oben) und die kann man dann über die NAS-Funktionen auslesen. Natürlich kann man das auch irgendwo anders ablegen lassen, dann braucht es aber wieder eine Shell für das Auslesen (inkl. C&P, wenn man es hier einstellen will).
Wenn man dann die Stelle des Fehlers gefunden hat und das betreffende Kommando leitet die Fehlernachrichten ins Null-Device, dann muß man dort diese Umleitung eben mal entfernen, wenn die Ursache des Fehlers nicht ins Auge springen sollte. Bisher vermute ich ja nur, daß der Mount-Vorgang fehlschlägt - an welcher Stelle das genau erfolgt, ist immer noch unklar und aus dem bereits bereitgestellten Trace-Log nicht zu ersehen, denn da lief das Skript ja ohne Probleme durch.
- - - Aktualisiert - - -
Die Frage in dem von Dir verlinkten Beitrag habe ich eher darauf bezogen, ob man die Abfrage bei AVM nach einer neueren Firmware auch für die in der inaktiven Partition installierte Version machen könnte (wenn da z.B. einmal die deutsche und einmal die internationale Version installiert wäre) - irgendwie geht es da ja die ganze Zeit um den neuen automatischen Update-Check und nicht um die Umschaltung zwischen den Systemen bzw. den "gui_boot_manager".
Da das mit der Prüfung nicht problemlos machbar ist, habe ich das allerdings erst einmal verworfen.
Die bisher beim "check_update" einfach zurate gezogene "jason_boxinfo.xml" ist dynamisch erzeugt (existiert also in der inaktiven Firmware nicht) und man müßte sich für die inaktive Partition die Datei selbst zusammenschustern bzw. die Werte in der aktuellen mit den abweichenden Angaben des alternativen Systems mischen - erst einmal zuviel Aufwand für zuwenige Anwendungsfälle, denn der Normalfall ist sicherlich die Verwendung nur einer (D vs. intl.) Version und da ist dann das Ergebnis so einer Abfrage für eine neuere und eine ältere installierte Version dasselbe.
Jedenfalls dann, wenn man nicht in einer Partition eine "inhouse version" und in der anderen eine offizielle hat. Wer das machen will (ich nehme die "inhouse versions" grundsätzlich nicht für die Box, höchstens mal zum Reinschauen), dem kann man auch von der Inhouse-Version aus (schließlich hat die SIAB) die manuelle Ermittlung der Versionsnummern mit einem passenden "juis_check"-Aufruf zumuten.
Abgesehen davon könnte die jason_boxinfo.xml vielleicht demnächst ohnehin verschwinden zugunsten der irgendwann (keine Ahnung, wann genau) neu eingeführten juis_boxinfo.xml mit anderer Aufteilung der Versionsnummer und ein paar mehr Angaben. Dann muß ich das "check_update" aber auch nur beim Dateinamen anpassen und das Thema unterschiedlicher "Brandings" (da rechne ich jetzt mal deutsche vs. internationale Version dazu) ist zwar beim Reboot eines, aber nicht bei der Prüfung auf Updates. Wobei auch hier die Verwendung der juis_boxinfo.xml gleich den richtigen Wert liefern würde, ob es sich um eine "inhouse version" handelt oder nicht - bisher setzt das mein "check_update"-Skript fix auf "nur öffentlich verfügbare Versionen" und prüft damit auch nur dafür - das will ich eigentlich auch nicht wirklich ändern.
