Da wurde wohl beim Versuch mit "eva_to_memory" eine Datei mit der Länge 0 angegeben (der Fall, daß die angegebene Datei gar nicht existiert, wird im Skript getestet) ... das Skript berechnet jedenfalls den verbleibenden Speicher entsprechend. Mehr kann man ja leider nicht sehen ... weder wie die Datei heißt, noch wo sie liegt oder welche Eigenschaften ("ls -l" könnte genauso hilfreich sein, wie ein "stat") sie hat.
Die vorbereiteten Erste-Hilfe-Images sind in ein eigenes
Repository ausgelagert worden (damit man das Repository auch als (kleineres, nämlich < 1 MB) ZIP-File laden kann), dieses wurde als "submodule" wieder
eingebunden. Normalerweise sollte es damit beim Klonen automatisch aktualisiert werden, ansonsten helfen die entsprechenden Git-Kommandos (und nein, ich werde diese hier nicht noch einmal beschreiben) ... auch dann, wenn man die ZIP-Version lädt und entpackt. Das "Problem", daß ich im ersten Anlauf für das Einbinden die SSH-URL verwendet habe (die nur mit passendem SSH-Key funktioniert), wurde auch bereits vor sieben Tagen korrigiert.
Die
Änderungen am "eva_discover" und das Erfordernis der Angabe von passenden Parametern sind inzwischen sooo alt (und mehrmals von mir beschrieben), daß mir am Ende nur bleibt, Dir dazu zu gratulieren, daß Du es jetzt auch bemerkt hast - oder war auch das nur die Wiederholung bereits "bekannter Probleme"?
Auch die
Änderungen an den Dateinamen bei den Skript-Dateien in "toolbox" haben bereits vier Monate auf dem Buckel (ich habe es etwas übersichtlicher gestaltet und "Ordner" zum Ordnen eingesetzt, weil sie dafür vermutlich gedacht sind) ... warum Du die Dateien nicht findest (bzw. wo und wie Du sie überhaupt gesucht hast), konnte mir meine Glaskugel aber leider auch nicht verraten - wobei ich der ohnehin nicht mehr traue, denn sie konnte mir bei der Frage im letzten Abschnitt des ersten Absatzes ja auch schon nicht helfen.
Sollte es irgendwo eine alte Beschreibung meinerseits geben, die nunmehr entsprechender Korrekturen bedarf, wäre ein Hinweis mit Angabe des entsprechenden Threads/Beitrags im IPPF hilfreich. Es wird sicherlich auch Leute geben, die diese Dateien trotzdem noch finden, denn die Pfade in den anderen Skript-Dateien, welche diese "Hilfsdateien" benutzen wollen, sind ja auch entsprechend angepaßt (sieht man dann beim Blick in diese Dateien) und auch ein "find"-Kommando wäre sicherlich innerhalb der Dateistruktur fündig geworden ... der direkte Zusammenhang zwischen dem englischen "find" und dem deutschen "finden" ist ja auch nicht der pure Zufall.
Leider habe ich meine eigene Policy ja nie zu 100% durchgehalten, Beschreibungen nur
ein einziges Mal und an
einer einzigen Stelle zu verfassen ... da kann es schon sein, daß es veraltete Beschreibungen gibt. Das ist dann der Nachteil des "Nettseins" ... es wird recht unübersichtlich oder arbeitsintensiv (und merkwürdigerweise immer für den Antwortenden und andere Suchende, seltener für den Fragesteller).
Wenn solche Beschreibungen "aus meiner Feder" dann auch noch aus der Xenforo-Zeit des Boards stammen (seitdem funktionieren nun mal nicht mehr alle Formatierungen, die zuvor in vBulletin nutzbar waren und auch die Länge eines Beitrags ist nunmehr auf 50.000 Zeichen begrenzt, was das nachträgliche Ändern von Beiträgen, die vor der Einführung dieses Limits verfaßt wurden, unmöglich macht, sofern sie den Wert überschreiten), dann bin ich gerne bereit, über entsprechende Korrekturen nachzudenken - sofern man mir diese Stellen (in vernünftiger Form) aufzeigt.
Ansonsten gehört es für mich zum "kleinen Besteck" beim Suchen, daß man Ergebnisse in der umgekehrten Folge ihrer Aktualität auswertet und dann ergibt sich der Effekt automatisch, daß die neuesten Änderungen zuerst zur Kenntnis gelangen - es wäre in meinen Augen auch nicht zielführend, künftig auf weitere Änderungen zu verzichten, nur weil es früher mal anders beschrieben wurde.
Im Gegensatz zu Beschreibungen in einer eigenen Site (welche ich absichtlich nicht betreibe) werden ältere Beiträge in einem Bulletin-Board nun mal immer irgendwie von neuen Entwicklungen überholt ... aber man macht ja AVM auch keine Vorwürfe, daß die Handbücher für Versionen vor 06.5x nicht mehr zur aktuellen Firmware passen und auch die Beschreibungen im IPPF für das Flashen von Firmware über MTD0/MTD1 wurden ja (leider) nicht alle überarbeitet ... obwohl auch diese für neuere Modelle nicht mehr zutreffen. Du wirst also sicherlich nicht von mir jetzt erwarten, daß ich (proaktiv) alle alten Beschreibungen auch noch anpasse, wenn ich irgendeine kleinere Änderung vorgenommen habe ... zumal ich diese Änderungen in den meisten Fällen auch noch in einem IPPF-Beitrag erwähne oder gar erläutere.
Wenn jemand sich berufen fühlt, eigene Beschreibungen für
alle Änderungen meinerseits zu verfassen, kann ich ihn oder sie nur dazu ermutigen ... eine "Verpflichtung" meinerseits, nach jeder Änderung alle bisher verfaßten Beiträge auf ihre fortdauernde Gültigkeit zu prüfen (und jede, aber auch wirklich jede Stelle zu korrigieren), besteht jedenfalls nicht. Alles, was ich schreibe und anderen zur Verfügung stelle, ist "AS IS" ... steht so auch in der Lizenz, die anderen das Recht
zur Benutzung einräumt.
----------------------------------------------------------------
Wahrscheinlich hapert es wieder an dem "Üblichen" socat netcat und 150tausend abhängigen Paketen
Ja, das ist wahnsinnig unübersichtlich, wenn
ein Skript
eine passende Shell und
ein weiteres Programm benötigt ("socat"
und "netcat" sind es ja nur dann, wenn man auch
zwei Skripte benutzen will), welches vielleicht nicht automatisch auf jedem Linux-System installiert ist, aber mit wenigen Zeilen installiert werden kann und die bisher aufgetretenen Probleme dann auch noch ausführlich beschrieben sind.
Die 150k Pakete, die ansonsten noch benötigt werden, bilden dann vermutlich das Linux-OS ... oder was meinst Du da genau? Wäre Dir ein C-Quelltext, bei dem dann die komplette Build-Umgebung vorhanden sein muß (vom Compiler bis zu den passenden Header-Files samt aller Abhängigkeiten) lieber? Wenn ja, schreib' Dir einen ... genau deshalb stelle ich ja nicht nur "Code" oder eine "Anleitung" zur Verfügung, sondern bemühe mich auch noch, dessen Funktion und ein paar Zusammenhänge (im Rahmen meiner bescheidenen Möglichkeiten) zu beschreiben.
Manchmal (aber nur manchmal) plagt mich aber auch nur die Frage, warum sich manche Leute es dann überhaupt noch antun, diese Skript-Files benutzen zu wollen, wenn das alles so furchtbar ist. Funktioniert es bei Dir nicht, benutze es einfach nicht oder gewöhne Dir
rein sachliche Fragen (und der zitierte Text gehört für mich nicht in diese Kategorie) und einen angemessenen Umgang miteinander bei Deinen "Fehlermeldungen" an und dazu gehört es dann auch, daß Du einmal gegebene Antworten und erläuterte Standpunkte akzeptierst und nicht ständig aufs Neue versuchst, da irgendwie "zu bohren" ... hier offenbar wieder beim Thema "Linux-Distribution".
Wie und womit Du Deinerseits "Freetz" benutzt, hat (im räumlichen Sinne) keine tangentiale Beziehung zu meinem Gluteus Maximus ... welche Voraussetzungen für den (bei vielen merkwürdigerweise deutlich reibungsloseren) Einsatz der Angebote(!) aus dem YourFritz-Repository erfüllt sein müssen bzw. wie man diese herstellt oder was man ggf. an den Skript-Dateien ändern muß, ist hinreichend thematisiert. Ich weiß ja nicht, woher Du den "Anspruch" ableitest, daß ein und dieselbe Linux-Installation bei Dir sowohl für Freetz als auch für die YourFritz-Skripte passen müßte ... ich leite daraus jedenfalls nicht für mich die "Verpflichtung" ab, meinerseits nun auf einem Ubuntu-System zu arbeiten und zu entwickeln, nur weil Freetz sich mehr für Debian-basierte Distributionen erwärmen kann als für andere.
Gewöhnst Du Dir das Provozieren nicht ab, landest Du wieder auf der "Ignore"-Liste - dafür ist mir meine Zeit dann am Ende doch zu schade und die Hoffnung auf "Einsicht" kann ich wohl ohnehin begraben. Auch habe ich keine Lust mehr, mich im Nachgang darüber zu ärgern, daß ich mich wieder einmal zu einer Reaktion auf solche Provokationen "verleiten" ließ ... damit habe ich dann wieder den heutigen Nachmittag zu kämpfen.
