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

@bmaehr:
Dann schreib' das doch einfach gleich hin, was Du bereits gelesen und selbst ausgeschlossen hast, dann denkt man auch nicht in die falsche Richtung.

Trotzdem bleibt bei mir die Frage stehen: Hast Du denn nun Swap-Space aktiviert oder nicht? Die zwingende(!) Notwendigkeit von Swap-Space steht in #1 in dem Teil, der am 06.11.2015 hinzugefügt wurde, der ist entsprechend gekennzeichnet.

Nicht jede Box hat dieselben Dienste am Start (ich gehe mangels Masse im Beitrag auf der vorhergehenden Seite von einer 7490 aus), schon die Frage, ob und wieviel der AHA-Daemon zu tun hat oder wie voll die Anrufliste ist oder ob die Kindersicherung verwendet wird (oder das Gastnetz) und mit wievielen Profilen und wievielen Geräten im LAN oder per DECT, ob mit oder ohne WLAN, usw., kann den entscheidenden Kick liefern, der das System ohne passende Vorbereitungen über die Klippe schubst.

Ich bin - tut mir leid, aber ich schreibe es lieber so deutlich, damit es keinen Raum für Mißverständnisse gibt - erst dann bereit, über weitere mögliche Probleme nachzudenken, wenn es definitiv kein Speichermangel sein kann und am Ende ist dazu neben der "Versicherung", daß es den passenden (und passend formatierten) USB-Stick gibt und der angesteckt wurde, auch noch die Ausgabe von "cat /proc/swaps" erforderlich, weil erst dann auch sichergestellt ist, daß dieser Stick korrekt vom System erkannt und eingebunden wurde. An allen Stellen davor kann es noch zu Fehlersituationen kommen und daher ist das tatsächlich die einzig sichere Stelle, an der man den Swap-Space diagnostizieren kann.

Eine andere Idee habe ich erst einmal nicht und solange da kein Swap-Space existiert, denke ich auch nicht darüber nach ... ich hoffe, Du verstehst diesen Standpunkt, es ist nicht persönlich gemeint.

Ich kann jedenfalls (ohne passende Erklärung, die ich aber gerne zur Kenntnis nehme) erst einmal keinen Zusammenhang zwischen einem automatischen und einem manuellen Download erkennen, der sich - abseits der "Speicherproblematik" - auf das Packen des neuen Dateisystems auswirken würde. Aufgrund des Aufbaus der Image-Datei von AVM braucht zwar der Download direkt innerhalb von "modfs" ein paar mehr Dateien in den Zwischenschritten (die eigentliche Image-Datei wird dann auch wieder gelöscht, um Platz zu sparen - gerade bei der Verwendung des yaffs2-FS kann es schnell eng werden), aber ab einem bestimmten Stadium der Ausführung sollte das auf dasselbe hinauslaufen. Aber die Speicherbenutzung und -auslastung ist nun mal dynamisch und da kann schon die Zuordnung von Dateipuffern das Zünglein an der Waage sein.

@all:
Ich baue einfach mal die Ausgabe von /proc/swaps und /proc/mounts noch mit in die Debug-Ausgabe in den Ringbuffer ein, dann braucht man (wenn denn das nunmehr immer erzeugte Debug-Protokoll so einem Fehlerbericht "beigeordnet" wird, was auch in #1 in der Änderung vom 24.03.2016 steht) nicht mehr nachfragen zu diesen Punkten. Auch die generelle Verfügbarkeit dieser Protokollierung steht in #1 (in der Änderung vom 26.07.2015) und dort ist auch der Beitrag zur "Handhabung" des Debug-Protokolls (steht in #190) verlinkt. Wenn ein Problem auftreten sollte, ist auch das Debug-Protokoll das richtige (und eigentlich auch das einzige, die Console-Ausgaben interessieren bei der Fehlersuche nicht mal richtig am Rande, weil sie sich im Debug-Protokoll auch entdecken lassen), was man hier (unaufgefordert) an seine Fehlermeldung anhängen sollte.

Mehr kann (und will) ich nicht machen - ich habe absolut keine Lust, das irgendwie anders und neu zusammenzufassen, was es an verstreuten Beschreibungen in diesem Thread gibt. Denen, die ihre Zeit nicht mit dem Lesen verbringen wollen, kann ich nur schreiben: Ich habe mit einiger Sicherheit mind. eine Zehnerpotenz mehr an Zeit investiert, als ich die ganzen Informationen zusammengetragen, in Shell-Skripte gegossen und dann hier beschrieben habe. Ist das jemandem zuviel, bliebe ihm immer noch Freetz oder eine andere (eigene) Lösung - nicht "modfs" geht auf die Suche nach einem Anwender, der Anwender findet i.d.R. "modfs", macht sich schlau, was das kann und entscheidet dann, ob es seine Anforderungen erfüllen könnte oder nicht. Wie er das überhaupt kann, ohne zuvor etwas dazu zu lesen, verstehe ich schon mal nicht.

Wenn mir dann jemand schreibt, er würde irgendwelche Informationen in #1 nicht finden und ich weiß genau, daß ich sie aufgeschrieben und dort auch verlinkt habe (oder zumindest die Nummer des Beitrags im Thread erwähnt habe), dann bringt es auch nichts mehr, mich "zu loben" für "modfs" ... dann bin ich erst einmal sauer, wenn mir jemand die objektive Unwahrheit schreibt und sehe das als "Schutzbehauptung" - das mag zwar subjektiv sogar der Wahrheit entsprechen, aber ein "ich kann es nicht finden" ist etwas vollkommen anderes als ein "es steht da nicht". Wer mir wirklich einen Gefallen tun will und sich "bedanken" möchte, der überlegt sich einfach, ob meine Bitte in #1 (erster Absatz nach dem roten Text) bzgl. irgendwelcher zusätzlichen Fragen wirklich so unangemessen ist, wenn ich dort auf das wiederholte Stellen derselben Fragen eingehe und darum bitte, dieses zu unterlassen.

Ich habe meinerseits keinerlei Bauchschmerzen damit, wenn jemand ein echtes Problem beim Einsatz von "modfs" entdeckt und werde jede nur denkbare Anstrengung unternehmen (nun gut, vielleicht nicht jede, aber viele), um das Problem zu lokalisieren und - sofern möglich - zu beheben ... aber es ist einfach auch LANGWEILIG, wenn immer nur dieselben Probleme berichtet werden, die man auch bei "richtiger Handhabung" (und das Thema Swap-Space steht auch in der Anleitung von @eisbaerin und zwar hier und hier) eigentlich gar nicht haben sollte. Dort steht u.a. auch schon (in #6), daß es eben einen Unterschied beim Speicherbedarf macht, wieviel die verwendete FRITZ!Box ansonsten noch zu tun hat.

Ich freue mich über jeden Nutzer (ob neu oder nicht), der mittels "modfs" sein Ziel erreichen konnte - noch mehr freue ich mich über jemanden, der sich an die Anleitung hält (und bei Problemen dann erst einmal prüft, ob er das getan hat - wenn er nicht vorher alles gelesen hat, dann sollte er es eben beim Auftreten von Problemen nachholen) und damit ohne weitere Probleme zum Erfolg gelangt. Ein "zu lang, zu umfangreich, zu unübersichtlich" finde ich - abseits aller anderen nettgemeinten Worte - reichlich unpassend. Wenn die Beschreibung jemandem zu lang ist, dann muß/kann/darf er auf den Einsatz von "modfs" verzichten oder seinerseits eine bessere Beschreibung abliefern.

Nichts gegen berechtigte Kritik und Nachfragen bei echten Problemen ... aber "ich habe keine Lust und keine Zeit, mir das alles durchlesen, also frage ich einfach und irgendjemand wird mir schon antworten", ist deutlich die falsche (weil selbstsüchtige) Lösung - es macht es dem "Nachfolger" noch einmal schwerer und dabei hatte man ja dann selbst schon Probleme, das alles zu lesen; daran sollte man aber auch einmal einen Gedanken verschwenden. Ansonsten macht einfach einen weiteren Thread auf, in dem dann "Anfängerfragen" gestellt werden sollen (das geht beim Linux dann los und endet bei bereits besprochenen Lösungen für "modfs") und dann fühle ich mich auch nicht mehr "verpflichtet", meinerseits auf solche Fragen zu antworten, weil dann sofort klar ist, daß ich nicht der Adressat der Frage bin - dann braucht es auch meinerseits keine "schlechte Laune" (aka "rant"), dann halte ich mich einfach raus.

Aber ich bin da auch recht empfindlich ... ich fühle mich nämlich bei Nachfragen in diesem Thread oder auch im Zusammenhang mit anderen Dateien aus meinem GitHub-Repository dann tatsächlich angesprochen und denke, ich müsse nun dem Fragesteller helfen. Das werde ich einfach noch weiter einschränken und dann sinkt sicherlich auch die (meinerseits unterstellte) Erwartungshaltung beim Fragesteller bzgl. einer Antwort. Ein anderer, weiterer Thread würde da aber eine deutlich bessere "Abgrenzung" ermöglichen - meinetwegen irgendetwas mit "Probleme und Fragen bei der Verwendung von "modfs" und ich verspreche auch tatsächlich, den gar nicht erst selbst zu lesen (und mir damit auch keine Meinung zu Fragen und Fragestellern zu bilden, das kann sicherlich niemand für sich selbst verhindern, daß er "einen Eindruck" gewinnt und der will dann erst einmal wieder korrigiert werden).

So ... wieder ein recht langer Beitrag - erneut mit einer Bitte um vorheriges Nachdenken und in dem Bestreben, meinen Standpunkt zu verdeutlichen und zu begründen. Nun mag auch dieser Beitrag wieder zu lang zum Lesen sein - dann nehme ich mir vor, beim nächsten Mal wesentlich kürzer und prägnanter zu reagieren, egal ob das dann wieder als "Unfreundlichkeit" oder gar "Unhöflichkeit" interpretiert wird. Entweder lang, mit Begründung und mit dem Versuch, Verständnis beim Gegenüber zu bewirken oder kurz und grob - das sind die Alternativen, die ich anbieten kann; ein Lavieren dazwischen liegt mir nicht, dann lasse ich das Schreiben einfach bleiben.

- - - Aktualisiert - - -

Gesagt, getan ... neues Datum, einzige Änderung: /proc/mounts, /proc/swaps und 'df -h' werden ins Debug-Protokoll geschrieben.

Bitte bei Fehlermeldungen dieses Debug-Protokoll (auszugeben mit "showshringbuf modfs", Ausgabe umleiten in eine Datei nach Belieben) anhängen (nochmal: anhängen und nicht zwischen "CODE"-Tags direkt einstellen).

Ggf. kann die Ausgabe von /proc/mounts und/oder 'df -h' Daten enthalten, die man vor der Veröffentlichung noch einmal auf "Vertraulichkeit" überprüfen sollte.

Wenn da also irgendwelche Speicherpfade (u.a. vielleicht zum Onlinespeicher) stehen, dann kann man die verfremden - wer ganze Zeilen löscht oder die Angaben zum verwendeten Dateisystem oder dem freien Platz usw., der sollte wissen, was er da tut und warum, denn die Informationen werden ggf. zur Beurteilung von Problemen mit dem Speicherplatz (das geht bis zum Arbeitsverzeichnis, dessen Auswahl vom "modfs" eigentlich in die Hände des Benutzers gelegt werden sollte) benötigt.

Weitere "individuelle" und schützenswerte Informationen im Debug-Protokoll fielen mir jetzt ad hoc nicht ein, wenn jemand da irgendetwas entdecken sollte, was mir (dann schon länger) entgangen ist, muß man darüber reden (oder besser schreiben).

Das sollte reichen ... allerdings für alle Dateisysteme, keine Ahnung, ob das tatsächlich erforderlich ist.

Vielleicht sollte man lieber ein paar Zeilen für ausgewählte "volume label" ergänzen, bei denen dann das "noexec" auf Basis des Volume-Namens weggelassen wird, denn eigentlich ist das ein sinnvoller Schritt und vielleicht wird der ja bei AVM irgendwann auch mal auf die per "davfs2" eingebundenen Dateisysteme ausgedehnt - bisher wird da m.W. immer noch das x-Flag vom Server übernommen und das eröffnet ggf. jemandem mit Zugriff auf den Server in Kombination mit einer (neuen oder bereits bekannten) RCE-Lücke wieder den direkten Aufruf auch binärer Dateien (bei Skripten ist das wg. der verbleibenden Möglichkeit des direkten Aufrufs eines Interpreters mit der Datei als Eingabe ohnehin nur ein unzureichender Schutz, wenn das x-Flag nicht gesetzt ist).

Es gibt immer eine Möglichkeit, einen Shell-Zugang zu einer FRITZ!Box zu erlangen (zumindest bisher).

Ein denkbarer Weg (für den man dann halt ein paar Kommandos anstatt in die /var/install eines "Pseudo-Images" in eine eigene Datei unter /var/media/ftp schreiben muß) wäre der Aufruf einer Skriptdatei über diese Lücke: https://github.com/PeterPawn/YourFritz/tree/master/reported_threats/796851

Die sollte (theoretisch) in der 06.51 der 3370 funktionieren, mangels Gerät kann ich das aber nicht definitiv sagen. Probieren hilft ... und was beim "Installieren" von ShellInABox in der Wrapper-Partition zu beachten ist bzw. wie das funktioniert, steht irgendwo in einem der beiden Threads, die sich mit "modfs-Starter" befassen (da, wo ich das Prinzip beim Start über ein "in-memory"-Image erklärt habe).

Man muß event. etwas "aufpassen", wenn man den Mailversand z.B. wirklich durch ein Update auslöst (es reicht m.W. aber schon, irgendeine ungültige Datei als Image anzugeben, weil die Prüfung erst nach dem Mailversand erfolgt, auch da bin ich aber nicht sicher, weil das schon wieder länger her ist ... also einfach selbst probieren) ... es macht keinen Sinn in das aktive FS unter "/wrapper" zu schreiben, wenn hinterher ein Firmware-Update auf das andere System umschaltet. Zwar kann man dann auch wieder zurückschalten, aber besser ist es allemal, den weiteren Ablauf so eines Updateversuchs gleich am Beginn "plattzumachen", damit es erst gar nicht zu einer echten Update-Installation kommt.

Ich weiß zwar nicht genau, was man unter "einfachen und wenigen Schritten" verstehen soll ... ich versuche es trotzdem einmal; auch auf die Gefahr hin, daß das wieder nur als "negative Reaktion" aufgefaßt wird.

---

-Ich will nicht schon wieder in "allgemeine Diskussionen" einsteigen, aber das Partitionieren und Formatieren eines USB-Datenträgers ist nun einmal Grundwissen (das braucht es nicht nur für "modfs", sondern es ist praktisch für jeden (Linux-)Benutzer eines USB-Sticks unumgänglich) und welche der vielen Anleitungen im Internet dafür man nun "gut findet" und welche nicht, hängt so stark vom eigenen Geschmack und den eigenen Vorkenntnissen ab, daß es einfach keine allgemeingültige "Empfehlung" geben kann und auf eine Diskussion "Du hast die und die "Anleitung" verlinkt, die und die ist aber viel besser ..." habe ich absolut keinen Bock.

Ich halte die Verwendung einer Swap-Datei sogar für eine schlechte Idee (auch wenn die Modifikation bzgl. des Aushängens von Swap-Space beim Neustart auch Dateien berücksichtigt ... im Gegensatz zu einer Datei, die zur Aktivierung zusätzliche Kommandos braucht, wird eine Partitiion automatisch verwendet) und ansonsten braucht es genau einen USB-Stick mit (mindestens) zwei Partitionen. Einmal eine Partition, als "Linux swap" gekennzeichnet, mit einer Größe ab ca. 512 MB (viel mehr macht auch keinen Sinn, weil Swap-Space keinen fehlenden Hauptspeicher ersetzen kann, er ermöglicht dem Linux-OS "nur" das temporäre Auslagern von Speicherinhalten für Programme, die gerade laufen, aber Teile ihres aktuellen Inhalts im Moment nicht benötigen oder dann halt warten müssen, bis wieder Platz vorhanden ist) und zum zweiten eine Partition mit einem nativen Dateisystem für Linux, welches die Verwendung von (Unix- bzw. Linux-)Dateiattributen direkt unterstützt und nicht irgendwo "emuliert", wie das bei FAT der Fall wäre. NTFS fällt schon wegen der Umsetzung über NTFS-3G und Fuse unter den Tisch ... und FAT könnte zwar tatsächlich für eine Swap-Datei verwendet werden (deren Attribute interessieren nicht wirklich), aber dort bräuchte eben ein Linux-Dateisystem eine "Containerdatei" in Form eines Images und das kostet spätestens bei der Ausführung dann einiges an Performance.

Die Dateiattribute sind wichtig, weil sie beim Entpacken und Packen des SquashFS-Images eine Rolle spielen. Angesichts des beschränkten Umfangs der Unterstützung von Dateisystemen im originalen AVM-Kernel, kommt damit nur eine der Versionen eines "extn"-Dateisystems in Frage. Angesichts der "Empfindlichkeit" von "ext2" bei unerwarteten Neustarts (das kann schnell in einem "kaputten" Dateisystem enden und so ein FS muß dann erst repariert werden, was mind. eine Shell-Session zur Box erfordert), bleiben nur "ext3" und "ext4" übrig und gegen die Verwendung von "ext4" habe ich mehrfach argumentiert. Zumindest beim hier zu betrachtenden Einsatzfall bringt "ext4" keinen Vorteil (m.E. ja bei keinem sinnvollen Einsatz an einer FRITZ!Box), also wäre die Wahl von "ext3" naheliegend.

Die bereitgestellten Werkzeuge im "bin"-Verzeichnis von "modfs" ermöglichen jetzt sowohl das Partitionieren eines USB-Sticks (die BusyBox enthält das "fdisk"-Applet) als auch das Anlegen der jeweils benötigten Dateisystem-Strukturen. Ein "mkswap"-Applet ist in der BusyBox ebenso enthalten, wie die (statisch gelinkten) Programme für die Verwendung von "extn"-Dateisystemen ("mke2fs" zum Erstellen und "e2fsck" zum Prüfen, falls doch auch mal ein "journaling filesystem" wie "ext3" oder "ext4" so zerwürgt ist, daß es einer gesonderten Überprüfung bedarf) gesondert bereitsgestellt wurden - wie diese Programme jetzt jeweils zu verwenden sind, wenn man den Stick direkt an der Box einrichten will und nicht an einem externen System, steht im Internet. Bei der Verwendung eines externen Systems hängt das Vorgehen dann logischerweise von diesem System ab ... hier springt die "Unmöglichkeit" einer allgemeingültigen Beschreibung dann direkt ins Auge.

Da ein korrekt eingerichteter USB-Stick dann automatisch auch richtig eingehangen wird (die Verwendung einer Swap-Partition ist auch im originalen AVM-System enthalten in "/etc/hotplug/udev-mount-sd"), braucht es dafür gar keine weiteren (zusätzlichen) Kommandos/Schritte/Vorbereitungen, als das Verbinden des USB-Speichers (ggf. mit externer Stromversorgung, weil die Modelle ohne USB3-Ports nur 500 mA an einem USB-Port bereitstellen). Dazu schaut man sich sowohl den Stecker (der kann auch direkt Bestandteil des USB-Speichergerätes sein, wenn es sich um ein solches handelt, was man gewöhnlich als "Stick" bezeichnet oder es ist das Ende eines "Kabels") als auch die Buchse in der FRITZ!Box an und führt dann den Stecker dergestalt in die Buchse ein, daß dabei keinerlei mechanische Probleme entstehen. Dafür ist sowohl die richtige Orientierung von Stecker und Buchse erforderlich als auch (am Beginn) unbeschädigte Kontaktzungen auf beiden Seiten.

Wer sich jetzt fragt, warum ich ausgerechnet den Vorgang des Verbindens von FRITZ!Box und USB-Speicher so ausführlich darstelle ... das ist dann tatsächlich "der gemeinsame Nenner", für den es praktisch keine Alternativen gibt und bei dem man als einziger Aktion wirklich eine "Anleitung" geben kann, wo zwar Kontroversen bzgl. der notwendigen Ausführlichkeit entstehen könnten (angesichts unterschiedlicher Ausgangskenntnisse bei möglichen Lesern), aber am generellen Vorgehen sollte sich hier eigentlich keine weitere Diskussion entzünden können.

Ich hänge jetzt hier bewußt keine URL an ... die Verwendung der Suchbegriffe "linux usb formatieren" liefert bei der gößten Suchmaschine ca. 177.000 Ergebnisse in 0,43 Sekunden (ich habe extra mal "auf Deutsch" präferiert) und ich fühle mich einfach nicht dazu berufen, meinerseits dieser Ergebnismenge ein weiteres Element hinzuzufügen (durch eine eigene "step by step"-Anleitung) oder gar für irgendjemanden eine Auswahl zu treffen, welcher dieser Treffer nun für ihn oder sie am besten geeignet sein mag.

Wenn jemand eine fremde "Entscheidung" benötigt, wie so ein USB-Stick nun aufgebaut sein soll, dann gerne als "Empfehluing" (solange niemand hinterher auf die Idee kommt, mit mir darüber diskutieren zu wollen):

USB-Stick mit mind. 4 GB mit zwei Partitionen einrichten, eine Swap-Partition mit 512 MB (bis zu 2 GB könnten sinnvoll sein, wenn der Stick am Ende gar 8 GB gesamt haben sollte) und den Rest des verfügbaren Speichers als "ext3"-Partition.

Wie das umzusetzen ist, hängt - wie erwähnt - vom eigenen Betriebssystem ab (es geht sogar unter Windows, hier aber nur mit "Zusatzsoftware" - s. Anleitung von @eisbaerin) und kann einfach nicht Gegenstand dieses Threads sein - das ist genau eines der Themen, die dann in so einen "wie mache ich das und das"-Thread gehören, wie ich ihn angesprochen habe. Ich kann zwar nicht verhindern, daß es auch in diesem Thread in aller Länge und Ausführlichkeit (ggf. inkl. der beliebten Glaubenskriege, ob man dafür nun besser Linux oder Windows oder ganz was anderes nimmt - und da bin ich "gebranntes Kind") diskutiert wird (schließlich "gehört" mir dieser Thread nicht), aber ich kann dann sehr wohl das weitere Lesen (und Schreiben meinerseits) verweigern und das würde ich auch tatsächlich machen.

---

-Ich will ebenfalls nicht mit einzelnen Benutzern diskutieren, ob man nicht auch bei der Verwendung einer Swap-Datei (auf die @eisbaerin verlinkt hat) die notwendigen Kommandos (und x Vergleiche/Diskussionen, was denn nun besser wäre: Partition oder Datei) durch einfache Suche hätte finden können (warum ich hier eine Partition für besser halte, habe ich zwar schon erwähnt, aber falls es untergegangen sein sollte: Eine Partition wird im Gegensatz zu einer Datei automatisch verwendet im FRITZ!OS.) - ich will nur noch einmal darauf hinweisen, daß es für die generelle Verwendung von Linux als Betriebssystem (und das macht eine FRITZ!Box nun einmal, mithin arbeitet auch "modfs" auf einem Linux-System, da es explizit dafür entworfen wurde, auf einer FRITZ!Box benutzt zu werden) andere und weitaus besser geeignete, ja sogar ausführlichere (was angesichts meiner üblichen Länge unwahrscheinlich erscheint, aber belegbar ist) Quellen gibt und daß es in diesem Thread eigentlich - zumindest nach meiner Ansicht - um Probleme und Fragen zu "modfs" und nicht zur Handhabung von Linux an sich gehen sollte.

Man muß mit dieser Meinung nicht konform gehen ... aber es wäre eben nett, wenn man sich vor solchen Fragen dann überlegt, ob man nur selbst von einer Antwort profitieren würde (dann bleibt immer noch die Möglichkeit, die Frage in einem gesonderten Thread zu stellen) oder ob das tatsächlich ein Thema ist, was auch andere Leser dieses Threads (meinetwegen inkl. "nachfolgender Generationen", wobei die Frage, wie es andere bisher wohl geschafft haben, einen USB-Stick passend zu präparieren, ja auch nicht ganz uninteressant ist) tangieren müßte.

Man muß so ein Thema einfach auch irgendwo beschränken (das klappt ohnehin schon nie, wie man es eingangs plant) ... ich finde jedenfalls außer der Feststellung "Das ist an anderer Stelle zu finden." keine schlüssige Begründung, warum man dann beim Thema "Partitionieren und Formatieren von USB-Datenträgern" die Grenze ziehen sollte und nicht bei "Auswahl und Installation eines passenden Linux-OS auf diversen Hardware-Plattformen inkl. Vor- und Nachteile möglicher Treiber-Dateien". Letzteres ist zwar "noch allgemeiner" und damit umfassender als das erste Beispiel, aber schon das erste ist eben eines, was (aus meiner Sicht) nicht in allen Einzelheiten in diesen Thread gehört und wo man sich mit ein wenig Beschäftigung mit dem Thema (was ist eigentlich Swap-Space unter Linux und wie kann man den bereitstellen) an anderen Stellen problemlos informieren kann.

Ich hoffe, ich bin nicht wieder "mit dem Messer zwischen den Zähnen" auf den Fragesteller losgegangen ... aber es wurde hoffentlich genauso deutlich, daß man - ich schreibe jetzt wirklich und absichtlich wieder "ohne eigene Initiative", weil ich einfach nicht glauben kann und will, daß man tatsächlich bei einer eigenen Suche so gar keine Treffer erzielen könnte - dann vielleicht doch die Finger von "modfs" lassen sollte.

Auch dieses war - zumindest am Beginn - ganz deutlich als "Anregung" für eigene Änderungen an einer FRITZ!Box gedacht (steht ziemlich sicher auch in #1) und schon dafür braucht es auch entsprechende Kenntnisse beim Anwender. Es ist doch geradezu widersinnig, wenn ich auf der einen Seite versuche, das FRITZ!OS von AVM sicherer zu machen durch Aufdecken bestehender Probleme und auf der anderen Seite dann zusehe, wie sich jemand sehenden Auges ins Knie schießt. Da bliebe als Konsequenz dann ja fast nur noch übrig, die Bereitstellung einer "schlüsselfertigen Lösung" wieder aufzugeben, wenn es wirklich um sich greift, daß "modfs" in einer Art und Weise verwendet wird, die am Ende die zusätzlich gewonnene Sicherheit wieder komplett aushöhlt (na gut, nur bei jemandem, der es dann zur Modfikation benutzt und insofern bleibt immer noch ein Plus bei der Sicherheit (der anderen) übrig), weil der (falsche) Eindruck entsteht, man bräuchte dazu keinerlei Vorkenntnisse mehr (oder den Willen, sich solche zusätzlichen Kenntnisse selbständig anzueignen).

Wenn mein erneuter "rant" jetzt auch nur einen neuen Benutzer von der Verwendung von "modfs" abhalten sollte, weil er sich in der Umschreibung oben wiederfindet, dann hätte ich das Ziel ebenfalls erreicht ... die (wiederholte) Betonung, daß es sich bei der (verständigen) Benutzung von "modfs" und Linux allgemein (speziell auch der Kommandozeile dort, weil eine FRITZ!Box nun mal keine X-Windows-Oberfläche hat) nicht um "rocket science" handelt und tatsächlich jeder durchschnittlich begabte Computer-"Versteher" dazu in der Lage sein sollte, impliziert eben noch lange nicht, daß das nun auch vollkommen ohne eigene Kenntnisse (oder entsprechende Bemühungen bei deren Erwerb) machbar wäre.

- - - Aktualisiert - - -

Wegen einer E-Mail will ich noch einmal schnell etwas loswerden ... es mag sein, daß ich hier wie der Elefant im Porzellanladen wirke und am Ende @palast das alles "abkriegt".

Warum gehe ich so "aus dem Sulky"?

Ich habe in #1042 (bei fast jedem - mir bekannten - Lesemodus ist das auf derselben Seite wie die Frage in #1048) lang und breit über Swap-Space geschrieben und im Ergebnis noch etwas dazu am Skript ergänzt.

In dem ganzen Text geht es u.a. auch darum, daß ich diesen Thread für den falschen Ort halte, um generelle Linux-Probleme zu erörtern. Das steht faktisch 1:1 auch bereits in #1 - ist also eigentlich auch nichts Neues, selbst wenn man #1042 nicht gelesen hätte.

Da sehe ich dann tatsächlich in der Frage in #1048 entweder eine Provokation (vielleicht auch zu unrecht, komme ich gleich drauf) oder erneut das Resultat genau des bereits in #1042 angesprochenen Umgangs mit dem Thema. Ich bin per se schon skeptisch, wenn mir jemand erklärt, er habe sich "über Stunden" mit dem Lesen von "hier internen und auch externen Linux-Threads zum Thema 'Swapfile erstellen'" beschäftigt und sei am Ende doch nicht einen Schritt weitergekommen. Das kann ich nicht wirklich glauben und solange jemand "über Stunden" schreibt, gehe ich von mind. 60 Minuten, wenn nicht sogar von mind. 120 Minuten aus, weil wohl jeder mit solch einer Angabe ganzzahlige Werte (von Stunden und das ist nun mal auch noch Plural) in Verbindung bringen würde.

Da würde ich tatsächlich die These wagen, daß entweder jegliche Voraussetzung für die Verwendung von "modfs" fehlt (vielleicht lohnt sich auch da noch einmal ein Blick, was ich schon vor langer Zeit in #1 dazu geschrieben habe - in meinen Augen hat sich nichts Grundlegendes geändert) - darauf bin ich dann eingegangen - oder es ein untauglicher Versuch der Suche im Internet war (das kann man ohne Suchbegriffe nicht beurteilen und die fehlen in der Frage leider - darauf bin ich nicht erneut eingegangen) oder es ist eben doch eine Übertreibung, die man nicht ganz so ernst nehmen kann (oder vielleicht sogar sollte nach dem Willen des Fragestellers). Wie auch immer ... wenn nach der Beschäftigung "über Stunden" so eine simple Frage nicht geklärt ist, was der Unterschied zwischen einer Swap-Datei und einer Swap-Partition ist und wie beide eingerichtet und eingebunden werden, dann stellt sich mir die Frage, warum das durch eine (erneute) Anleitung nun anders werden sollte ... und der Verweis auf Linux-Grundlagen und die Bitte, sich diese Grundkenntnisse anderswo zu erarbeiten, ist weder neu in #1042 noch (nach meinem Dafürhalten) unbegründet.

Es kommt immer wieder die Kritik auf, der Thread wäre so lang und es könne ihn praktisch niemand mehr lesen ... aber das steht dann praktischerweise nicht etwa in einem "Nachbarthread" mit der eigenen Frage, sondern wieder in einem zusätzlichen Beitrag in diesem Thread, was für den nächsten Leser die Lage noch mehr verschärft (der vielleicht doch noch mehr Ausdauer beim Lesen gehabt hätte als der letzte Fragesteller). Wenn jemand tatsächlich keinen Bock hat, den gesamten Thread zu lesen und trotzdem eine Frage hat, die (erkennbar!) mit dem Thema "modfs" zu tun hat, dann muß man wohl resignieren und sich denken: "Wenigstens paßt es zum Thema." ... das sehe ich (egal wie sehr ich mich auch anstrenge) bei der Frage nach dem "Swap-Space" absolut nicht.

Inzwischen hat dieser Thread tatsächlich eine Länge erreicht (da spielt die jeweilige Länge der von mir geschriebenen Beiträge zumindest nicht direkt hinein, denn die zählen nur einmal, egal wie lang sie sein mögen), daß man kaum noch (realistischerweise) darauf verweisen kann, daß das irgendwo hier im Thread bereits steht. Aber das, was direkt in #1 steht und auch jeder von dortaus verlinkte Beitrag - das gilt auch dann, wenn dort nur die Nummer steht und es keinen Link gibt - sollte schon zu dem gehören, was man sich erst einmal durchliest, bevor man sich zur eigenen Frage aufrafft. Dann noch zweimal gründlich nachgedacht, ob das wirklich zum Thema "modfs" gehört und dann kann ich mich tatsächlich nicht erinnern, daß ich jemandem mal keine (sachliche) Antwort gegeben hätte.

Ich finde es nur unfair (sowohl mir selbst als auch anderen gegenüber), wenn man sich "einen schlanken Fuß macht", auf Kosten anderer. Wenn jemand wirklich ernsthafte Probleme hat, etwas zu finden, dann schreibe er in drei Teufels Namen eben auf, was er gesucht und gefunden hat (das wirkt dann auch gleich viel glaubwürdiger) und dann kann man ihm für die nächste Suche vielleicht helfen. Wenn sich jemand schon deshalb weigert, weil die verwendeten Suchbegriffe wohl eher unlogisch waren, dann sagt das eben mehr über die Realität hinter der Behauptung so einer stundenlangen Suche aus (und das kommt ja auch von anderen, das geht nicht nur an die Adresse von @palast) als es jeder "rant" meinerseits könnte.

Wenn ich mich irgendwo "festlese" und vom hundertsten Link zum nächsten springe, dann kann ich mich auch stundenlang mit einer Internet-Suche befassen ... aber ab dem dritten oder vierten Link hat das mit meinem ursprünglichen Anliegen nur noch wenig zu tun (am Ende landet man entweder bei YouTube oder auf einer Pron-Seite) und da kann ich das wohl kaum zu dieser Suche "hinzuzählen".

Wenn das von @palast gar kein Test war, ob ich "ausraste" ... wenn also meine Annahme falsch war, dann ist aber das in #1 - und (zuletzt) in #1042 noch einmal - Geschriebene nach wie vor gültig - wenn ich davon ausgehe, daß ein Verwender von "modfs" spätestens dann, wenn er ein Problem findet, was bei @eisbaerin nicht beschrieben ist, wieder in diesem Thread nachliest (und zwar bevor er fragt), dann finde ich das tatsächlich immer noch "normal". Ich kann mich noch an Zeiten erinnern, wo einfach kurz und schmerzlos "RTFM" oder "STFW" geschrieben wurde (das lehnt die Forensoftware als zu kurz ab) - und das ging auch. Etwas anderes will ich hier auch niemandem "ans Herz legen" - ich kann das nur nicht so kurz und prägnant formulieren.

Ich gehöre jedenfalls noch zu den Leuten, die es sich tatsächlich überlegen, bevor sie anderen eine Arbeit aufhalsen wollen (und auch das Schreiben einer Antwort ist Arbeit), die sie eigentlich selbst erledigen könnten oder gar sollten. Die Masche "Ich bin nur ein armer DAU und kann mir das mal jemand ganz langsam erklären, weil ich nicht so schnell lesen kann." verfängt bei mir schon deshalb nicht, weil es in meinen Augen überhaupt keinen DAU gibt. Das ist entweder (a) eine reichlich überhebliche Bemerkung von Administratoren und Programmierern oder (b) eine reine Schutzbehauptung von jemanden, der etwas nicht weiß, sich damit aber auch gar nicht selbst und aus eigener Kraft befassen will.

Meine (inzwischen 37-jährige) Berufserfahrung hat mich auch gelehrt, daß ein DAU eben keine "feste Größe" ist, mit der man "planen" kann. Egal, wieviel Mühe man sich gibt, bereits im Vorfeld alle nur denkbaren Fehler und Probleme auszuschließen und eine Lösung "DAU-sicher" zu machen ... es fand sich bisher immer noch jemand, der die Latte noch ein Stückchen höher legen konnte.

Wenn also jemand freiwillig hingeht und sich selbst als DAU bezeichnet, dann sehe ich das weniger als eine realistische Einschätzung der eigenen Kenntnisse und Fertigkeiten an (die könnte man ja ohnehin erweitern und verbessern) als vielmehr als das "Vorbauen", daß es auch gar keinen Sinn macht, noch etwas zu lernen, weil man es ja ohnehin nicht begreifen würde ... das ist in der Tat ein Standpunkt, den ich "widerwärtig" finde - erst recht dann, wenn dieses Urteil von einem "Fachmann" über jemand anderen gefällt wird.

Damit ist allerdings gleichzeitig die Erwartungshaltung auf meiner Seite verbunden, daß sich jemand mit einer eigenen Frage "an die Allgemeinheit" tatsächlich auch mit der Materie beschäftigen will und wenn ihm dabei die eigene "Unlust" im Weg steht (auch das "Mir reicht das, was ich davon schon weiß." kennen wir alle zur Genüge), dann konnte mir bisher niemand plausibel machen, warum sein Problem für mich bedeutsamer sein sollte als es für ihn selbst ist und warum ich nun zusätzliche Anstrengungen investieren sollte, um sein Problem zu lösen.

So etwas gibt es tatsächlich auch (seitdem die Menschheit die Arbeitsteilung "erfunden" hat) ... dafür werden diejenigen, die ihrerseits die Arbeit übernehmen sollen, dann aber auch entsprechend entlohnt. Das geht hier im Forum nicht und somit ist das Forum auch nicht der geeignete Platz für derartige Haltungen und Ansprüche - meine Meinung.

So schön es auch sein mag, wenn man jemandem mit einem Stück Code oder einer Antwort am Ende helfen kann (und man damit einen weiteren "Nutzer" hat), daraus leitet sich noch keine "Verpflichtung" zu irgendeiner weiteren "Dienstleistung" ab und wenn jemand (erkennbar - und das kann auch am Behaupten eigener Anstrengungen bei gleichzeitigem "Auslassen" der konkreten Beschreibung bisher bereits "aussortierter" Lösungen oder Fundstellen festgemacht werden) an die Stelle eigener Bemühungen um die Lösung dann einfach jemand anderen "einspannen" will, dann reagiere ich allergisch - auch wenn ich natürlich nur für mich selbst festhalten kann, daß ich nicht der TvD sein will; fühlt sich jemand anderes dazu berufen, kann ich es nicht ändern.

Wenn das dann aber auch noch erkennbar OT ist, muß es eben nach meiner Ansicht nicht unbedingt in diesem Thread sein (ja, auch ich schreibe ab und an mal OT, aber nicht "nun erst recht", wenn es gerade erst wieder angesprochen wurde und die "Bitte" diesbezüglich quasi noch druckfrisch ist - das macht denn eben den Eindruck: "Jetzt erst recht." und der veranlaßte mich zu #1051 ... und keine andere Antwort oder ähnliches).

Ich habe mal etwas geändert wg. des neuen Eintrags im GitHub ... ich denke mal, das Ergebnis ist in etwa das, was da gewünscht war.

Der "check_trigger" ist ja nur (wenn ich das richtig gesehen habe) ein Merkmal, mit dem man zwischen "schon modifiziert" und "noch original (bzw. eher: noch unmodifiziert durch dieses Skript)" unterschieden werden kann, weil am Beginn Änderungen nicht mit "patch" gemacht wurden (gibt es in der AVM-BB nicht und die Verwendung einer eigenen Binärdatei kam erst später). Mehrfache Anwendung von "sed" kann aber leicht zu Problemen führen, deshalb brauchte es eine "Entscheidungshilfe". Bei "patch" ist die Gefahr doppelter Änderungen ja nicht vorhanden, paßt die Ausgangsdatei nicht, wird sie auch nicht geändert.

Da es ja immer noch möglich ist, daß man "inkrementelle Änderungen" vornimmt (also das bereits installierte und schon modifizierte System noch weiter ändert), gibt es auch diesen "precheck" immer noch (einige Dateien benutzen auch noch "sed", weil das nun wieder den Vorteil hat, von der "konkreten Formulierung" in der Ausgangsdatei unabhängiger zu sein), der "postcheck" dient nur der (wahrscheinlichen) Erfolgskontrolle.

Solange es vor der Änderung keine Zeichenkette "Datenvolumen" gibt, paßt das schon und wenn das ein Wort sein sollte, was AVM wirklich nur bei der 7412 aus der "inetstat_counter.lua" entfernt hat, würde ja bei anderen Modellen der "precheck" auch sofort auf "für dieses Modell nicht erforderlich" schließen können und Du könntest die erzeugte Nachricht noch entsprechend anpassen (wie ich es in "default_show_mac" gemacht habe).

Eine Prüfung auf ein spezielles Modell mache ich (in privaten Skripts) ansonsten eigentlich immer anhand des ersten Wertes in der Variablen "TARGET_SYSTEM_VERSION". Das reicht zumindest dann, wenn man ein Skript gezielt für ein Modell ein- oder ausschließen will. Ein Test, ob das Ziel eine 7412 ist, sähe dann z.B. so aus:
Das kann man bereits im "precheck" abfragen und dann eben "falsches Modell" als Nachricht zurückgeben, die von "modfs" dann protokolliert und angezeigt wird.

Die Texte befinden sich in der als "/var/htmltext.db" verlinkten Datei. Wie deren Index aufgebaut ist, interessiert mich auch, ich bin bisher bei allen Versuchen der Interpretation immer an irgendeiner Stelle gescheitert. Diese DB enthält auch alle Meldungen für das Ereignisprotokoll, die "Übersetzung" der Event-ID in den Text findet in der Datei "/etc/default/$OEM/strings.tab" statt ("/etc/default" ist ein Symlink auf "/var/default", wo dann wieder auf "/etc/$CONFIG_PRODUKT" verlinkt wird).

Zum Auslesen einer konkreten Meldung (der "Index" ist der Wert zwischen den Fragezeichen) kann man "dbtext.lua" verwenden, habe ich hier irgendwo in einem Thread mal "vorgestellt" (frag' mich nicht wo, ich weiß es auch nicht mehr) - da steht auch, wie man's anwendet.

Will man sich alle denkbaren Einträge für das Ereignisprotokoll anzeigen lassen (afaik), sähe das z.B. so aus:
Das "dbtext.lua" funktioniert leider nur auf der Box selbst - solange ich das Format nicht genau kenne, kann ich die Texte auch nicht direkt aus der Datei auslesen und bin auf die Mithilfe des FRITZ!OS angewiesen. Zumal dieses Format schon sehr alt sein muß und wohl von AVM irgendwann mal "aufgebohrt" wurde, aber die Anfänge gehen noch auf den "TI_Interpreter" zurück, wenn ich das richtig sehe.

- - - Aktualisiert - - -

Die ersten Schritte eines anderen Skripts, welches ich im Zusammenhang mit diesen Texten verwende, sehen so aus:
Nach diesen ersten Schritten enthält die Datei "/var/textdb_references.step2" dann eine Liste aller Zeichenketten aus dem laufenden SquashFS-Image, die dem verwendeten Schema für solche Text-Referenzen entsprechen. Die Liste ist sortiert und bereits "eindeutig", d.h. doppelte Einträge sind entfernt.

Theoretisch schon, praktisch will ich nicht.

Warum, habe ich schon oft genug erläutert. Mit der Bereitstellung einer binären Datei, die für den Dauereinsatz bestimmt ist, übernimmt man auch gleichzeitig die Verantwortung, diese immer in der neuesten Version anzubieten und entsprechend zu aktualisieren, wenn in vorhergehenden Versionen (Sicherheits-)Lücken erkannt werden. Das ist "nicht mein Tisch" ... und ein Skript zur Installation ist dann auch nicht mehr so schwierig beim "Eigenbau" - im Prinzip könnte man sogar das /var/install aus einem der alten Pseudo-Updates für die "SIAB-Impfung" als Blaupause verwenden.

Für einen solchen (Dauer-)Einsatz gedacht sind jedenfalls weder die BusyBox noch die extFS-Module, SquashFS-Tools oder das "openssl"-Binary aus dem "modfs"-Paket (selbst wenn man sie auf diese Art "mißbrauchen" kann, ist der Einsatzzweck das Funktionieren von "modfs" und nicht die Übernahme als "ständige Tools" in ein eigenes Image - das erfolgt "auf eigene Gefahr") und da diese eigentlich nur für die Dauer der Ausführung von "modfs" auf der Box (und automatisch erreichbar) sein sollten, geht auch von einer älteren Version mit bekannten Lücken keine inakzeptabel große Gefahr für die Integrität der FRITZ!Box aus. Auch beim "modfs-Starter" ging es ja nur um einen "Einstieg" in die Box für die spätere Verwendung von "modfs" und (als "Wunsch" meinerseits) nicht um die dauerhafte Verwendung einer alten ShellInABox-Version. Es hat auch seine Gründe, warum ich diese Dateien in den "modfs-Starter"-Archiven nie wieder aktualisiert habe, obwohl die IIRC statisch gegen die OpenSSL-Libraries gelinkt waren und vermutlich schon länger eine "Frischzellenkur" vertragen könnten.

Das war die "kurze Version" ... die lange steht bestimmt auch irgendwo schon in einem Thread hier.