- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
@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).
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).
