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

eisbaerin

IPPF-Promi
Mitglied seit
29 Sep 2009
Beiträge
6,873
Punkte für Reaktionen
208
Punkte
63
Ich habe jetzt z.B. in der rc.user das folgende Alias gesetzt:
Dort ist es völlig falsch, da jedes Telnet oder SSH Fenster(session) in einer neuen Shell beginnt.

alias dir='ls -al --color=auto'
Das kommt mir aber sehr bekannt vor, wenn das mal nicht von mir ist ... ;)

Ich mache bei dem modscript "mod_profile" zwar immer "JA", habe es aber noch nie benutzt, da mein profile für SSH immer unter /var/tmp/.profile liegt. Das wirkt aber nicht für Telnet.

Jetzt habe ich mal versucht die Änderungen des "mod_profile" zu benutzen. IMO ist leider die Benutzung nicht erläutert.
Also du mußt:

1. ein Verzeichnis /var/custom anlegen
2. ein Verzeichnis /var/custom/etc anlegen
3. eine Datei /var/custom/etc/profile anlegen
(Warum ist das so tief verschachtelt??? Wir sind hier nicht bei freetz!)

Wenn du dann in diese Datei dein "alias" schreibst, dann sollten sie beim nächsten Telnet wirken.

Dieses kannst du alles in der rc.user machen lassen:
Code:
mkdir /var/custom
mkdir /var/custom/etc
echo "alias dir='ls -la --color=auto'" >/var/custom/etc/profile
@PeterPawn : Deine "hoch wissenschaftliche" Abhandlung ist zwar für mich ganz interessant, aber nützt diese IMO full2000 fast nichts und beantwortet seine Frage nur sehr indirekt.
Ich merke immer öfter, daß du dich nicht in die Lage eines einfachen Nutzers versetzen kannst.

(mal ganz abgesehen davon, daß die eben auch im SquashFS-Image liegen würde und dynamische Änderungen damit im weiteren Verlauf gar nicht möglich wären, sondern nur die einmalige beim "modfs")
Kann man die nicht hinterher noch übermounten?

BTW:
Eine einfache Gebrauchsanweisung für das "mod_custom_images" suche ich auch noch.
 
Zuletzt bearbeitet:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,160
Punkte für Reaktionen
753
Punkte
113
@eisbaerin:
Willst Du mich veralbern oder willst Du mich nur provozieren?

Was ist an #1360 "hoch wissenschaftlich"?

Da ist ein Verweis auf das entsprechende "modscript" im Beitrag und eine Erläuterung, wann die "/etc/profile" bei einer Shell überhaupt zum Einsatz kommt (was sie ja deutlich von der "rc.user" unterscheidet). Was diese "mod_profile" ansonsten macht, steht in #1 ... ich kann auch nichts dafür, daß es seit Xenforo keine Tabellen mehr gibt und somit das "Lesen" dort entsprechend schwerer geworden ist.

Woher weißt Du eigentlich so genau, daß @full2000 jemand ist, der in Deinen Augen nur als "einfacher Nutzer" durchgeht und welche Formulierung in #1360 ist es denn genau, die Du Deinerseits für "hoch wissenschaftlich" hältst und damit als Erklärung für ungeeignet ansiehst? Ist das nicht auch etwas überheblich gegenüber den (unterstellten) (Un-)Fähigkeiten von anderen?

Ansonsten kann ich Dir aber auch gerne noch mit Informationen weiterhelfen, was ich mir bei bestimmten Änderungen gedacht habe.

Die Frage
(Warum ist das so tief verschachtelt???)
wäre dann damit zu beantworten, daß ich dabei davon ausgehe, daß unter "/var/custom" ein komplettes Image gemountet wird (quasi als "System im System"), welches selbst wieder über eine zum Wurzelverzeichnis nach LSB analoge Struktur aufweist. Dazu gehört dann ein "/etc"-Verzeichnis, in dem die "systemweiten Einstellungen" liegen, genauso, wie ein zusätzliches "bin"-, "sbin"-, "usr/bin"-, "usr/sbin"- und "lib"-Verzeichnis ... auch für diese ergeben sich beim Mounten dieser "virtuellen Wurzel" unter "/var/custom" dann entsprechende Pfade, die "so verschachtelt" sind.

Kann man die nicht hinterher noch übermounten?
Logisch kann man ... aber die Frage ist ja: "Sollte man auch?" - wenn man die "/etc/profile" ohnehin "übermounten" will, braucht man die gesamte Modifikation nicht. Warum habe ich das abgesetzt? Weil ich mich auch auf verschiedenen Modellen und Versionen nicht gesondert darum kümmern will, was AVM da in der "/etc/profile" ansonsten noch so macht (z.B. den Aufruf von "getcons" in der ersten Session) und ob sich das irgendwann irgendwie ändert ... und weil ich lange nicht auf jeder Box dieselben Inhalte in einer solchen "Erweiterung" der "/etc/profile" stehen haben will - was ebenfalls die direkte Modifikation der "/etc/profile" nur als zweitbeste Lösung erscheinen läßt. Bei der Verwendung des Konstrukts:
Code:
[ -f /var/custom/etc/profile ] && . /var/custom/etc/profile
wird hingegen ganz sauber auf die Existenz einer solchen Erweiterung getestet (die kann meinetwegen überall liegen ... packt man sie auf einer Box mit einem "wrapper"-Verzeichnis dort hinein, ist sie sogar persistent änderbar auf VR9-Modellen) und nur wenn sie vorhanden ist, werden die dort eingetragenen Kommandos auch "inkludiert" - was hier wieder entscheidend ist, weil eine Sub-Shell automatisch dazu führen würde, daß vorgenommene Einstellungen mit der zusätzlichen Instanz auch wieder "sterben".

BTW: Eine einfache Gebrauchsanweisung für das "mod_custom_images" suche ich auch noch.
Da kann ich Dir (auch wenn Du das nur mal "beiläufig" fallen lassen wolltest) leider auch nicht wirklich weiterhelfen ... aus Deiner Formulierung muß ich ja wohl schließen, daß Dir diese Erläuterungen nicht "einfach" genug sind - an "nicht ausführlich genug" wird es ja hoffentlich nicht liegen. Aber die einzige Chance, die ich dann meinerseits sehe, wäre die Beantwortung konkreter Fragen zu den Teilen, die Du (oder jemand anderes) nicht verstanden ha(s)t aus der verlinkten Beschreibung - aus diesem Kontext der Verwendung eines solchen "custom images" ergibt sich dann auch noch einmal eine ausführlichere "Begründung" für die überbordende "Verschachtelung", die ggf. die oben abgegebene Erklärung dazu ergänzen kann.

Einfacher als eine aus dem Chinesischen ins Deutsche übersetzte Gebrauchsanweisung wird das vermutlich immer noch zu lesen sein ... ansonsten steht es jedem (der den Inhalt verstanden hat) ebenso wieder frei, mit gutem Beispiel voranzugehen und meine "hochwissenschaftliche Erklärung" (falls diese Klassifikation für #644 auch gelten sollte) so umzusetzen, daß auch der "einfache Nutzer" (wer auch immer das sein mag und wie gut der sich genau auskennt - ich kenne ihn halt nicht, aber Du ja offenbar dann doch) etwas davon hat. Hat so jemand selbst Schwierigkeiten mit dem Verständnis, habe ich mich (sofern es tatsächlich um von mir geschriebene Sachen geht und nicht um "Wie bediene ich die Konsole und was ist denn dieses Vieh, von dem alle immer schreiben, wenn sie Dateien bearbeiten wollen?") bisher m.W. auch noch nie geweigert, weitere Erläuterungen oder Hilfestellungen zu geben.

Ich verwende jedenfalls genau so einen Mechanismus auch bei mir (gut, mit ein paar anderen Anweisungen in der E99-custom, weil ich noch die Signatur von Images über "tr069fwupdate" prüfen lasse, aber das Prinzip ist noch genau dasselbe):
Code:
[email protected]:~ $ l /etc/init.d/ | grep wrapper
lrwxrwxrwx    1 root     root            30 Thu Nov  9 18:41:40 2017 E99-custom -> /wrapper/etc/init.d/E99-custom
lrwxrwxrwx    1 root     root            30 Thu Nov  9 18:41:40 2017 S02-config -> /wrapper/etc/init.d/S02-config
lrwxrwxrwx    1 root     root            37 Thu Nov  9 18:41:40 2017 S03-early-syslogd -> /wrapper/etc/init.d/S03-early-syslogd
lrwxrwxrwx    1 root     root            28 Thu Nov  9 18:41:40 2017 S03-path -> /wrapper/etc/init.d/S03-path
lrwxrwxrwx    1 root     root            30 Thu Nov  9 18:41:40 2017 S20-config -> /wrapper/etc/init.d/S20-config
lrwxrwxrwx    1 root     root            29 Thu Nov  9 18:41:40 2017 S50-rdate -> /wrapper/etc/init.d/S50-rdate
[email protected]:~ $ l /wrapper/etc/init.d/
drwxr-xr-x    1 root     root          2048 Sat Jun  4 06:29:49 2016 .
drwxr-xr-x    1 root     root          2048 Sun Jul  3 23:27:00 2016 ..
-rw-r--r--    1 root     root         29802 Mon May 30 17:36:03 2016 E99-custom
-rw-r--r--    1 root     root          3284 Mon May 30 14:31:18 2016 S02-config
-rw-r--r--    1 root     root          2681 Mon May 30 14:42:41 2016 S03-early-syslogd
-rw-r--r--    1 root     root          2074 Mon May 30 14:46:59 2016 S03-path
-rw-r--r--    1 root     root          1639 Mon May 30 14:51:51 2016 S20-config
-rw-r--r--    1 root     root          2304 Mon May 30 14:57:05 2016 S50-rdate
[email protected]:~ $ mount -t squashfs
/dev/loop0 on / type squashfs (ro,relatime)
/dev/loop1 on /var/custom type squashfs (ro,relatime)
/dev/loop2 on /var/bintools type squashfs (ro,relatime)
[email protected]:~ $ l /var/custom
drwxr-xr-x    7 root     root            83 Sat Jun  4 06:16:11 2016 .
drwxr-xr-x   20 root     root          2400 Wed Feb 21 01:59:47 2018 ..
drwxr-xr-x    2 root     root           103 Tue Aug 15 01:48:54 2017 bin
drwxr-xr-x    4 root     root            77 Sat Jun  4 06:16:02 2016 etc
drwxr-xr-x    2 root     root          2892 Mon Sep 25 17:51:20 2017 lib
drwxr-xr-x    2 root     root            39 Mon Aug 14 14:46:56 2017 sbin
drwxr-xr-x    6 root     root            74 Mon Aug 14 14:50:53 2017 usr
[email protected]:~ $ l /var/custom/etc/init.d/
drwxr-xr-x    2 root     root            91 Mon Aug 14 14:23:36 2017 .
drwxr-xr-x    4 root     root            77 Sat Jun  4 06:16:02 2016 ..
-rwxr-xr-x    1 root     root          7606 Mon Aug 14 14:23:36 2017 rc.alive
-rwxr-xr-x    1 root     root          6191 Sun Apr 17 02:11:41 2016 rc.dropbear
-rwxr-xr-x    1 root     root          6629 Sun Apr 10 14:19:02 2016 rc.shellinaboxd
-rwxr-x---    1 root     root          5841 Sat Apr  9 16:38:24 2016 rc.startup
[email protected]:~ $ cat /var/custom/etc/profile
export TMP=/var/tmp
tmphome=$(sed -n -e "s|^\($USER\):\([^:]*\):\([^:]*\):\([^:]*\):\([^:]*\):\([^:]*\):\(.*\)\$|\6|p" $(realpath /etc/passwd))
[ ${#tmphome} -gt 0 ] && export HOME=$tmphome
export LD_LIBRARY_PATH=/var/custom/lib${LD_LIBRARY_PATH+:}$LD_LIBRARY_PATH
export PATH=$HOME/bin:$HOME:/var/custom/bin:/bin:/var/custom/usr/bin:/usr/bin:/var/custom/sbin:/sbin:/var/custom/usr/sbin:/usr/sbin
und muß damit an den wichtigsten Erweiterungen, die ich in jeder Version haben will, in aller Regel gar nichts mehr ändern, weil die Dateien für die Wrapper-Partition bei mir vom "modfs" genauso in diese Partition kopiert werden, wie die zusätzlichen Symlinks (und weitere Dateien, die ich immer im SquashFS-Image haben will) über "copy_binaries" mit entpackt werden aus dem TAR-Archiv, welches dabei bekanntlich zum Einsatz kommt (der Name "copy_binaries" ist hier ja etwas irreführend, aber auch dessen Funktion ist in #1 "beschrieben").

Wie man schon an meiner "/etc/profile" aus dem "custom image" oben sehen kann, macht es sogar wieder absoluten Sinn (der Name des Mountpoints hängt ja - zumindest bei der Verwendung von E99-custom - auch vom Namen des Images ab), die Pfadangaben für die Suche nach zusätzlichen Programmen oder Bibliotheken (LD_LIBRARY_PATH), die man ja vermutlich innerhalb so einer interaktiven Session benutzen will, gerade aus dem Image heraus ebenfalls zu setzen (auch wenn man hier sogar noch das "/var/custom" durch etwas mehr Code und am Ende durch eine variable Angabe hätte ersetzen können), weil die schlicht spezifisch für die Dateisystemstruktur in diesem Image sein können.

Und auch wenn ich die Binaries in solchen Images tatsächlich immer mal wieder erneuere, sofern ich dort Änderungen vorgenommen habe (deshalb sind die auch in einem solchen "custom image" und nicht direkt im SquashFS-Image des FRITZ!OS, weil man sie dann auch austauschen kann, ohne das gesamte System zu erneuern) ... die verwendeten Skript-Dateien zum Einrichten der Umgebung für einen Service und zum Starten desselben, ändern sich in aller Regel nicht - man sieht es schon an den Datumsangaben bei den verwendeten Skripten. Damit brauche ich diese Dateien (also die eigenen "Images") auch nicht bei jedem FRITZ!OS-Update anzupassen ... es reicht vollkommen, sie (wenn sie wirklich im Wrapper liegen und nicht ohnehin in "/var/media/ftp", wo sie dank Signaturprüfung genauso sicher sind) jeweils wieder in die Wrapper-Partition kopieren zu lassen.

Daher finden sich auch durchaus recht "alte" Dateien in einem solchen Image ... aber auch vieles von dem, was ich entweder als Skript im YourFritz-Repo habe oder als Änderung/Erweiterung von Freetz in meinem Fork im GitHub - die hier enthaltenen Dateien (zumindest die veröffentlichten, aber es gibt nur wenige "private") kann sich also auch jeder selbst bauen, wenn er meine Patches für Freetz benutzt. Ich mag es eben (wie man im Anhang sehen kann, weil sonst der Beitrag wieder mal jenseits der 50k-Zeilen landen würde), wenn ich mich auf der Box auch mal mit einem "Midnight Commander" bewegen kann ... weil der Komfort bei der "ash" eben doch etwas eingeschränkt ist.

In einem zweiten "custom image" (bintools.custom) habe ich sogar eine "Entwicklungsumgebung" mit dem GCC (und den "bintools", daher der Name) auf der FRITZ!Box (auch wenn die auf der 7580 deutlich mehr Spaß macht als auf der 7490) ... da die wiederum deutlich seltener gebraucht wird, als die "normalen Erweiterungen", liegt sie eben in einem zweiten Image vor und wird nur auf den Boxen gemountet (den Mechanismus zur Auswahl habe ich bei der "E99-custom" mehr als ausführlich beschrieben), wo (bzw. sogar wenn, weil das auch nicht immer der Fall ist) sie vonnöten ist. Das ist dann ein Beispiel dafür, warum es Sinn macht (oder zumindest machen kann), das auch so "ausführlich" und konfigurierbar zu machen, anstatt einfach ein jeweils für die Box passendes Image mit allen notwendigen Zusatzprogrammen "am Stück" zu mounten ... wenn es so einfach wäre, könnte man auch immer gleich alles in das SquashFS-Image des FRITZ!OS packen, wie es AVM und Freetz (mal abgesehen von "externals", was aber eher Platzgründe hat als dem "Segmentieren" der Erweiterungen dient) machen. Auch das ist sicherlich ein Weg, aber einer, gegen den ich mich entschieden habe, weil ich einfach zuviele Boxen zu betreuen habe und nicht für jedes dieser Geräte eine "Spezial-Firmware" haben will.
 

Anhänge

Zuletzt bearbeitet:
  • Like
Reaktionen: 3949354

eisbaerin

IPPF-Promi
Mitglied seit
29 Sep 2009
Beiträge
6,873
Punkte für Reaktionen
208
Punkte
63
Willst Du mich veralbern oder willst Du mich nur provozieren?
Weder noch. Warum sollte ich? Nichts liegt mir ferner. Warum bist du so bösartig?

Was ist an #1360 "hoch wissenschaftlich"?
Es steht ja in " ", dann ersetze es eben mit "für DAUs nicht verständlich, weil zu tiefgründig" oder so ähnlich.
Und unter DAUs zähle ich mich im Vergleich zu dir mit dazu, wenn bei mir vielleicht auch etwas grenzwertig.

Den Rest muß ich erst in Ruhe lesen und verstehen und dann vielleicht antworten.
 
Zuletzt bearbeitet:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,160
Punkte für Reaktionen
753
Punkte
113
Warum bist du so bösartig?
Weil Du Dir vielleicht auch mal Deine Formulierungen besser überlegen solltest?

Ich merke immer öfter, daß du dich nicht in die Lage eines einfachen Nutzers versetzen kannst.
Es ist mir ziemlich gleich, was Du "immer öfter merkst" ... die Leute, mit denen ich direkten Kontakt habe, sind teilweise auch ältere Personen, mit sehr geringen Computerkenntnissen und wenn Du mich tatsächlich schon einmal bei solchen Erklärungen (mit aller Geduld und Ruhe und Ausführlichkeit) erlebt hättest, dann würdest Du Dir Kommentare wie den obenstehenden (den ich durchaus als ehrenrührig ansehe) klemmen.

Wenn ich hier in einem technischen Forum aber meine Antworten im ersten Zug auf das beschränke, was man nach meiner Erfahrung nicht problemlos auch in anderen Quellen nachlesen kann oder womit man den Zusammenhang zu anderen Quellen herleiten kann, dann ist das immer noch meine Entscheidung ... und auch der Ton macht die Musik.

Bei meiner Antwort an @full2000 habe ich genau das niedergeschrieben, was nach meinem Eindruck der Kenntnisse des Fragesteller notwendig erschien. Welcher Alias zu setzen war (und damit offenbar auch die Kenntnis, daß es ein "alias"-Kommando gibt), stand bereits da ... es ging nur noch um die korrekte Stelle, an der man das einbringen sollte und die habe ich meinerseits mit der Ausführlichkeit beschrieben und erklärt, die dem (von mir unterstellten) Wissensstand von @full2000 entsprach. Wieso Du ihn (oder sie) jetzt für "dümmer" hältst, kann ich nicht nachvollziehen und insoweit teile ich Deine Meinung auch nicht ... egal ob Du das in Anführungszeichen gesetzt hast oder nicht.

Wenn das nicht ausreichen sollte und auch die Suche nach weiteren Informationen nicht Erhellendes beitragen kann, ist eine Nachfrage ein opportunes Mittel - und wenn Du Dich in die Vergangenheit gerade auch in diesem Thread stürzt (den Du aber eigentlich auch kennen solltest aus den vergangenen Jahren), dann solltest Du hier auch immer wieder auf Stellen treffen, an denen das genau so auch ablief. Wenn eine "Nachfrage" kommt (kam) und anhand derer auch eigene Bemühungen zu erkennen waren, dann habe ich eher selten (und meist auch nur dann, wenn es - m.E. - "Mißtöne" und ein falsch verstandenes "Anspruchsdenken" gab, bei dem die eigenen Bemühungen sich in eigenen "Und wie geht das genau?"-Fragen erschöpften) bei der ersten oder zweiten Nachfrage irgendwie schlechte Laune heraushängen lassen und weitere, genauere Erklärungen nachgeschoben.

Seitdem ich mich geweigert habe, eigene Verantwortung für Deine Änderungen bei der 7412 mit den Statistikdaten zu übernehmen (obwohl ich extra für diesen Zweck das ganze "contrib"-Zeug eingebaut habe) und Dir mit den Links auf die entsprechenden älteren Beiträge nachgewiesen habe, daß Fortschritte an dieser Stelle durch Dich verhindert wurden (auch die Beiträge rundrum gehören zum Kontext) ... seitdem gibt es immer mal wieder Beiträge (gerade hier beim "modfs"), die ich als "Nadelstiche" ansehe und die mir persönlich zu wenig sachbezogen sind.

Mag sein, daß es sich um Vorurteile oder gar um Mißverständnisse handelt, aber nach meiner "Weigerung", das "modfs" in der vorliegenden Form auch noch an die GRX-Boxen anzupassen, gab es eben von Dir auch solche Kommentare zu lesen:
Schade, daß es jetzt langsam stirbt.
Auf meine - eher ausführliche(n) - Erklärung(en) (u.a. in #1313 und #1273 und #1231), warum ich keinen Sinn darin sehe bzw. warum ich nicht weitere Zeit in "rückwärtsgewandte" Technologie investieren will und daß ich die Modifikation von GRX-Firmware (allerdings nicht auf der Box, das gebe ich gerne zu - wobei auch das durch "Adaptieren" der Anleitung ja problemlos machbar ist) an anderer Stelle beschrieben habe, kommt dann gar keine weitere Reaktion mehr ... bis zur nächsten "Spitze" und die gipfelte oben für mich dann in der Feststellung:
Eine einfache Gebrauchsanweisung für das "mod_custom_images" suche ich auch noch.
Wenn das jetzt von Dir gar nicht als "Das könntest Du eigentlich auch mal ordentlich beschreiben, damit es ein "einfacher Nutzer" versteht." - in Fortsetzung des Tenors der vorhergehenden Sätze - gemeint war, sondern als "Frage" nach der Art: "Gibt es eigentlich irgendwo eine ausführliche Erklärung, wie "mod_custom_images" funktioniert? So etwas bräuchte ich nämlich auch ganz dringend." ... dann lies Dir einfach noch einmal die Abfolge Deiner Worte in #1361 durch und meine "Interpretation" der letzten Bemerkung und Du verstehst vielleicht auch, wieso bei mir ein solches "Mißverständnis" (wenn es denn eines war) entstehen konnte - so ganz abwegig ist mein "Verständnis" Deines Beitrags sicherlich auch nicht.

Unabhängig davon finde ich eben schon den zweiten - oben in diesem Beitrag hier zitierten - Text von Dir recht "ungehörig" - daher bin ich auch so "bösartig" (korrekt wäre eher: angefressen), wenn Du das so sehen möchtest.
 
  • Like
Reaktionen: 3949354

PlanetDyna

Neuer User
Mitglied seit
21 Feb 2018
Beiträge
1
Punkte für Reaktionen
0
Punkte
1
Hallo Folks,

ich möchte auf meiner 7590 Fritz!Load nutzen, ohne dass nach einem Reboot die Konfiguration verworfen wird. Ist dies derzeit möglich?

Beste Grüße
Felix
 

eisbaerin

IPPF-Promi
Mitglied seit
29 Sep 2009
Beiträge
6,873
Punkte für Reaktionen
208
Punkte
63
Mit modfs nicht, das ist derzeit (und wahrscheinlich für alle Ewigkeit) nicht möglich, da Peter das modfs nicht öffentlich für die GRX5(7590) Boxen nutzbar macht.
Ich vermute, interne Varianten dazu gibt es, aber jedoch habe ich die noch nicht mal.

Ich weiß, jetzt frißt mich Peter gleich roh und ungekocht,
Aber so ein Eisbärfell hält schon einiges ab ...
 
Zuletzt bearbeitet:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,160
Punkte für Reaktionen
753
Punkte
113
Nein, es gibt auch keine "internen" Versionen dafür. Was die GRX-Modelle von den VR9-Modellen unterscheidet, habe ich inzwischen mehrmals aufgeschrieben ... das Entpacken und Packen der Firmware müßte auf eine Weise erfolgen, die von "modfs" nicht unterstützt wird.

Wie einfach es ist, eine originale AVM-Firmware zu entpacken, daran Änderungen vorzunehmen und sie so wieder zu packen, daß man sie mit einem Kernel zusammen über den Bootloader installieren kann, habe ich ebenfalls (auch mehrfach) im "Modifikationen"-Thread angerissen und am Beispiel "Telnet für 7580" auch sehr ausführlich beschrieben.

Die intellektuelle (Zusatz-)Leistung, in der Phase des Modifizierens und vor dem Zusammenpacken der geänderten Struktur, dann noch diejenigen "modscripts" aufzurufen, deren Änderungen an der GRX-Firmware man gerne in dem eigenen Image hätte, ist nicht sooo herausragend oder an "Spezialwissen" gekoppelt, daß es dazu weiterer Anleitung bedarf (und selbst wenn das so wäre, bräuchte es dazu immer noch konkrete Fragen) ... wie ein Aufruf dieser Skripte unter einer "fremden" Umgebung aussiehen könnte, habe ich am Beispiel "fwmod_custom" zur Integration des "guibootmanager" in ein Freetz-Image auch schon irgendwo in diesem Thread gezeigt und ein Skript, was die gewünschten "modscripts" nacheinander aufruft, ist nun wirklich nichts, was jemanden überfordern sollte, der seine Router-Firmware modifizieren möchte.

Es gab und gibt keine "modfs"-Version von oder bei mir, welche zusätzliche "Erkennungen" für die GRX-Firmware implementiert und da sich dort bereits der Aufbau der AVM-Firmware anders gestaltet, sollte nicht einmal das Entpacken problemlos funktionieren, wenn ich nicht irgendwelche Relikte von Versuchen für die 6490 (wo der Aufbau der "filesystem.image" immerhin noch derselbe ist, wenn dort auch inzwischen eher LE-Format beim SquashFS verwendet wird, seitdem das System auf den ATOM-Core umgezogen ist) bereits damals in den "modfs"-Code implementiert haben sollte - ich weiß es nicht mehr und ich suche jetzt auch nicht danach bzw. ich werde es nicht testen.

Und ich betone es auch gerne noch einmal (obwohl ich es schon mehrfach geschrieben habe): Es wird von mir auch keine "modfs"-Version für GRX-Boxen mehr geben (um die dritte Zeitform auch noch zu ergänzen) - nicht einmal der Prozess der "Installation" in eine UBIFS-Partition muß noch einmal "nacherfunden" werden, denn den gibt es sowohl in der "/var/install" in einer AVM-Firmware als auch in der "E03-flash_update" in jedem AVM-Image bereits. Wer also nach dem Zusammenpacken nicht weiß, wie er/sie die erzeugte Firmware installieren soll, kann sich dort schlau machen - notfalls kann man es sogar (wenn man bereits auf der Box ist, wo das geänderte System installiert werden soll) von Hand ins entsprechende MTD kopieren.

Die von mir geschriebene Anleitung zum Modifizieren der GRX-Firmware kann man jedenfalls - als "Zweizüger" - auch problemlos auf einer 7580 oder 7590 anwenden (bei der 7560 braucht man sicherlich noch zusätzlichen Swap-Space wegen zuwenig RAM), indem man sich im ersten Schritt nur einen Shell-Zugang verschafft (das Problem, den im ersten Schritt zu erlangen, hat man bei jeder Box, seitdem die Firmware nur noch signierte Images akzeptiert) und danach kann man die gesamte Anleitung für das eigene Image auch auf dieser GRX-Box ausführen, denn die dafür notwendigen Binärdateien sind im YourFritz-Repository auch in einer MIPS-Version vorhanden. Etwas wie das alte "modfs-Starter", was der AVM-Firmware ohne Entpacken/Packen weitere Dateien hinzufügt, funktioniert auf den GRX-Boxen mangels YAFFS2-Dateisystem in der "wrapper"-Partition ohnehin nicht mehr.

Es gibt also (zumindest bei mir) gar keinen Bedarf nach einer GRX-Version von "modfs" - jedenfalls nicht in der vorliegenden Form und wie ich mir das in der Zukunft mit dem "Modifizieren" auf der Box selbst vorstelle, kann man sich z.B. hier als ersten Schritt in einem solchen "Batch" ansehen, wo die verschiedenen, denkbaren Quellen einer Firmware in einer Box (aktives oder inaktives Dateisystem bzw. "filesystem.image"-Datei von irgendwoher) beim Entpacken so vereinheitlicht werden, daß es sowohl für VR9- als auch für GRX- und Puma-Boxen zu demselben Ergebnis führt, an dem dann weitere Modifikationen vorgenommen werden können, bevor man es wieder einpacken läßt.
 

eisbaerin

IPPF-Promi
Mitglied seit
29 Sep 2009
Beiträge
6,873
Punkte für Reaktionen
208
Punkte
63
Ich habe nicht alles gelesen, aber:
Es gab und gibt keine "modfs"-Version von oder bei mir, welche zusätzliche "Erkennungen" für die GRX-Firmware implementiert ...
Ach ja?
Jetzt stelle ich doch gerne mal die Frage zurück:
"Willst Du mich veralbern oder willst Du mich nur provozieren?"
Und wieso gibt es seit einer gefühlten Ewigkeit den Pfad mod/bin/GRX5? Ebenso wie die Links 221, 225, 226, die auf dieses Verzeichnis zeigen??? (für alle unwissenden: 221, 225, 226 sind die HW Nummern für die FB 7560,7580,7590, welche unter dem Sammelbegriff GRX5 zusammen gefaßt werden)
IMO deutet alles darauf hin, daß alles für die GRX5 Modelle vorbereitet ist und es interne Testversionen gibt/gab/leider nie geben wird.

Es ist allerdings dein gutes Recht diese nicht zu veröffentlichen.

###

Zu dem OT gibt es von mir keine Antwort.
-----------------------------------------------------------------------
Zum Fachlichen hätte ich noch einen Hinweis:
Warum löschst du die großen Dateien immer erst ganz zum Schluß?
Du gehst IMO immer von einem unendlichen Speicher aus, den ich aber in der FB nicht habe.
Konkret: Seit die FW immer größer wird habe ich Probleme selbst in der 7580 alles im RAM zu machen.
IMO könnten bestimmte Dateien wesentlich früher gelöscht werden:
z.B.
1. nach Erstellung der firmware.squash könnte die firmware.image gelöscht werden.
2. nach Entpacken der firmware.squash könnte diese gelöscht werden.
3. spätestens vor mksquashfs könnten alle nicht mehr benötigten temporären Dateien gelöscht werden.

###


das Entpacken und Packen der Firmware müßte auf eine Weise erfolgen, die von "modfs" nicht unterstützt wird.
Ach, das lese ich ja jetzt erst. Seit wann kann modfs kein unsquashfs und mksquashfs?
Du hattest IMO mal behauptet, daß es bei den GRX5 Modellen sogar einfacher ist als bei den VR9.
Komischerweise entpacke und packe ich damit die FW laut deiner Anleitung für Telnet für die 7580.

//Zusammenführung Doppelposts by stoney
 
Zuletzt bearbeitet von einem Moderator:
  • Like
Reaktionen: Micha0815

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,160
Punkte für Reaktionen
753
Punkte
113
@eisbaerin:
https://www.ip-phone-forum.de/threads/modfs-squashfs-image-avm-firmware-ändern-für-nand-basierte-fritz-boxen.273304/page-64#post-2246254

Da stand (und steht) dann auch schon drin, daß diese zusätzlichen Programme (am Ende sind es für GRX ohnehin dieselben wie für die VR9-Modelle, nur noch einmal unter anderem Pfad zugänglich und wenn da wirklich zusätzliche Binaries dabei waren, dann vielleicht die für x86/ATOM) nur ein Unfall waren und eher als "host tools" zu verstehen sind (also als Dateien für ein System, auf dem man das Modifizieren der Firmware ausführen läßt) und somit als der Versuch, "modfs" gerade für "foreign images" auch auf anderen Plattformen auszuführen (eben z.B. eine 7412-Firmware auf einer GRX-Box zu modifizieren) - was aber von mir verworfen wurde, weil dazu "modfs" erst einmal "lernen" müßte, nicht mehr von der Plattform, auf der es läuft, direkt auf das Zielsystem zu schließen und Annahmen zum Aufbau der zu modifizierenden Firmware direkt vom "build host" abzuleiten.

So macht es "modfs" nämlich bisher und wenn das tatsächlich funktioniert (also auf einer 7490 auch eine 7412-Firmware modifiziert werden kann), ist das nur der Tatsache geschuldet, daß beide Modelle denselben Aufbau beim Firmware-Image verwenden. Aber selbstverständlich habe ich mir das jetzt auch gerade eben als "Ausrede" einfallen lassen und mit irgendwelchen finsteren Komplizen dafür gesorgt, daß es so scheint, als stünde das schon seit Okt. 2017 in diesem Thread und setzt langsam Patina an.

Da, wo es wieder statthaft ist, vom Host auf den Aufbau der Firmware zu schließen ... da mache ich das auch, wie man am oben verlinkten "unpack_squashfs" auch sehen kann. Das ist eben dazu gedacht, auf der jeweiligen Box die eigene Firmware zu entpacken und damit sind solche Annahmen auch wieder valide.

Zu dem OT gibt es von mir keine Antwort.
Danke, Du mich auch ... wenn Du nicht einmal feststellen willst, daß es sich nur um eine Mißinterpretation Deiner "Gemütslage" handeln kann, die mir da unterlaufen ist, dann war ich wohl doch nicht so weit weg von der Wahrheit, wie man nach dem ersten Absatz aus #1363 (der ja noch um das "Nichts liegt mir ferner." im Nachhinein ergänzt wurde) hätte vermuten können - auch die Verweise auf Deine Textstellen habe ich mir ja nicht aus den Fingern gesogen.

Ansonsten ist es (um zu Deiner technischen Angelegenheit zu kommen) nur Deine eigene Interpretation, daß man beim "modfs" auch alles im RAM machen könne ... das ist aber frühestens seit der Existenz der GRX-Boxen überhaupt erst möglich (eigentlich erst seit der 7580, weil die 7560 auch nicht genug RAM hätte) und war niemals meine Intention beim Schreiben.

Nicht einmal bei der 7490 mit 256 MB RAM funktioniert das nämlich zuverlässig - häufig braucht es sogar bei diesem Modell (und sogar, wenn dabei das NAS-Verzeichnis zum Entpacken herangezogen wird anstelle eines Verzeichnisses im "tmpfs") eine Möglichkeit für virtuellen Speicher.

Ich habe auch nicht ganz umsonst in das Skript (zum Zeitpunkt seiner Entstehung) die interaktive Auswahl von verschiedenen USB-Volumes (wenn es mehr als einen Kandidaten dafür gibt) als Zwischenspeicher eingebaut ... was veranlaßt Dich also zu der Annahme, daß ein Arbeiten ausschließlich im RAM jemals vorgesehen war bei diesem Skript?

Und wo siehst Du im Lichte der Existenz dieser Vorkehrungen Deine obenstehende Annahme bestätigt, ich ginge immer von einem "unendlich großen Speicher" in der Box aus? Je nachdem, wofür ein solcher "Zwischenspeicher" gesucht wird (in "find_free_storage_space()"), gibt es sogar unterschiedliche Größen, die ein solcher Zwischenspeicher haben muß ... ich bin mir nämlich durchaus bewußt, daß es in einer FRITZ!Box da mehrere Kandidaten mit höchst unterschiedlichen Voraussetzungen gibt.

Ganz im Gegensatz zu Deiner Behauptung wurde von mir auch extra bei den Voraussetzungen darauf hingewiesen (siehe #1), daß (zumindest bei Boxen ohne ausreichend großen NAS-Flash) irgendwo mind. 256 MB auf einem USB-Volume zur Verfügung stehen sollten und nur bei der 7490 (die 3490 vergaß ich dabei tatsächlich zu erwähnen) an dessen Stelle auch die Benutzung des NAS-Flashs treten kann - auch wenn das eigentlich nicht zu empfehlen ist und schon wegen des benötigten virtuellen Speichers ein USB-Stick viel besser geeignet wäre.

Wenn Du Zwischenergebnisse früher löschen lassen möchtest (weil Du Deinen Spezialfall "im RAM" besser unterstützt sehen willst), ist es ja sicherlich kein Problem, eine "remove_directory"-Zeile (der Rest dessen, was dafür noch notwendig ist, ist bereits alles in dieser einen Funktion gekapselt) an den passenden Stellen einzufügen.

Zu #1370:
Du kannst ja einfach mal eine "filesystem.image" von einer 7580 an die Funktion "extract_rootfs_from_firmware()" im "modfs" verfüttern ... wenn das dann korrekt entpackt wird, berichtest Du einfach hier davon und läßt uns an dem Erfolg teilhaben.

Ansonsten verdrehst Du einfach meine Worte ... das Entpacken des Dateisystems IST einfacher, denn anders als bei den VR9-Modellen muß nicht erst noch das Root-Image aus einer Verpackung in Form eines "ext2"-Images (nach 06.5x) oder eines weiteren SquashFS-Images (vor 06.50) befreit werden, bevor man es entpacken kann - das ist dann auch noch genau der Punkt, an dem das o.a. "extract_rootfs_from_firmware()" scheitert und da - vor 06.50 eben - das durchaus auch mal ein SquashFS-Image als "Verpackung" war, ist auch die Tatsache, daß es sich nicht nur um einen "Dummy-SquashFS-Header" vor dem "ext2"-Image handelt (den man an der Version 0:0 sogar noch erkennen kann), noch lange kein sicheres Zeichen dafür, daß es stattdessen ein GRX- oder Puma-Image wäre.
 
Zuletzt bearbeitet:

eisbaerin

IPPF-Promi
Mitglied seit
29 Sep 2009
Beiträge
6,873
Punkte für Reaktionen
208
Punkte
63
ich ginge immer von einem "unendlich großen Speicher" in der Box aus?
Begreifst du es nicht oder willst du es nicht begreifen?
Weil man IMO Dateien, die nicht mehr gebraucht werden sofort löscht und nicht erst am Ende des scripts.
Insbesondere, wenn sie groß sind und insbesondere wenn man auf einer FB nur sehr begrenzten Speicher hat.

Aber du läßt die firmware.image und firmware.squash (oder so ähnlich) bis zum bitteren Ende bestehen und ich wundere mich, daß es zu Abbrüchen wegen Speichermangel kommt.

Und ich kann nur noch mal wiederholen:
Ich glaube kein anderer hat so oft modfs ausgeführt wie ich. ;)

Schade, daß es jetzt langsam stirbt. :(
IMO verlierst du jetzt deinen treusten Nutzer.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: Micha0815

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,160
Punkte für Reaktionen
753
Punkte
113
Du willst es ja offenbar nicht anders ... dann erkläre ich Dir das halt mal in einzelnen Schritten und hoffe damit, Dich von der Unhaltbarkeit dieser Vorwürfe zu überzeugen.

Mit "firmware.image" dürfte dann ja eine Datei gemeint sein, die als Ergebnis eines Downloads durch das Skript entstanden ist und den Namen aus der Variablen "firmwarestoragename" erhält. Ich finde jedenfalls im Skript keine andere Vorgabe eines solchen Dateinamens als in der verlinkten Zeile.

Darüber, daß eine solche Datei nur dann überhaupt automatisch gelöscht werden darf, wenn sie auch vom Skript erzeugt wurde, besteht ja hoffentlich Einigkeit - also schauen wir uns einmal an, wann diese Variable wo zum Erzeugen einer Datei verwendet wird und welche Vorkehrungen jeweils getroffen werden, Zwischendateien dann auch wieder abzuräumen, wenn sie nicht mehr benötigt werden. Angesichts Deiner oben zum Ausdruck gebrachten Theorie, habe ich ja ohne triftige Gründe darauf verzichtet, solche Zwischendateien zu diesem Zeitpunkt dann auch zu entsorgen.

Hier wird diese Variable jedenfalls zum ersten Mal zum Download einer Firmware-Datei verwendet - das ist der Fall, daß als Basis für die Modifikation (beim Aufruf ohne "update" als Parameter) eine neue Kopie vom Server des Anbieters verwendet werden soll. Dieser Punkt ist zwar fast in Vergessenheit geraten ... aber bei seiner Auswahl hat man zusätzlich die Chance, die hier geladene Firmware-Datei für spätere, wiederholte Verwendung an einer Stelle eigener Wahl (die sich allerdings auf die vorhandenen USB-Volumes und deren Wurzelverzeichnis beschränkt) abzulegen, damit man sie nicht jedesmal erneut laden muß.

Jedenfalls wird - vor dieser Frage nach der persistenten Speicherung - dann an dieser Stelle die geladene Firmware entpackt und zwar nur das dort enthaltene SquashFS-Image für das Root-Dateisystem, weil bei dieser Option bereits ein funktionierender Kernel in der alternativen Partition ebenso installiert sein muß, wie das Dateisystem im "wrapper"-Verzeichnis bereits vorhanden sein muß.

Nachdem dieses Extrahieren abgeschlossen ist (und das geladene Image in voller Schönheit nicht mehr benötigt wird), wird das gesamte Download-Verzeichnis in dieser Zeile auch bereits wieder gelöscht und im Anschluß erfolgt die Frage, ob das extrahierte SquashFS-Image für das Root-Filesystem für erneute Verwendung gespeichert werden soll. Wenn das jetzt geschieht, wird an dieser Stelle das extrahierte SquashFS-Image samt Verzeichnis wieder gelöscht, weil als Quelle dann der Ort dieser persistenten Speicherung verwendet wird ... soll es aber nicht gespeichert werden, kann es jetzt trotzdem noch nicht gelöscht werden, weil es ja noch entpackt werden muß.

Jedenfalls wurde hier die größere der beiden Dateien (nämlich das gesamte Firmware-Image) in jedem Falle schon wieder gelöscht (sofern kein Fehler auftrat, weil dann das Löschen automatisch beim "EXIT" erfolgen sollte) - ich weiß nicht genau, wie sich das mit dem von Dir geäußerten Vorwurf verträgt, ich würde mich nicht um das prompte Löschen von Dateien kümmern.

Der nächste Punkt, an dem die angesprochene "firmware.image" entstehen könnte, wäre diese Stelle ... hier würde ein Firmware-Image von AVM geladen, wenn man "modfs update" ohne Angabe eines lokalen Firmware-Images aufruft und eine neue Version bei AVM gefunden wurde. In den folgenden Zeilen wird dann aus diesem Image sowohl der Kernel als auch das Wrapper-Dateisystem und aus diesem dann wieder das Root-Dateisystem extrahiert (das sind hier ja komplett neue Dateien, die zusätzlich zum modifizierten Root-Dateisystem zu installieren sind, wenn die Modifikationen bis zur Installation fortgeführt werden) ... aber auch hier wird die zuvor geladene "firmware.image" (samt Download-Verzeichnis) in dem Moment wieder gelöscht, wo sie nicht mehr benötigt wird.

Ich weiß ja nicht, wo Du im "modfs"-Skript (bitte verlinke auf die Version aus dem Repository, falls Du die Stelle finden solltest) jetzt weitere Punkte siehst, an denen bei erfolgreichem Verlauf vom Skript eine Datei mit dem Namen "filesystem.image" (absichtlich, ich will Schreibfehler nicht generell ausschließen) erstellt wird ... aber die zweifellos auch vorhandenen Bemühungen (oder willst Du die von mir verlinkten Zeilen wegdiskutieren?) lassen Deine Behauptung
Aber du läßt die firmware.image und firmware.squash (oder so ähnlich) bis zum bitteren Ende bestehen und ich wundere mich, daß es zu Abbrüchen wegen Speichermangel kommt.
zumindest als "hinterfragenswert" erscheinen.

Sollte bei Dir tatsächlich bei normalem Verlauf eine Datei mit dem erstgenannten Namen bis zum Ende stehenbleiben (auf die zweite Datei gehe ich dann ein, wenn ich deren Namen konkret kenne ... ansonsten liefert meine Suche am Ende auch nur ein Ergebnis, was "oder so ähnlich" ist und dann war es am Ende gar nicht die von Dir kritisierte und ich habe noch einmal jede Menge zusätzliche Zeit vollkommen umsonst verplempert), dann wäre - wie bei jedem/jeder anderen auch - natürlich die Einsicht in das Debug-Protokoll extrem hilfreich ... dort wird ja auch jede dieser Aktionen vermerkt.

Vielleicht möchtest Du ja aber auch erst einmal etwas "herunterkühlen", bevor Du den nächsten Fehler findest ... für mich war jedenfalls die zusätzliche Beschäftigung mit "firmware.image" und die Suche nach der Stelle, die Deinem Vorwurf entsprechen könnte, daß ich keinerlei Vorkehrungen zum Entfernen solcher, nicht mehr benötigter Dateien treffen würde, keinesfalls so ergiebig, daß ich das ohne Protokoll noch einmal machen möchte.

Angesichts der oben festgestellten Vorkehrungen (und nach einem zusätzlichen Test beider Fälle) bleibt mir halt nur ein "works for me" ... es wäre also sehr nett von Dir, wenn Du (a) Deine Feststellung bzgl. des systematischen und reproduzierbaren Auftretens dieser Überbleibsel mit einem Protokoll untermauerst und (b) auch anerkennst, daß ansonsten durchaus die notwendigen Vorkehrungen zum Entfernen solcher Dateien getroffen wurden. Es mag sein, daß es irgendwo eine Stelle und eine Konstellation gibt, wo so eine Datei dann wirklich mal stehen bleibt infolge eines Fehlers ... das ist dann aber immer noch etwas vollkommen anderes als der von Dir - ohne wirkliche Substanz, wie man anhand der Vorkehrungen sehen kann - erhobene Vorwurf.
 

Igi2003

Mitglied
Mitglied seit
10 Feb 2005
Beiträge
495
Punkte für Reaktionen
7
Punkte
18
Ach Leute, streitet doch nicht. Ich sehe alle die hier ihre Boxen modden, egal ob Anfänger, Fortgeschrittener oder Profi, als eine Community, vergleichbar mit nem Autoclub. Hier sollten alle miteinander arbeiten, und nicht gegeneinander. Ich hatte die letzten Jahre nichts mehr gemacht, das letzte mal als aus dem alten ds-mod allmählich Freetz wurde und bin jetzt als wiedereinsteiger um wertvolle Tipps dankbar.

Und jetzt Handschlag drauf und weiter gehts ;-)
 

eisbaerin

IPPF-Promi
Mitglied seit
29 Sep 2009
Beiträge
6,873
Punkte für Reaktionen
208
Punkte
63
Ja, von mir Handschlag drauf!!!

Ich hoffe ja nur, daß Peter irgendwann begreift, daß ich nicht sein Feind, sondern sein Freund bin!
 
Zuletzt bearbeitet:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,160
Punkte für Reaktionen
753
Punkte
113
@eisbaerin:
Schau Dir mal #1372 bei derzeitigen Stand ganz genau an ... gibt Dir das nicht auch zu denken? Oder würdest Du am Ende auch (wie hier) in ein solches Horn stoßen?

Du läßt mir auch gar keine wirkliche Chance, wieder "runterzukommen" ... jedesmal legst Du gleich noch einen nach - in diesem Falle jetzt die "Drohung", ich würde meine/n treueste/n Nutzer/in verlieren. Was bringt das Dir jetzt genau?

Was nutzt mir wiederum eine "treue Nutzerin", wenn die auf meine Angebote nicht eingehen will (das eingebaute "contrib" gab es nun mal in erster Linie für Dich und Deine Änderung bei der 7412) und offenbar angesäuert ist, weil ich meine Pläne bezüglich der GRX-Modelle über den Haufen geworfen habe? Die ständigen Erinnerungen daran helfen jedenfalls weder Dir noch mir ... Du wirst ja nicht ernsthaft annehmen, daß man mich am Ende "weichklopfen" kann - und selbst dann sollte man IMHO eben aufpassen, wen man sich dabei zum Verbündeten wählt.

Wenn Du wirklich Interesse an einer sachlichen Auseinandersetzung hast (Du kannst bestimmt auch klarer formulieren, damit nicht soviele - auch mißverständliche - Interpretationsmöglichkeiten verbleiben), dann laß uns ganz sachlich Deiner Behauptung in #1372 nachgehen (am liebsten in ihrer "Ursprungsform", die sie hatte, als ich mit dem Schreiben von #1373 begann) ... ich habe meinerseits ja inzwischen haarklein aufgelistet, was ich dazu gesucht und gefunden habe. Sicherlich etwas genervt ob des Vorwurfs, nichtsdestotrotz bemüht sachlich und mit ordentlicher Verlinkung samt Erklärung, warum das meiner Meinung nach unhaltbar ist.

Ich bin aber - gerade auch angesichts der zusätzlichen, von mir jetzt investierten Zeit für die Überprüfung - nicht einfach so bereit, das Thema sofort wieder "beiseite zu schieben", ohne daß es wirklich zu einem Abschluß gekommen wäre.

Ich hoffe jedenfalls, daß Du nicht am Ende - wie andere vor Dir - einfach irgendwelche Beiträge komplett entfernen wirst, womit dann der Kontext und der Verlauf einer Auseinandersetzung nur noch anhand der Beiträge einer Seite nachvollziehbar ist ... aber auch auf diesem Wege hat ja der von mir oben verlinkte "Mitstreiter" es nicht geschafft, in meine Beiträge die von ihm behaupteten Anwürfe (er wäre DAU und ein wandelndes Layer8-Problem) zu projizieren, was das Gegeifere ja recht deutlich als Schaumschlägerei entlarvt.

Ich hatte es auch nicht nötig, an meinen Beiträgen dazu nachträglich herumzuändern oder gar komplette Beiträge zu entfernen und selbst beim heutigen Nachlesen kann ich praktisch nichts von dem in meinen Beiträgen auf der Seite 62 (die seit damals nun mal unverändert sind) finden, was ich ihm vorgeblich an den Kopf geworfen haben soll.
 

Anhänge

MatuAC

Neuer User
Mitglied seit
9 Jul 2007
Beiträge
73
Punkte für Reaktionen
1
Punkte
8
Hallo,
ich habe zuletzt mit modfs meine 7490 (nach dem Tipp von eisbaerin, "mod_show_vpn_on_overview" nicht zu benutzen, um auch wieder Inhalte auf der Startseite der Fritz!Box zu sehen - danke dafür!) problemlos auf die Beta-Firmware 51287.
Nun wollte ich auf die neue Beta 51497 updaten, erhalte aber beim Ausführen von modfs immer den Fehler "Permission denied".

Ich habe sowohl die bereits auf der Box vorhandene modfs-Version ausprobiert, als auch noch mal neu per wget runter geladen, in beiden Fällen das gleiche Problem.

Woran könnte das liegen?
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,160
Punkte für Reaktionen
753
Punkte
113
Seit einigen Labor-Versionen wird auch der interne Flash mit "noexec"-Option gemountet. Wer also die Dateien dort ablegen läßt (durch die Binärdateien ist das ja inzwischen in "bin/common" auf fast 12 MB angewachsen, wobei man die "*.24kc"-Dateien auch getrost löschen kann - die werden nur bei der 7390 benötigt und die wird gar nicht unterstützt), der muß mit einem zusätzlichen "mount -o remount,exec /var/media/ftp" zuvor noch das Ausführen von Dateien im NAS-Flash erlauben.
 

eisbaerin

IPPF-Promi
Mitglied seit
29 Sep 2009
Beiträge
6,873
Punkte für Reaktionen
208
Punkte
63
Das ist IMO Fehler 40!
Dazu braucht es noch genauere Angaben, wo und wie der Fehler Auftritt und entsteht.

@peter:
Ich dachte ja fälschlicherweise du wüstest besser als ich welche großen temporären Dateien du da anlegst.
Aber da du ja mal wieder so völlig naiv und ahnungslos tust:
Code:
7580:# ls -la
drwxr-xr-x    2 root     root           100 Feb 24 13:33 .
drwx------    9 root     root          2780 Feb 24 13:34 ..
-rw-r--r--    1 root     root      28352520 Feb 24 13:33 filesystem.image
-rw-------    1 root     root      25124864 Feb 15 16:54 filesystem_core.squashfs
-rw-r--r--    1 root     root       2702088 Feb 24 13:33 kernel.image
Diese Dateien und sogar der ganze Pfad können/sollten bei mir alle spätestens vor dem mksquashfs gelöscht werden, da sie alle nicht mehr gebraucht werden.
 
Zuletzt bearbeitet:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,160
Punkte für Reaktionen
753
Punkte
113
Ich dachte ja fälschlicherweise du wüstest besser als ich welche großen temporären Dateien du da anlegst.
Aber da du mal wieder so völlig naiv und ahnungslos tust und um deinem schleichend einsetzenden Alzheimer mal auf die Sprünge zu helfen:
Ich habe Dir haarklein aufgeschlüsselt, wo in "modfs" die Dateien geladen werden und wo sie dann auch wieder gelöscht werden sollten. Insofern dachtest Du da gar nicht so falsch ... und wenn das von Dir gezeigte "Schnipselchen" nach der Ausführung von "modfs" den Stand im Dateisystem zeigt, schaue ich auch gerne (wie oben bereits bemerkt, aber vielleicht hast Du es ja tatsächlich nur überlesen und nicht bewußt ignoriert) in Dein Protokoll, wo das Löschen offenbar fehlgeschlagen ist. Meiner Aufforderung oder Bitte, mir dann doch die Stelle aufzuzeigen, an der von "modfs" eine "firmware.image" erzeugt wird (und von der hast Du irgendwo weiter oben geschrieben) und wo nicht gleichzeitig (bei "geplantem Verlauf") diese Datei so zeitnah wie möglich wieder abgeräumt wird, wurde ja offenbar dasselbe Schicksal zuteil, wie der Frage nach der Protokoll-Datei.

Wenn Du also irgendeine (fachliche) Reaktion auf Deine fortgesetzten Frechheiten erwarten solltest (ich finde das mit "Alzheimer" keinesweg so witzig, wie Du es offenbar sehen möchtest), dann gehört da ein Protokoll dazu - ich kann mir nämlich keine Erklärung dazu aus den Fingern saugen, warum bei Dir die "filesystem.image" weiterhin besteht.

Ja, man kann hier nicht einmal erkennen, was Du da wo genau aufgerufen hast - wenn Du also auf diese "Meldung" eines Fehlers überhaupt eine Antwort haben möchtest, muß schon Deinerseits auch noch ein Protokoll hinzugefügt werden oder Du wartest einfach, bis meine spiritistische Beraterin aus ihrem Urlaub in Delphi zurück ist und ich mir dort nähere Informationen holen kann.
 
Zuletzt bearbeitet:

eisbaerin

IPPF-Promi
Mitglied seit
29 Sep 2009
Beiträge
6,873
Punkte für Reaktionen
208
Punkte
63
Also manchmal weiß ich wirklich nicht wie komisch du dich anstellst.
Es gibt bei dem modfs script nur eine Stelle wo es vor dem mksquashfs anhält und die sieht so aus, falls du das noch nie gesehen hast:
Code:
Das ist die letzte Chance zum manuellen Modifizieren des Dateisystems in folgendem Verzeichnis: /var/tmp/1519475618/squashfs-root

Die Eingabetaste drücken, um mit dem Packen des neuen root-Dateisystems zu beginnen
oder 'q' eingeben, um die letzte Möglichkeit zum Abbruch zu nutzen :
Und genau zu diesem Zeitpunkt sind die oben erwähnten IMO unnötigen Dateien noch vorhanden, obwohl sie IMO schon wesentlich eher gelöscht werden könnten.
 
Zuletzt bearbeitet:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,160
Punkte für Reaktionen
753
Punkte
113
Und ich weiß immer noch nicht, wie ich "modfs" aufrufen soll, um diese Situation nachzustellen - beim Aufruf mit "modfs update" steht sie zum von Dir erwähnten Zeitpunkt nicht mehr da ... falls Du es noch nie gesehen hast: Es gibt durchaus mehrere Möglichkeiten des Aufrufs von "modfs" mit verschiedenen Parametern - aber warum soll ich das in #1378 dazu bereits Geschriebene noch einmal wiederholen?

Die klare Ansage ist: "Fehlersuche mit Protokoll" (dafür habe ich es schließlich eingebaut) und da schadet es auch nichts, wenn das ein Protokoll ist, aus dem man Dein "Speicherplatzproblem" erkennen kann ... das war immerhin die - inzwischen nach diversen Änderungen und Korrekturen (sowohl von Dateinamen als auch ein Zusammenlegen von Beiträgen, wodurch die Zeitstempel Deiner nachträglichen Änderungen an den Einzelbeiträgen nicht mehr ersichtlich sind - hier hat mir die Moderation dann einen Bärendienst erwiesen) - kaum noch erkennbare Ausgangslage in #1368. Oder ist dieses Protokoll in irgendeiner Weise "geheim"? Wenn ja, welche Angaben sollte ich dort auslassen, damit es diesen Status verlieren kann?

In diesem Fall bin ich jedenfalls auch mehr als froh, daß ich #1378 auf das - nachträglich von mir um 13:58 Uhr erst eingefügte - wörtliche Zitat nicht verzichtet habe (obwohl es direkt darüber stand) ... denn Du hast ja Deinerseits das Alzheimer-Thema wieder still und heimlich aus #1377 entfernt (um 14:36 Uhr, dem Zeitstempel nach zu urteilen). Entweder man sieht das selbst als Fehlgriff an und steht trotzdem dazu oder man streicht es auf diese feige Art und Weise, bei der dann der zweite Absatz in meinem Beitrag unmittelbar den Kontext verliert und damit so wirkt, als würde ich meinerseits immer wieder Öl ins Feuer gießen.

Wenn es Dir tatsächlich peinlich gewesen sein sollte als "Ausrutscher", wäre das mit einer Streichung (und vielleicht einem oder zwei Sätzen dazu) auch "ehrlicher" aus der Welt zu schaffen gewesen. Daß auch zuvor schon diverse Änderungen an den vorhergehenden Beiträgen von Dir vorgenommen wurden (und zwar lange nach dem Erstellen, was die Korrektur von Fehlern beim Lesen ja eher unwahrscheinlich erscheinen läßt - das halte ich noch für plausibel, wenn es innerhalb von 10-15 Minuten erfolgt), habe ich in #1374 ja auch schon angemerkt ... ich weiß ja nicht, wie weit Du das treiben möchtest, kündige aber gleichzeitig schon mal an, daß ich solche Stellen von jetzt an (zuvor habe ich es leider versäumt) auch dann als Zitat aufnehmen werde, wenn sie direkt im Beitrag darüber stehen. Ich markiere zwar auch nicht jede Änderung innerhalb kurzer Zeit (in #1378 hatte ich mich tatsächlich von Deinem plötzlichen Wechsel des Dateinamens von "firmware.image" auf "filesystem.image" einmal zuviel anstecken lassen), aber ich vermeide (nach Kräften) sinnentstellende Änderungen oder mache die dann kenntlich.

Wie Du Dich da jedenfalls noch fragen kannst:
Also manchmal weiß ich wirklich nicht wie komisch du dich anstellst.
, erschließt sich mir auch nicht wirklich ... das ist am Ende nur noch ätzend, was Du hier treibst und Du willst es offensichtlich auch nicht gut sein lassen.

Wenn da tatsächlich noch irgendein Interesse an der Beseitigung eines Problems sein sollte, was sich auch bei "bestimmungsgemäßem Gebrauch" zeigt und nicht nur Deiner Interpretation dessen geschuldet ist, was ich irgendwo und irgendwann mal geschrieben haben soll (und von dem Du ja ohnehin nur die Hälfte glaubst), dann steht es Dir frei, mit einem passenden Protokoll diesen Fehler aufzuzeigen.

Und selbst dann, wenn das eine Änderung oder Erweiterung sein sollte, stehe ich dem durchaus aufgeschlossen gegenüber, solange es sich um eine Verbesserung für alle handelt. Weitere Änderungen auf persönlichen Wunsch von @eisbaerin wird es jedenfalls nicht mehr geben (sowohl die generelle Behandlung von "fremden Images" als auch die "contrib"-Möglichkeit wurden auf Deine Bitte hin eingebaut) - ansonsten steht das gesamte Projekt unter GPLv2 und es steht Dir ebenso wie jedem/jeder anderen frei, da eigene Änderungen vorzunehmen und diese sogar wieder zu publizieren, wenn man möchte und der Meinung ist, daß auch andere davon profitieren könnten.

Ich hoffe ja nur, daß Peter irgendwann begreift, daß ich nicht sein Feind, sondern sein Freund bin!
Ich denke mal, wer solche Freunde hat, braucht gar keine Feinde mehr - das habe ich zumindest irgendwann begriffen.
 

3CX PBX - GRATIS
Linux / Win / Cloud

Neueste Beiträge

Statistik des Forums

Themen
232,893
Beiträge
2,027,819
Mitglieder
351,017
Neuestes Mitglied
mucfaber