Scheint das gleiche Problem zu sein, wie es Mikebatt [...] beschreibt.
Dann sollte man es ja lösen können, denn der Beitrag #169 im verlinkten Thread strotzt ja nur so von Fehlern bei der Ausführung/Anwendung der verschiedenen Kommandos. Das sieht ja dort eher so aus, als hätte jemand nur die CODE-Blöcke aus anderen Beiträgen gelesen und (relativ wahllos) angewendet - egal, ob die dort aufgeführten Kommandos zum verwendeten Programm paßten oder nicht. Schon die Frage, ob man nun mit oder ohne "quote" ein Kommando aufrufen sollte, stellt sich ja eigentlich nicht bzw. ist eigentlich nichts, was man "durch Probieren" ermitteln müßte, wenn man die Erklärung dazu verstanden hat.
Ansonsten steht die Antwort/Reaktion auf die Feststellung/Frage (aus vorhergehenden Beiträgen in diesem Thread), ob da nun irgendeine Security-Suite unter Windows installiert war oder nicht, immer noch aus ... solange die fehlt, weigere ich mich einfach, über mögliche Probleme mit den PowerShell-Skripts oder irgendeiner anderen Software von mir auch nur nachzudenken. Auch wenn es immer wieder Nutzer gibt, die das besser wissen wollen (womit ich nicht sagen will, daß das hier auch der Fall sein MUSS, denn dazu gab es ja gar keine Reaktion), zeigt doch die Erfahrung aus diversen anderen Fällen (die man auch hier im IPPF nachlesen kann), daß häufig diese "Sicherheitssoftware" selbst dann noch die Ursache eines Problems darstellt, wenn sie angeblich deaktiviert wurde. Die Fälle, wo es nach der Deinstallation solcher Programme dann plötzlich doch funktionierte, sind jedenfalls hier im Board nachzulesen. Daher:
Ohne die definitive (und ungelogene!) Aussage, daß außer den Standardkomponenten von Windows (Firewall + Defender) nichts aktiv ist, lohnt es sich gar nicht, sich mit einem Problem in dieser Richtung zu befassen.
Die gezeigten Kommandos (mit dem "SetEnvironmentVariable" für "firmware_version" und "linux_fs_start" ohne neuen Wert) tragen aber (für mich) auch hier nicht unbedingt dazu bei, eine eingehende "Lektüre" der bereitgestellten Anleitungen wahrscheinlich erscheinen zu lassen ... zumindest dann nicht, wenn die "Nachfragen" dazu (selbst wenn sie vielleicht nicht immer als solche
zu erkennen sind) irgendwie ungehört zu verhallen scheinen -
irgendeine Reaktion sollte man ja erwarten können und ich bin nicht der Überzeugung, daß diese lauten sollte: "Das Gerät ist schuld." (zumindest nicht a priori) und man müsse nun versuchen, auf dem nächsten Weg zu scheitern. Schlauer wäre es (immer nur in meinen Augen, ich will das nicht als "allgemeingültig" verstanden wissen), wenn man die Ursachen der Probleme erkundet, anstatt beim nächsten Lösungsansatz dann an genau denselben Problemen ebenso Schiffbruch zu erleiden.
=========================================================================
Bei der Ausführung von "build_tffs_image" stellt sich die Frage, wie die (Skript-)Dateien auf das verwendete System gelangt sind. Das Skript ist auf die Existenz des Symlinks zu "yf_helpers" im aktuellen Verzeichnis angewiesen:
https://github.com/PeterPawn/YourFritz/blob/master/tffs/build_tffs_image#L23 und wenn dieses Skript gefunden werden kann (weil der Symlink auf ein Verzeichnis mit dem Inhalt von "scriptlib" aus dem Repository zeigt und darin auch noch die benötigte und erwartete Dateisystemstruktur vorliegt - nämlich das Unterverzeichnis "functions" mit den einzelnen Dateien), dann sollte das Einbinden der Funktionen auch möglich sein.
Wenn das nicht der Fall ist (wie man es hier wohl sehen kann), liegt zunächst mal die Vermutung nahe, daß da eben nicht das
gesamte Repository geklont bzw. "kopiert" wurde. Das muß allerdings auch gar nicht so sein, jedoch sollte man dann schon selbst dafür sorgen, daß die "scriptlib" so funktionieren
kann, wie das in ihrem eigenen Verzeichnis beschrieben wurde von mir (u.a. wäre eine korrekt gesetzte Variable "YF_SCRIPT_DIR" dann schon hilfreich).
Erst wenn man das jeweils befolgt hat (und es mit entsprechenden Ausgaben der "Prüfkommandos" belegen kann - immerhin kann man mit der Variablen "YF_HELPERS_DEBUG" ja eine recht ausführliche Protokollierung aktivieren und das wurde von mir auch entsprechend dokumentiert:
https://github.com/PeterPawn/YourFritz/tree/master/scriptlib), macht es (auch hier, wie oben bei den Windows-Versionen) irgendeinen Sinn, sich an eine "Fehlerprognose" zu machen ... bis dahin ist die einfachste Erklärung (Benutzerfehler) auch die wahrscheinlichste und in der überwiegenden Mehrzahl der Fälle eben auch die richtige.
Das soll nicht ausschließen, daß auch in den Skripten noch Fehler stecken ... aber beim Befolgen der "Anleitungen" (und die sollten für die Verwendung von "YourFritz" als Repository eigentlich immer auch das Klonen direkt von GitHub beinhalten) stellte sich schon bei mehreren Anwendern dann das gewünschte Ergebnis ein und so sollte die erste Vermutung bei einem Problem eben immer die eigene falsche Verwendung sein (zumindest, bis man das definitiv ausschließen kann). Das ist hier ja offensichtlich "beherzigt" worden (jedenfalls lese ich den Schluß von #128 so) und daher gibt es von mir auch noch einmal diese - eher umfangreichere - Antwort.
