[Info] modfs - SquashFS-Image (AVM-Firmware) ändern für NAND-basierte FRITZ!Boxen

[darki2017]

@ PeterPawn : planst du in der nächsten Zeit ein Update von modfs bzgl. Telnet ?

gruß
darki

 

[eisbaerin]

Wie wäre vor dem Schreiben mal wenigstens die letzten Beiträge, insbesondere von PeterPawn zu lesen?
Und ganz insbesondere #1456!

 

[PeterPawn]

Ich fasse noch mal zusammen aus meiner Sicht:

Ich hatte ja für 07.00 Änderungen am "modfs" versprochen ... jetzt ist das aber schon 07.01 bei AVM. Bin ich jetzt noch an die damalige Aussage gebunden?

Ja ... ich mache noch ein "frisches" "modfs" (auf Basis des alten Codes und auch nur für die bisher unterstützten Boxen - an den Dateisystemformaten hat AVM ja nichts weiter geändert), wo Script und Patches an die 07.00 angepaßt sind (bei den Patches nur das, was Sinn ergibt bei der 07.00) und auch gleich andere Neuerungen eingebunden werden (z.B. die neuere Version des Boot-Managers, die inzwischen selbst in Freetz eingebaut ist, wenn der Benutzer das möchte - nur in "modfs" noch nicht).

Bei den Binaries für die Verwendung mit "modfs" bleibt es wohl erst einmal bei den statisch gelinkten für die alte uClibc ... die sollten ja auch mit dem anderen Kernel laufen und die C-Library interessiert sie (da sie eben statisch gelinkt sind) ohnehin nicht.

Ich habe nur im Moment das Problem, daß die HDD mit den (lokalen) Repositories langsam den Geist aufgibt und ich die gerade auf eine neue doppeln will (sind ja auch nicht immer dieselben lokalen Stände, wie diejenigen, die öffentlich verfügbar sind) - das "rsync" für die ganzen Partitionen läuft jetzt schon fast zwei Tage, weil die HDD halt immer mal Lesefehler hat, sie aber in der zig-sten Wiederholung dann doch noch zum Erfolg kommt - S.M.A.R.T rät inzwischen auch deutlich zum Austausch. Diese Lesefehler machen aber auch jedes andere "Arbeiten" mit dem System nervig, weil bis zum Erfolg oder Fehler einer Leseoperation eben mal 30 Sekunden und mehr vergehen können und in der Zeit steht das gesamte restliche System.

Erst wenn dieses Doppeln fertig ist, kann ich die HDD im internen Server tauschen und damit beginnen, meinen Freetz-Fork auf den aktuellen Freetz-Stand zu aktualisieren, um dann neue Binaries für 07.00 bereitstellen zu können. Das hat zwar mit dem "öffentlichen" "modfs" nicht direkt etwas zu tun (außer daß halt auch dieses Repository in demselben Verzeichnis wie alle anderen liegt), aber beim Test sollte natürlich auch bei mir ein benutzbares Image für die 7490 entstehen und dazu gehört nun mal ein "copy_binaries"-Skript, was auch tatsächlich etwas zu kopieren hat (in der richtigen Version für das "Zielsystem").

Bleibt also die Frage, was "die nächste Zeit" ist ... erste korrigierte Patches wird es vielleicht sogar noch heute geben (wobei ich die Liste von oben nach unten abarbeiten will und keine Präferenzen habe - höchsten aufwändigere Sachen dann schiebe, wenn ich es nicht gleich lösen kann) und damit - wenn Bedarf besteht - meinetwegen auch eine Version "0.5.0" als Beta o.ä., wobei ich dann vermutlich nicht jede Änderung hier kundtun würde - Änderungen am Repository kann man sich ja auch selbst auf GitHub ansehen bzw. dort das Repo "beobachten" und so von Änderungen Kenntnis erhalten. Auch freue ich mich über Feedback zu solchen Vorabversionen (wenn ich sie bereitstellen sollte), kann aber die Funktion nicht wirklich "garantieren" (das Wort "Garantie" ist hier auch nur im Kontext der Lizenzbedingungen verstehen). Ob ich die Datei zum Download auf yourfritz.de angepaßt habe, kann man dann auch durch Hash-Vergleich mit der alten feststellen.

Wann es eine "fertige" Version 0.5.1 (oder wie auch immer die Nummer dann sein wird) geben wird, kann ich nicht genau vorhersagen.

Die (fertigen) Images zum "Impfen" der 7490 mit Shell-in-a-Box sollten eigentlich auch noch mit der 07.00 funktionieren - falls jemand einen "Einstieg" suchen sollte. An der "rc.S" hat AVM da m.W. nichts geändert und damit sollte die "injection" auch bei der 07.00 noch klappen.

 

[PeterPawn]

Ich habe mal einen Zwischenstand als "modfs-0.5.0-beta.tgz" auf yourfritz.de abgelegt (und im "modfs"-Repo natürlich) - aber der Symlink "modfs.tgz" zeigt noch auf die alte Version. Man muß also das Kommando zum Download selbst anpassen ...

Was geht und was geht nicht?

Den Boot-Manager habe ich noch nicht angefaßt (der sollte aber weiterhin arbeiten) und die LED-Seite wird zwar im Menü eingebunden, aber bietet die "verzögert abschalten"-Option nicht an. Der Rest (außer den VPN-Verbindungen in der Übersichtsseite, die ich ja schon früher beschränkt hatte, weil dann bei einigen die Übersichtsseite gar nicht mehr ging) sollte funktionieren ... ich habe die Nutzung von NAS-Flash als temporäres Verzeichnis komplett abgeschaltet. Wer das trotzdem benutzen möchte, gibt ein "INCLUDE_NAND=1" zusätzlich als Environment-Variable beim Aufruf vor.

Beim Telnet-Zugang habe ich das zweigeteilt ... ein Skript installiert den Symlink für den "telnetd" und ein weiteres trägt den Start des "telnetd" in die "S85-apps" ein. Für 07.00 müßte man also beide Patches anwenden lassen und dann läuft der "telnetd" eben immer mit. Wer den irgendwie anders starten kann oder eine ältere FRITZ!OS-Version installieren möchte, der kann auf "mod_telnet_start" dann eben auch verzichten.

Damit diese beiden Skripte für den "telnetd" auch nacheinander abgearbeitet werden, habe ich die passend benennen müssen - dieser Aktion ist das alte "mod_enable_telnet" zum Opfer gefallen. Stattdessen heißen die beiden jetzt "mod_telnet_enable" und "mod_telnet_start" - wer eine "custom_modscripts" verwendet, muß ggf. die Dateinamen darin selbst anpassen. Und man sollte die ältere Version eben auch nicht mit der neuen "mischen" ... dann gäbe es drei Telnet-Patches.

Beim Versuch, unter 07.00 mit der "alten" BusyBox aus dem "modfs"-Tarball die nächsten Änderungen auszuführen, kriegte ich erst mal einen "Bus Error" ... keine Ahnung, was da konkret falsch lief und ob das ein permanentes Problem ist. Ich wollte es nur "angemerkt" haben, daß es nicht selbstverständlich ist, daß "modfs" auch aus einer Version 07.0x erfolgreich ausgeführt werden kann.

Die zwei "offenen" "modscripts" (den neuen Boot-Manager und die LED-Seite) mache ich irgendwann morgen (bzw. heute) - wann das mit neuen Binaries was wird, weiß ich noch nicht.

 

[eisbaerin]

aber bietet die "verzögert abschalten"-Option nicht an.

Dann lösche mal einfach alles was du vor Zeile 83 alt, 75 neu in der led_display.lua änderst, dann geht es sofort. Bei mir geht es
Ich habe nie verstanden wozu das gut sein soll.

AVM hat in dem ersten Bereich einiges geändert.
Warum ändert AVM dort, wenn es normalerweise sowieso keiner sieht, weil es ja nicht genutzt wird?
Oder gibt es einen LED-Parameter wo man das Menü einschalten kann?
Aber das hatte ich IMO schon mal geschrieben.

"Bus Error"

Ja, da habe ich mich auch schon gewundert.
Den bekomme ich z.B. auch, wenn ich eine FB7490-07.01er busybox auf einer FB7580-59660 starten will.
Hatte ich versucht, um zu sehen, ob der telnetd noch enthalten ist.

Aber die "offiziellen" busyboxen laufen dagegen überall und sind wesentlich neuer (1.28.x gegen 1.24.x) und umfangreicher:
https://busybox.net/downloads/binaries/1.28.1-defconfig-multiarch/busybox-mips

Und da du dich ja wesentlich besser mit Linux auskennst, kannst du dir sogar schon eine 1.29.3 bauen.

Warum AVM immer noch bei 1.24.2 (von ca. 2016) bleibt ist mir schon lange ein Rätsel.
Daß beim Aufruf:
BusyBox v1.24.2 (2018-04-17 12:45:33 CEST)
ein anderes/falsches Jahr angezeigt wird liegt IMO nur an der verspäteten Compilierung.

 

[PeterPawn]

Ich habe nie verstanden wozu das gut sein soll.

Wenn Du die ersten beiden "hunks" in dem Patch für die "led_display.lua" meinst ... die sorgen dafür (die Zeilen mit den zusätzlichen Leerzeichen mal außen vor, das hatte ich gar nicht beachtet/gesehen - so etwas würde ich nicht absichtlich extra patchen, da hatte ich nur die "diff"-Ausgabe in die Datei kopiert), daß bei der ersten Anzeige der Seite auch die aktuelle Einstellung ausgewählt ist und die Seite damit auch als "Display" herhalten kann.

Wenn Du diese beiden Teile bei Dir entfernt hast, startet die Anzeige der Seite immer mit "LED-Anzeige an", egal was wirklich gerade eingestellt ist.

---------------------------------------------------------------------------------------------------------

Wenn statisch gelinkte Binaries nicht problemlos austauschbar sind, gibt es also doch genügend Unterschiede in den Kernelversionen, daß man die nicht "cross-over" benutzen kann. Das heißt dann, ich muß mir für ein vernünftig lauffähiges "modfs" unter Kernel 3.10.107 (ich hoffe mal, daß wenigstens die VR9-Modelle alle dieselbe Kernel-Revision verwenden) etwas einfallen lassen - es braucht zumindest zwei verschiedene (statisch gelinkte) BusyBox-Versionen und dann stellt sich die Frage, wie man das am besten macht.

Packe ich beide von Beginn an in den Tarball, wird der Download größer - aber ich kann einfach durch den passenden Symlink (anhand von "uname -r") die zu verwendende BusyBox auswählen. Die Alternativen wären unterschiedliche Tarballs schon auf yourfritz.de oder das dynamische Nachladen der passenden BusyBox (wobei das ggf. auch noch andere Programme betrifft, z.B. das "openssl" für die Image-Prüfung). Die letzte Variante erfordert dann eine aktive Online-Verbindung bei der Verwendung von "modfs" ... für diejenigen, die einfach nur "modfs update" aufrufen, sicherlich keine Hürde - aber es macht die "Offline-Benutzung" kaputt.

Ich werde also wohl auf die Download-Größe pfeifen und die Versionen für beide Kernel bzw. beide C-Libraries dazupacken.

Aber meine HDD synchronisiert immer noch ... an eine Aktualisierung des Freetz-Forks ist immer noch nicht zu denken.

---------------------------------------------------------------------------------------------------------

Dasselbe Problem habe ich auch bei meinen "custom images" dann wieder ... auch da sind ja genug statisch gelinkte Programme drin (von Shell-in-a-Box bis dropbear), bei denen dann die C-Library eher schlecht zum Kernel paßt. Wer also auch weitere "Zusatzprogramme" einbinden läßt, sollte das erst dann machen, wenn er die passenden Binärdateien für die 07.0x hat.

Da ist die Feststellung, daß beim Übergang auf die 113.07.01 die Einstellungen tatsächlich "konvertiert" werden, dann nur noch eine Randnotiz - vor dem ständigen Wechsel zwischen pre-07.0x- und 07.0x-Versionen würde ich auch warnen ... jedenfalls solange man dabei nicht tatsächlich auch die Einstellungen "im Block" mit austauscht.

 

[Rocky_1965]

Ich habe mit modfs-0.5.0-beta.tgz von 6.93 auf 7.01 ein Update gemacht. Telnet läuft jetzt auch.
Habe aber ein anderes Problem festgestellt. Meine Programme lassen sich nicht mehr starten, weder in RC.user noch Manuell.

-sh: /var/media/ftp/USB_DATEN/Fritzload/fritzload/bin/install.sh: Permission denied
-sh: /var/media/ftp/server/apache_bin: Permission denied

Kann mir jemand helfen. Hat vorher einwandfrei funktioniert.

 

[Micha0815]

Ich muss den Befehl auch immer erst suchen Quelle #1372

mount -o remount,exec /var/media/ftp/...

LG and may help

 

[PeterPawn]

@topversand:
Das ist das Mounten aller NAS-Volumes (jetzt auch des internen Flash-Speichers) mit "noexec"-Option. Das ist für "normale Benutzer" deutlich sicherer und ich bin AVM dankbar, daß es jetzt auch für den internen Flash gilt (für die USB-Volumes war das schon vorher so).

Aber das ist auch recht einfach wieder herausgepatcht - wenn der Benutzer es wirklich will. Ich werde wohl dafür eine weitere Modifikation zur Verfügung stellen - aber getrennt nach "USB" und "NAND", weil man nicht gleich alles auf einmal "aufmachen" muß.

 

[eisbaerin]

aber getrennt nach "USB" und "NAND"

Habe und nutze ich schon lange.
Ich habe mich ja auch schon lange und ausgiebig vorbereitet auf die FW 07.xx:
mod_nas_without_noexec
und
mod_usb_without_noexec

Wenn du willst... gebe ich sie dir gerne.
Aber bitte ohne langfristige Formulare und anderes.

 

[Rocky_1965]

Ich muss den Befehl auch immer erst suchen Quelle #1372

mount -o remount,exec /var/media/ftp/...

LG and may help

Vielen Dank läuft jetzt alles. Habe den Befehl vorerst in die RC.user eingetragen.

 

[PeterPawn]

Es gibt zwei Möglichkeiten (das hat sich ja nicht geändert, sorry):

1. Jemand stellt eigene Skripte zur Verfügung als "user contributed content" ... es ist bekannt, wie das dann aussehen sollte, denn das Thema hatten wir für die 7412 und die Online-Zähler dort ja auch schon.
2. Ich baue es selbst (mit allen Rechten bei mir, die ich dann auch anderen überlassen kann) - zumal die Patches ja nicht wirklich umfangreich sind (insgesamt sind es - für beide - sechs Stellen) und ich die ohnehin auch für mich selbst schon im Einsatz habe (halt ohne pre- und postcheck, was ich noch dazubasteln muß).

Aber da ich ohnehin noch ein paar weitere Anpassungen erstellen will/muß, nehme ich gerne noch weitere "Wünsche" (oder Vorschläge) für Patches entgegen, solange die sich in angemessener Zeit umsetzen lassen.

Wer eigene öffentliche Schlüssel für das Signieren von Images einbauen lassen will, macht das - m.E. am Besten - dann über "copy_binaries" ... wenn man dort unterhalb von "etc" seinen eigenen Schlüssel als "avm_firmware_public_keyn" in das Image kopieren läßt (es wird ja nur ein TAR-File entpackt), braucht man kein gesondertes Skript dafür (das könnte ohnehin auch nur eine Datei mit festem Namen als Quelle nehmen, weil interaktive "modscripts" nicht vorgesehen sind).

 

[eisbaerin]

Na, dann erfinde das "Fahrrad" eben jedes mal neu.
Ich wollte dir ja nur helfen etwas Zeit zu sparen, für Scripts, die ich schon längst gemacht habe.

Aber wer nicht will, der hat schon.

### Zusammenführung Doppelpost by stoney ###

denn das Thema hatten wir für die 7412 und die Online-Zähler dort ja auch schon.

Nur komischerweise wurde genau dieses Thema (counter in der 7412) ohne Rückfrage und ohne (was wolltest du (PeterPawn) da eigentlich alles wissen?) von er13 einfach ins freetz übernommen und ich habe mich dafür bedankt.
Ich weiß bis heute nicht warum bei dir das alles so kompliziert ist.

 

[PeterPawn]

Noch mal deutlich ... erstens habe ich die auch schon und wenn Du da tatsächlich etwas mit pre- und postcheck gemacht hast (das habe ich tatsächlich nicht getan), muß ich das immer noch unter Berücksichtigung verschiedener Versionen korrekt umsetzen. All diese Informationen (von welcher bis zu welcher Version von AVM das funktioniert und zwar so, daß tatsächlich nicht zweimal dieselbe Änderung angewendet wird) fehlen nun mal von Dir ... und daß es durchaus sehr unterschiedliche Wege gibt, eine solche Änderung auszuführen (u.a. über "patch" oder eben auch über "sed"), dürfte auch bekannt sein. Ich selbst habe gerade erst eine Änderung (die in "mod_default_show_mac") von "patch" auf "sed" umgestellt, weil das nach den jüngsten Änderungen von AVM an der "/usr/www/avm/net/net_overview.js" einfacher war, als zwei verschiedene Patches zu verwenden.

Ein Patch braucht eben immer irgendeinen "Anker", an dem er festmachen kann (wenn man das nicht ausschließlich auf Zeilennummern stützen will, was noch viel gefährlicher ist) im alten "Text" ... wenn es dort keine Gemeinsamkeiten in älteren Versionen gibt (und es ist eben lange nicht so, daß ich alle Patches nur noch auf 07.0x ausrichten möchte, dann hätte ich die bisherigen Änderungen auch leichter haben können und einfach getrennte "modfs"-Versionen bereitstellen können), die dann auch für eine gemeinsame Lösung sprechen, muß man das ohnehin überdenken.

Und das ist auch die eigentliche "Arbeit" bei so einem (kompletten) Patch ... wie gesagt, die vier Stellen in der "udev-mount-sd" bzw. der "S15-filesys" sind im Handumdrehen gepatcht (das ginge notfalls sogar "ohne Kontrolle"). Der eigentliche Aufwand steckt in der Erkennung, ob der Patch schon angewendet wurde, ob er ggf. nicht nötig ist und wenn er angewendet wurde, ob das auch zum gewünschten Ergebnis führt - beim "patch" kriegt man z.B. keine Rückmeldung, wie man ja an "mod_leddisplay" im Moment noch sieht, wo die "Änderung" nur am Vorhandensein des entsprechenden Menüpunktes festgemacht wird und der zweite Patch in die Hose geht.

Wenn Du das alles tatsächlich gemacht hast, verstehe ich nicht, warum Du die "letzten Schritte" nicht auch noch machen willst und Deine Frage, warum das mit dem Online-Zähler von @er13 einfach so in Freetz übernommen werden konnte, solltest Du vielleicht ihm stellen. Ich habe jedenfalls keinerlei Bock auf eine erneute Diskussion dieser ganzen Angelegenheit und vielleicht reicht Dir als "Denkanstoß" ja schon der Hinweis, daß es bei Freetz für "precheck" und "postcheck" gar keine Verwendung gibt (da wird ja immer eine originale AVM-Firmware "aufs Neue" modifiziert und die Frage doppelter Änderungen stellt sich dort gar nicht erst).

Wenn Du der Meinung bist, daß auch nur "die halbe Arbeit" abgeliefert werden kann und mir den Rest aufs Auge drücken willst, dann mach das gefälligst selbst. Ich habe bisher von Dir noch nie per E-Mail diese Dateien in "zusammengefaßter Form" erhalten - trotz meiner ausdrücklichen Bitte und wenn sich @er13 hier hinstellt und sich die Dateien tatsächlich aus irgendwelchen IPPF-Beiträgen "ausgräbt" (nur nebenbei bemerkt auch vollkommen entgegen seiner sonstigen "Forderungen" an die Leute, die Änderungen für Freetz vorschlagen), dann ist das seine Sache.

Ich werde jedenfalls (schon aus (C)-Gründen) nicht hier hingehen und irgendwelche fremden Inhalte aus Beiträgen klauben und dann meinerseits "verbreiten" ... dafür verschwinden mir auch deutlich zu oft irgendwelche Texte oder Teile davon. Wenn das dann auch noch solche betreffen sollte, die mich zum "Raubkopieren" auffordern, bin ich am Ende der Dumme - und ich habe außerdem absolut keinen Bock, die Verantwortung für den Code von anderen zu übernehmen.

Wenn Du das erstellt hast, dann stehe auch dazu ... sich auf "zuviele Förmlichkeiten" herauszureden, nur weil ich eine passende Beschreibung, einen Lizenz-Text und den zu publizierenden Stand in einer "vernünftigen Form" erhalten möchte, bevor ich den selbst weitergebe, kann's ja wohl auch nicht sein.

Sieh Dir andere Projekte an, wo es solchen zusätzlichen Content gibt - die machen das auch nicht anders und ich sehe gar nicht ein, warum ich (als von dem Problem gar nicht Betroffener, weil mir die fehlenden Zähler absolut Wumpe sind) da meinerseits noch zusätzliche Zeit hineinstecken soll. Aber diese Diskussion gab es bereits und außer "@er13 hat das ja auch gemacht" gibt es m.W. keine neuen Argumente von Deiner Seite. Dieses eine neue Argument kann mich ebenfalls nicht überzeugen (warum steht oben) und solange es da keine "neuen Erkenntnisse" gibt, ist das Thema für mich durch.

Je länger ich hier auf diese Fragen erneut eingehen muß, um so weniger Zeit bleibt für "ernsthaftes Arbeiten".

 

[eisbaerin]

Ich habe jedenfalls keinerlei Bock auf eine erneute Diskussion dieser ganzen Angelegenheit

Ich auch nicht!!!
Entschuldigung, daß ich mich in deine Angelegenheiten eingemischt habe.
Ich werde dir NICHT weiter in diesem Projekt helfen, so gerne ich es auch möchte.

Anfragen, speziell an meine modscripte nehme ich gerne entgegen.
Sicherheitshalber vor PP nur per PN.

Wenn Du der Meinung bist, daß auch nur "die halbe Arbeit" abgeliefert werden kann und mir den Rest aufs Auge drücken willst, dann mach das gefälligst selbst.
Meinst du nicht, daß das etwas zu weit geht?
Ich möchte dir ja nur helfen, aber wenn das in solch einer Gegenaggressivität endet.
Na, ich weiß ja nicht.

 

[PeterPawn]

Meinst du nicht, daß das etwas zu weit geht?
Ich möchte dir ja nur helfen, aber wenn das in solch einer Gegenaggressivität endet.
Na ich weiß ja nicht.

Ich weiß nicht mehr, was das soll. Nochmal ganz, ganz unmißverständlich: Wer eigene Modifikationen anbieten möchte, die ich über das "modfs"-Archiv mit verteile, von dem erwarte ich folgendes:

• eine E-Mail mit dem kompletten Inhalt des Unterverzeichnisses für diesen "user contributed content" unterhalb des (extra dafür eingerichteten) "contrib"-Verzeichnisses im "modfs"
• zu diesem Inhalt gehört eine (nachvollziehbare) Aussage (für jeden Nutzer ersichtlich, also auch nicht "im Text" der E-Mail an mich), unter welcher Lizenz dieser Zusatz steht und ob/wie er genutzt, geändert und verbreitet werden darf
• ebenso gehört da eine Beschreibung dazu - deren Inhalt und Ausführlichkeit sind mir egal, aber der Autor (oder die Autorin, wobei ich diesen Gender-Quatsch nicht wirklich mitmache) und die Möglichkeit, diesen zu kontaktieren (weil ich auch nicht für "Nachfragen" dazu zur Verfügung stehen will - jedenfalls nur dann, wenn ich das auch möchte) sind das Minimum an Information - der Rest kann dann meinetwegen wieder in einer "modscript"-Datei stehen, denn die werden bei der Anzeige und Abfrage genauso behandelt, wie die von mir bereitgestellten

Wenn das schon "zuviel verlangt" sein sollte, rutsche mir in die Tasche ... die "Aggressivität" in meinen Worten hast Du Dir selbst zuzuschreiben. Ich habe das jetzt über fast zwei Jahre immer wieder erklärt - irgendwo habe ich Dir die "Fundstellen" zu dieser "Unterhaltung" zwischen uns auch mal aufgelistet, um das Bild wieder geradezurücken, wer da was wann an wen geschrieben hat und wer dann einfach nicht weiter darauf eingehen wollte.

Und wenn es jemand nicht schafft, mir das in der o.a. Form zur Verfügung zu stellen, dann ist schon das Zusammensuchen irgendwelcher Dateien hier im IPPF eine zusätzliche Arbeit, die der- oder diejenige mir aufhalsen will.

Ich habe noch nicht ein vernünftiges Argument zu lesen bekommen, warum meine "Forderungen" oben in irgendeiner Form übertrieben sein sollten ... das Einzige, was ich für derartigen Content noch machen will, ist das Auspacken (nach Malware- und "zip bomb"-Test) in das "contrib"-Verzeichnis unter einem passenden Namen für ein Unterverzeichnis (wer schlau ist und einen bestimmten (freien) Namen haben will, verwendet den als Verzeichnisnamen schon beim Einpacken) und das Berücksichtigen beim Einpacken der Tarball-Files für die Speicherung auf yourfritz.de.

Bei passender Lizenz für diesen Zusatz kann ich den auch zusammen mit meinen eigenen Dateien in das "contrib"-Verzeichnis im Repository einstellen ... wenn die Lizenz zur (A)GPL inkompatibel ist, bleibt es beim "Ausliefern" im Rahmen des Tarballs.

Das ist also alles sogar noch "sehr leicht" zu realisieren ... normalerweise würde man eher einen Pull-Request für das "modfs"-Repository erwarten, der dann den passenden Inhalt für das "contrib"-Verzeichnis enthält. Das ist hier allerdings nicht wirklich vonnöten und deshalb lasse ich mich auch zur Verwendung einer E-Mail "breitschlagen". Aber ich gehe keineswegs hin und klaube mir hier aus irgendeinem IPPF-Beitrag irgendwelche Dateien zusammen ... was würde man mir wohl erzählen, wenn ich anderen zumuten würde, die Dateien für die Verwendung von "modfs" aus einer CODE-Box hier im IPPF erst per "cat" oder "vi" auf der Box erstellen zu müssen, anstatt sie einfach per "wget" laden zu können?

Ich hab's echt satt, das jedesmal aufs Neue erklären zu müssen und dann wird es einfach ad libitum ignoriert ... nicht mal das "Vergnügen" einer echten Gegenrede mit plausiblen Argumenten wird einem da gegönnt.

EDIT: Und um auch das noch einmal "festzuhalten" ... @er13 hat da keinesfalls irgendein "modscript" von Dir irgendwo eingebaut, sondern das schön einzeln mit zwei zusätzlichen Patch-Files in Freetz erledigt ... da hängt aber schon ein "ganzes Öko-System" außen herum, angefangen bei der Konfiguration (ob der Patch überhaupt einbezogen werden soll) bis hin zum Sicherstellen, daß es sich um das richtige Modell handelt. Das Einzige, was da von Deiner Lösung in Freetz noch übrig geblieben ist, sind die "diff"-Ausgaben zwischen der originalen AVM-Datei und der erwarteten Ausgabe - die ja auch eher auf den anderen Boxen beruht (bis auf das Auflösen der Texte aus der DB ist das ja der Inhalt bei den anderen Modellen). Da hat er also nicht einmal wirklich irgendwelche Dateien aus irgendeinem Thread zusammensuchen müssen - vielleicht noch die Text-Datei. Den Rest hat er einfach neu gemacht ...

Wenn es dieser Weg war, den Du Dir "vorstellst" für die Integration in "modfs" durch mich, dann ist "aufs Auge drücken" von Arbeit noch viel zu freundlich formuliert und mit "die halbe Arbeit" (was sich ursprünglich gar nicht auf ein Verhältnis "bereits erledigt" vs. "noch offen" bezog und mehr auf "unfertig" hinweisen sollte) der vorhandene Part noch deutlich überbewertet.

 

[darki2017]

Wie wäre vor dem Schreiben mal wenigstens die letzten Beiträge, insbesondere von PeterPawn zu lesen?
Und ganz insbesondere #1456!

Es ist schon ein starkes Stück wie du mit den Leuten hier umgehst... liest du dir deine Kommentare eigentlich später nochmals durch? Wenn nein solltest du das machen. Dann würdest du dich schämen. Natürlich habe ich die vorrigen Posts gelesen nur ist es so, dass ich nunmal kein Profi bin und nicht genau weis wo und wie ich in einer Telnet Session irgendwelche Befehle implizieren muss um Erfolg zu haben. Wie gesagt ich verwende Telnet nur einmalig um ein Programm zu installieren. Der Rest "unter der Haube" interessiert mich nicht. Hauptsache es funktioniert. Und dies macht modfs toll (Für einen 1-Click User wie mich) Leute wie ich haben ja wohl das recht nach einer neuen Version zu Fragen wenn etwas nicht mehr funktioniert. Dies wurde wie gewohnt qualitativ schnell und sachlich von PeterPawn beantwortet. Was interessiert es dich eigentlich ? Bist du ein Mod? In denke nicht... Und wie du mit Peter umgesprungen bist ist unter aller Sau! Du und viele Andere können froh sein, dass es hier im Board so einen erfahrenen Dev gibt der seit Jahren sein Geistiges Eigentum und Wissen hier frei pupliziert und immer auf neue Gegebenheiten reagiert. Man muss auch mal dankbar sein. Das ist eine Menge Arbeit die er leistet und das würdige ich!!! Aber in unseren egoistischen Geselschaft ist dies ja nichts mehr Wert. Echt traurig...

Und die die behaupten, dass er Arrogant ist sollten Sich ebenso schämen! Selbst wenn er das wäre hat er allen Grund dazu!

Egoistisch, Neidisch, Missgünstig, Faul ... genau dies sind die Merkmale die hier über die Jahre echt zugenommen haben !

 

[eisbaerin]

Natürlich habe ich die vorrigen Posts gelesen

BTW: "vorigen" wird nur mit einem "r" geschrieben.
(Mein Augenkrebs wird in diesem Forum von Jahr zu Jahr schlimmer)

Ach ja? Wirklich? Dann hätte dir das nicht entgehen sollen:

Wenn ich das Telnet-Skript anpasse

Und das besagt doch eindeutig, daß PP daran arbeitet.
Also ist deine Frage aus #1461 so was von sinnlos und überflüssig.

Zu dem Rest deiner sinnlosen und ungerechtfertigten und völlig überflüssigen Verleumdungen und Anfeindungen äußere ich mich lieber nicht, zum Wohlgefallen von allen!!!

 

[Mr.I]

Guten Abend,
auch ich habe mich am Update meiner 7490 per 'modfs-0.5.0-beta.tgz' von 6.93 auf 7.01 versucht.

Das Skript läuft fast bis zum Ende durch, nach dem Packen des neuen root-Dateisystems erscheint der Hinweis "Erstellen eines neuen ' u eren Dateisystems' ... Fehler", in der nächsten Zeile "The specified message number 255 was not found at the language file for 'de'.

Anschließend wird das ext3-Dateisystem abgemeldet und gelöscht. Nach einem reboot wird wieder auf 6.93 gestartet. Das Kopieren des neu erzeugten Root-Dateisystems in die inaktive Partition findet demnach nicht statt.

Auf der Neustart-Seite erscheint für die andere Partition der Hinweis "Das System in den alternativen Partitionen kann nicht identifiziert werden, es könnte beschädigt sein.
Eine Umschaltung auf dieses System sollte nur ausgeführt werden, wenn man sich wirklich sehr sicher ist, was man da tut."

Hier scheint also etwas nicht so gelaufen zu sein, wie es sollte.

Bin für Tipps und Lösungshinweise dankbar...

Gruß
Mr.I

 

[PeterPawn]

Bitte die Protokoll-Datei (mit "showshringbuf modfs" am Terminal angezeigt, am besten umleiten in eine Datei - in #1 sollte ein Verweis auf einen Beitrag dazu verlinkt sein) anhängen ... ich habe zwar heute ein neues Archiv bereitgestellt mit weiteren Änderungen, aber es gibt (a) keine Nachricht mit Nummer 255 (das stimmt also schon mal an der Fehlermeldung - https://github.com/PeterPawn/modfs/blob/master/locale/de) und es gibt (b) aber auch nicht ein einziges Vorkommen von 255 im gesamten "modfs"-Skript - sagt jedenfalls mein "grep 255 modfs"-Aufruf. Das Protokoll überlebt auch das Entsorgen des ext3-Containers.

Da ist mir also vollkommen unklar, wo das herkommen sollte und man kommt ohne Protokoll gar nicht weiter bei irgendeiner (Trocken-)Suche.

Wobei ich das auch schon sehr lange nicht mehr mit einer Container-Datei getestet habe ... ich würde ja eher zu einem USB-Volume mit einem passenden Dateisystem greifen. Zumal heute irgendwelche µSD-Karten im USB-Adapter ja praktisch überall herumschwirren und auch ein 8 GB-USB-Stick wird einem ja eher hinterhergeworfen bzw. hängt in jedem Supermarkt im Kassenbereich. Die Version mit dem "ext3"-Image (weil beim Aus- und Einpacken eben ein natives Dateisystem benötigt wird) braucht noch mehr Hauptspeicher als die anderen Varianten.

Mehr als ein passendes Dateisystem braucht es aber gar nicht ... und da fehlender Swap-Space immer wieder für Fehler und Nachfragen sorgt und es ohnehin noch irgendeinen Wrapper um das Modifizieren braucht, der - je nach OS-Version des laufenden Systems - die richtigen Binärdateien verlinkt, wird die nächste Version auf Swap-Space bestehen und sich nur mit einer weiteren Umgebungsvariablen von dieser Idee abbringen lassen (wenn das jemand auf einem anderen System laufen läßt, wo genug RAM vorhanden ist für das Packen).