Danke für die Anleitung, hat funktioniert
Ich muß Abbitte leisten, das hat nichts mit Ungeduld Deinerseits zu tun, das ist ganz simpel wirklich ein krasser Fehler und Du warst der Erste, dem er sauer aufgestoßen ist.
Das zeigt mir einmal mehr, daß QS bei AVM offenbar nicht mehr üblich ist, ganz zu schweigen von Labor-Versionen für 7390i, in denen die "Öffentlichkeit" ihnen auf die Sprünge hätte helfen können.
Bitte nicht falsch verstehen, ich weiß auch, daß es keine fehlerfreie Software gibt. Aber der QS bei AVM sollten all die Informationen, die wir uns hier erst mühsam mit forensischen Mitteln erarbeiten müssen, von Anfang an zur Verfügung stehen. Damit sind - anhand der vorgenommenen Änderungen - dann auch die besonders intensiv zu testenden Stellen der Firmware bekannt und wenn dann ein solcher Fehler durchrutscht, zeugt das in meinen Augen nicht von gründlichem Vorgehen.
Um wirklich jede Fehlerquelle auszuschließen (z.B. eine vorzeitige HTTP-Anfrage an den ctlmgr durch eine Ajax-basierte Abfrage im Hintergrund), habe ich einen USB-Stick mit ext2 formatiert, dort das Plugin an der richtigen Stelle gespeichert und die Box (ohne Außenverbindungen, also ohne jeden Netzwerkverkehr) neu gestartet. Nachdem sich dann die Box "beruhigt" hatte (ca. 3 Minuten), habe ich die LAN-Verbindung wieder hergestellt und das GUI aufgerufen. Dieses war bereits bei diesem Aufruf komplett in Deutsch, das Eventlog wurde jedoch - genau wie bei peter48 - in Englisch angezeigt. Das läßt für mich den Schluß zu, daß die Sprachdatei auch ohne Zugriffe auf das GUI oder das Eventlog bereits beim Start des ctlmgr geöffnet wird und dort - solange er läuft - niemals wieder ein Schließen-/Öffnen-Zyklus stattfindet.
So etwas sollte - wenn man diesen Plugin-Mechanismus erst in dieser Firmware-Version als CONFIG_PLUGINV2 neu aus der Taufe gehoben hat und daher weiß, daß dieser Teil gezielt zu testen ist - nach einer QS, die den Namen auch nur ansatzweise verdient, nicht mehr passieren ... da habe ich absolut kein Mitleid. Wenn man dann noch bedenkt, wie lange es garantiert wieder dauern wird, bis AVM eine fehlerbereinigte Version veröffentlicht (ich weiß, diese ist erst etwas mehr als eine Woche alt, man kann aber aus früheren Erfahrungen abstrahieren), dann finde ich das besonders ärgerlich.
Selbst wenn AVM sich nur eine kleine (bezahlte, soviel Geld sollte wohl in der Kriegskasse sein, daß man das nicht für "lau" erwarten wird - das ist bei den deutschen Versionen für mich schon ein Witz, wie AVM da die Kunden einspannt und dann anschließend auch noch verarscht, indem nur sehr selektiv auf gemeldete Fehler überhaupt reagiert wird) Schar von Beta-Testern (wenn man dafür zahlt, meinetwegen auch nach Qualifikation gesiebt, damit da nicht mehr Aufwand als Nutzen entsteht) "halten" würde, käme da in meinen Augen mehr bei heraus, als bei der derzeitigen Vorgehensweise. Wenn aber AVM wie alle anderen immer mehr auf "Bananen-Firmware" setzt, worin unterscheiden sie sich dann eigentlich noch von anderen Herstellern ? Rechtfertigt das dann noch den durchaus saftigen Aufpreis, den man für AVM-Hardware zu zahlen hat ?
Hier höre ich jetzt lieber auf, das wird wieder OT ... aber ich mußte es einfach mal wieder loswerden, da AVM wohl nie begreifen wird, daß auch die Zeit, die ein Kunde investieren muß (Haben Sie schon mal ein Werksreset gemacht ?) - in diesem Falle eben, um deren Fehler einzugrenzen - ihren eigenen Wert hat. Im Moment bin ich jedenfalls mal wieder richtig angep***t ...
:motz:
EDIT: Wenn ich mir dann noch die /etc/samba_control in der 7390i anschaue, rücke ich auch wieder von der Einschätzung ab, AVM hätte den nmbd absichtlich nicht in die Firmware eingebaut. In dem erwähnten Skript wird jeder Sch*** generisch behandelt, auch die Sonderfälle für Puma6-Boxen, wo der Samba-Teil auf dem ATOM-Kern läuft und die Samba-Konfiguration erst zwischen den beiden "VM" (ich nenne sie mal so) synchronisiert werden muß. Da würde ich bei der Möglichkeit, daß der nmbd in der Firmware nicht vorhanden sein könnte (wie es jetzt der Fall ist), dann wenigstens eine Abfrage vor dem Start einer solchen optionalen Komponente erwarten, davon ist aber weit und breit nichts zu sehen. Wenn dann also auch noch der fehlende nmbd nur ein weiterer Fehler in der Firmware ist, unterstreicht das meine oben geäußerte Meinung nur noch ...
EDIT2: Kommt oben vielleicht falsch rüber ... die fehlende Berücksichtigung des nmbd erfolgt (abgesehen vom kill) nicht direkt in /etc/samba_control, sondern erst in /bin/inetdctl ... da wird keine Rücksicht auf den fehlenden (oder "optionalen") nmbd genommen.
