@muellmann4, hattest du einen USB-Stick mit einem SWAP verwendet, Größe mind. 512 MB? Wenn nicht, dann hast du Glück gehabt, dass modfs überhaupt lief.
[Info] modfs - SquashFS-Image (AVM-Firmware) ändern für NAND-basierte FRITZ!Boxen
- Ersteller PeterPawn
- Erstellt am
Hallo jono! Nein - hatte ich nicht. Soweit ich verstanden hatte, ist dies auch nur nötig um 7.01 drauf zu bekommen und hat mit meinem "Problem" bzw. meiner "Unwissenheit" hier Telnet wieder zu bekommen erstmal Nichts zu tun. Denn ich wollte dann schon am Ende des Tages einen USB-Stick mit meinen Daten für den Mediaserver anstecken...
Nun: 7.01 ist drauf... aber wie komme ich an Telnet?
Nun: 7.01 ist drauf... aber wie komme ich an Telnet?
? Also ich bin vor bestimmt 1,5 wenn nicht schon vor 2 Jahren mal den Weg über ShellInABox gegangen - aber danach immer nur über den Weg des "normalen" Telnet, da ich die Webseitenzugriffe nicht nur nicht mag sondern auch den Weg Telnet schlicht ein- und auszuschalten (immer wenn es ich benötige) zu können immer sehr geschätzt habe.
Davon einmal abgesehen - würden denn bei 7.01 immer noch ein inject von ShellInABox funktionieren? [sorry - habe mich damit schon ewig nicht mehr auseinandergesetzt]
Davon einmal abgesehen - würden denn bei 7.01 immer noch ein inject von ShellInABox funktionieren? [sorry - habe mich damit schon ewig nicht mehr auseinandergesetzt]
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
90 Minuten kann "modfs" aber fast nicht brauchen, wenn die Box technisch in Ordnung ist.
Ohne spezielle Parameter beim Aufruf wird eben (absichtlich) kein Arbeitsverzeichnis mehr im NAS-Flash verwendet (habe ich in #1494 beschrieben) - damit wird aber die Geschwindigkeit des verwendeten USB-Speichers wichtiger und wer hier mit einem USB-Adapter für µSD-Karten mit sehr geringer Schreibrate arbeitet, der wartet schon beim Entpacken der Firmware praktisch endlos (um mal ein Beispiel zu nennen). Wenn das dann auch noch ein USB-Volume mit dem falschen Dateisystem ist und der ext3-Container ausgepackt werden muß, dann geht das allerdings richtig in den Keller ... nur ist das auch die Schuld des Benutzers und daran kann "modfs" nichts ändern, der Benutzer aber sehr wohl.
-----------------------------------------------------------------------------------------------------------
Ein vernünftiger USB-Stick mit akzeptabler Schreibrate und Platz für den Swap-Space (am besten als Partition, aber wie das mit einer Datei auch ginge, habe ich kürzlich (innerhalb der letzten 3 Monate) noch einmal ausführlich gezeigt) ist Grundvoraussetzung für die Benutzung von "modfs" ... dabei spielt es auch gar keine Rolle, von welcher Version man auf welche aktualisieren will. Schon um diese Diskussionen gar nicht erst aufkommen zu lassen, gilt das als "Faustregel": Kein Swap-Space, kein "modfs".
Funktioniert es trotzdem, ist das pures Glück und kann von so vielen Umständen abhängen (weil die AVM-Firmware eben auch einen unterschiedlichen Speicherbedarf im RAM hat, je nachdem, was man von den Funktionen alles nutzt), daß man das bitte nicht verallgemeinern sollte und selbst bei der eigenen Box kann es beim nächsten Versuch problemlos schiefgehen, wenn es eben noch funktioniert hat.
Ich bin jedenfalls nicht wirklich bereit, mich mit Fehlfunktionen zu befassen, die in "Abwesenheit" von Swap-Space auftreten ... und ich will noch einmal ausdrücklich an die Debug-Ausgabe erinnern, die Voraussetzung für das Eingrenzen von Fehlern ist, weil "raten" eher suboptimal ist als Strategie bei der Fehlersuche und nur unnötig Zeit kostet, selbst wenn man ggf. richtig läge.
-----------------------------------------------------------------------------------------------------------
Der Shell-Zugriff per "telnet" braucht zwei Faktoren ... einmal den Symlink unter "/usr/sbin/telnetd" für den Daemon, wenn man die AVM-BusyBox verwendet, in der die Existenz dieses Symlinks durch einen zusätzlichen Patch geprüft wird - EDIT: dieser Symlink wird mit "mod_telnet_enable" erstellt.
Die andere Voraussetzung ist es, daß jemand diesen Daemon dann auch startet ... und das macht die AVM-Firmware ab Labor 06.98 nicht mehr, wenn man nichts weiter ändert.
Also gibt es drei Möglichkeiten, diesen Start dennoch ausführen zu lassen:
Ohne spezielle Parameter beim Aufruf wird eben (absichtlich) kein Arbeitsverzeichnis mehr im NAS-Flash verwendet (habe ich in #1494 beschrieben) - damit wird aber die Geschwindigkeit des verwendeten USB-Speichers wichtiger und wer hier mit einem USB-Adapter für µSD-Karten mit sehr geringer Schreibrate arbeitet, der wartet schon beim Entpacken der Firmware praktisch endlos (um mal ein Beispiel zu nennen). Wenn das dann auch noch ein USB-Volume mit dem falschen Dateisystem ist und der ext3-Container ausgepackt werden muß, dann geht das allerdings richtig in den Keller ... nur ist das auch die Schuld des Benutzers und daran kann "modfs" nichts ändern, der Benutzer aber sehr wohl.
-----------------------------------------------------------------------------------------------------------
Ein vernünftiger USB-Stick mit akzeptabler Schreibrate und Platz für den Swap-Space (am besten als Partition, aber wie das mit einer Datei auch ginge, habe ich kürzlich (innerhalb der letzten 3 Monate) noch einmal ausführlich gezeigt) ist Grundvoraussetzung für die Benutzung von "modfs" ... dabei spielt es auch gar keine Rolle, von welcher Version man auf welche aktualisieren will. Schon um diese Diskussionen gar nicht erst aufkommen zu lassen, gilt das als "Faustregel": Kein Swap-Space, kein "modfs".
Funktioniert es trotzdem, ist das pures Glück und kann von so vielen Umständen abhängen (weil die AVM-Firmware eben auch einen unterschiedlichen Speicherbedarf im RAM hat, je nachdem, was man von den Funktionen alles nutzt), daß man das bitte nicht verallgemeinern sollte und selbst bei der eigenen Box kann es beim nächsten Versuch problemlos schiefgehen, wenn es eben noch funktioniert hat.
Ich bin jedenfalls nicht wirklich bereit, mich mit Fehlfunktionen zu befassen, die in "Abwesenheit" von Swap-Space auftreten ... und ich will noch einmal ausdrücklich an die Debug-Ausgabe erinnern, die Voraussetzung für das Eingrenzen von Fehlern ist, weil "raten" eher suboptimal ist als Strategie bei der Fehlersuche und nur unnötig Zeit kostet, selbst wenn man ggf. richtig läge.
-----------------------------------------------------------------------------------------------------------
Der Shell-Zugriff per "telnet" braucht zwei Faktoren ... einmal den Symlink unter "/usr/sbin/telnetd" für den Daemon, wenn man die AVM-BusyBox verwendet, in der die Existenz dieses Symlinks durch einen zusätzlichen Patch geprüft wird - EDIT: dieser Symlink wird mit "mod_telnet_enable" erstellt.
Die andere Voraussetzung ist es, daß jemand diesen Daemon dann auch startet ... und das macht die AVM-Firmware ab Labor 06.98 nicht mehr, wenn man nichts weiter ändert.
Also gibt es drei Möglichkeiten, diesen Start dennoch ausführen zu lassen:
- man startet den "telnetd" einfach selbst an einer anderen Stelle (Nachteil ist, daß der dann immer aktiv ist), dafür gibt es den Patch "mod_telnet_start", den man aber erst selbst aktivieren muß, weil er sonst gar nicht angeboten wird - wie das über die Dateirechte oder eine "custom_modscripts"-Datei funktioniert, habe ich mehrfach beschrieben
- man verwendet einen anderen Telefon-Code für das Starten und Stoppen des "telnetd", dafür gibt es den Patch "mod_telnet_start_as_dtrace" - auch der ist deaktiviert und muß erst vom Benutzer passend aktiviert werden
- man benutzt den "telefon"-Daemon im "privaten Modus", der mit dem "mod_enable_calllog" eingeschaltet wird - hier ist der Start des "telnetd" und die Verfügbarkeit der Telefon-Codes zu dessen Steuerung dann eher eine Nebenwirkung des "privaten Modus" und es gibt zumindest einen Nachteil ... der Inhalt der "/var/flash/calllog" wird bei jedem eingehenden Anruf ausgeführt und wenn man diese Datei (wie ich) gerne mal für andere Zwecke verwendet (weil die AVM-Firmware sie ex- und importiert und sie ansonsten nicht weiter genutzt wird, wenn der "private Modus" nicht aktiv ist), dann kann das zu Unverträglichkeiten führen
Zuletzt bearbeitet:
Hallo,
ich brächte bitte euer Hilfe/Rat.
Ich hab die FB 7362SL per modfs auf die 7.01 geupdatet.
Soweit so gut, einziges Problem das ich aktuell habe ist das der integrierte gui_bootmanager nicht angezeigt wird.
Unter "System->Sicherung->Neustart" steht hier
Statt das die Auswahl des zu-bootenden Systems angezeigt wird
Die Berechtigung kann ich nicht ändern da das Filesystem Read-Only ist.
Kann ich dieses irgendwie kurzfristig RW mounten um die Berechtigungen anzupassen?
---------------EDIT-----------------
habs selber gelöst, handisch vor dem flashen die Berechtigung korrigiert
ich brächte bitte euer Hilfe/Rat.
Ich hab die FB 7362SL per modfs auf die 7.01 geupdatet.
Soweit so gut, einziges Problem das ich aktuell habe ist das der integrierte gui_bootmanager nicht angezeigt wird.
Unter "System->Sicherung->Neustart" steht hier
Code:
Sie können hier die FRITZ!Box neu starten.
Hinweis:
Beim Neustart werden die Ereignismeldungen gelöscht. Alle Einstellungen der FRITZ!Box bleiben erhalten.
sh: /usr/bin/gui_bootmanager: Permission deniedStatt das die Auswahl des zu-bootenden Systems angezeigt wird
Die Berechtigung kann ich nicht ändern da das Filesystem Read-Only ist.
Kann ich dieses irgendwie kurzfristig RW mounten um die Berechtigungen anzupassen?
---------------EDIT-----------------
habs selber gelöst, handisch vor dem flashen die Berechtigung korrigiert
Zuletzt bearbeitet:
Micha0815
IPPF-Promi
- Mitglied seit
- 25 Feb 2008
- Beiträge
- 5,344
- Punkte für Reaktionen
- 467
- Punkte
- 83
@muellmann4
lädt das "alte" modfs.tgz in der "modfs_version=0.4.6-280220180003" herunter was imho mit der 7.01 nicht klarkommt.
Persönlich bin ich zu blond herauszufinden via Browser http://yourfritz.de auf welche Version da verlinkt wird und wie diese Version wohl korrekt heissen mag.
Btw. schlägt der Wechsel zwischen 6.93<->7.01 via GUI-Bootauswahl dahingehend fehl, dass die Internetverbindung (hier WLAN-Repeater->WLAN-Master via 5GHz-Netz) fehlt. Ich muss stets erst das 5GHz-Netz neu suchen lassen um die Internet-Verbindung neu aufbauen zu können. Ähnliches wurde ja auch für DSL-Verbindung berichtet. Eigentlich sollten die Einstellungen im TFFS ja für beide Partitionen gelten.
LG
Edit:
Bingo @freshgodfather
Ich hatte Dein Post nicht richtig interpretiert Hast Du das Packen mit dem grossen "Q" unterbrochen und dann in dem Auspackverzeichnis die Rechte geändert? Und wie lässt man das script dann zwecks Packen und flashen und aktivieren der alternativen Partition weiterlaufen?
//edit by stoney: Bild geschrumpft
Code:
mkdir -p /var/mod;cd /var/mod;wget -qO- http://yourfritz.de/modfs.tgz | gunzip -c | tar xPersönlich bin ich zu blond herauszufinden via Browser http://yourfritz.de auf welche Version da verlinkt wird und wie diese Version wohl korrekt heissen mag.
Code:
wget -qO- http://yourfritz.de/modfs-0.5.0-beta.tgz ... modfs-masterBtw. schlägt der Wechsel zwischen 6.93<->7.01 via GUI-Bootauswahl dahingehend fehl, dass die Internetverbindung (hier WLAN-Repeater->WLAN-Master via 5GHz-Netz) fehlt. Ich muss stets erst das 5GHz-Netz neu suchen lassen um die Internet-Verbindung neu aufbauen zu können. Ähnliches wurde ja auch für DSL-Verbindung berichtet. Eigentlich sollten die Einstellungen im TFFS ja für beide Partitionen gelten.
LG
Edit:
Bingo @freshgodfather
Ich hatte Dein Post nicht richtig interpretiert
Hast Du das Packen mit dem grossen "Q" unterbrochen und dann in dem Auspackverzeichnis die Rechte geändert? Und wie lässt man das script dann zwecks Packen und flashen und aktivieren der alternativen Partition weiterlaufen?//edit by stoney: Bild geschrumpft
Zuletzt bearbeitet von einem Moderator:
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Die falschen Permissions für /usr/bin/gui_bootmanager sind das Ergebnis des Einpackens ... da ich die bei mir eigentlich schon mit der richtigen UID/GID gespeichert habe in "files", habe ich auf die zusätzlichen "chown"- und "chmod"-Aufrufe verzichtet und wollte mittels "cp -a" eigentlich die Attribute alle mitkopieren. Nur klappt das halt nicht, wenn schon die Quelle keine "x-Flags" mehr hat ... vermutlich war auch hier wieder "git" Schuld beim Einchecken des "gui_bootmanager"-Files im "modfs"-Repo. Ich habe das "modscript" für den Boot-Manager entsprechend ergänzt ... nicht nur um das explizite Setzen der Attribute, sondern auch um die Prüfung im "postcheck", daß Owner und Attribute wie erwartet gesetzt sind. Allerdings ist diese Änderung noch ungetestet ... manchmal hat man ja auch Tomaten auf den Augen bei einer Änderung. Also muß auch das noch getestet werden.
-------------------------------------------------------------------------------------------------------
Beim Modifizieren einer 07.01 (bzw. 06.98-Labor) von einer früheren Version aus, sollte die alte Version (in Grenzen, weil nicht alle Patches funktionieren) durchaus arbeiten können ... das ist dieselbe Situation, wie sie bis zum Erscheinen des 07.01-Release bestand.
In der Beta sind geänderte Patches enthalten, die u.a. auch Änderungen in der 07.01 berücksichtigen und damit beim Modifizieren der 07.01 auch ein besseres Ergebnis liefern ... man muß halt immer zwischen dem Framework (das ist das "modfs"-Skript mit dem Kram drumherum, der nicht im "modscripts"-Verzeichnis steht) und den eigentlichen Patches (das sind dann die Skripte in "modscripts") unterscheiden. Wenn ich die in einer Datei zusammenpacke, ist das nur für größere Bequemlichkeit beim Benutzen ... rein theoretisch besteht da kein direkter Zusammenhang und für das "modfs"-Paket an sich ist es wichtig, daß es die Plattform unterstützt, auf der es ausgeführt wird, während es für die Patches wichtiger ist, daß sie die Version des Zielsystems (also die zu modifizierende Version) unterstützen. Da das zwei Paar Schuhe sind, kann man mit "besser unterstützt" nur schwer argumentieren.
-------------------------------------------------------------------------------------------------------
Ich kann aber gerne den "Beta-Status" für die 0.5.0 aufheben und von "modfs.tgz" dahin verlinken ... bisher war ich noch nicht der Ansicht, daß ich "fertig" wäre. Aber ich kann auch einfach eine Version dazwischen schieben ... wenn es keine größeren Probleme mit der "Beta" bisher gab. Dann wandert die "Installation" als signiertes Image halt in die nächste Versionsnummer.
Ich selbst habe damit allerdings in den vergangenen zwei Wochen bestimmt 30-40x sowohl die 06.93 als auch die 07.01 für die 7490 modifiziert (wenn auch nicht jede dieser Modifikationen am Ende installiert wurde) und dabei keine weiteren Probleme mit der Beta gefunden (das Permissions-Problem ist inzwischen gelöst, s.o.) bzw. habe die dann gleich entsprechend gefixt.
Dabei habe ich aber auch festgestellt, daß es bei mir keinerlei Probleme bereitet, zwischen einer 07.01 und einer 06.93 hin und her zu springen (auch die verwendete Konfiguration macht nicht wirklich Probleme), allerdings läuft die Box als LAN1-Router. Auch der Wechsel zwischen der deutschen und der internationalen Version (der 07.01) klappt problemlos - wenn ich das Branding fest setzen lasse, sogar auf der 7580 (auch wenn die von "modfs" nicht direkt unterstützt wird, geht es mir hier um den Boot-Manager).
Wobei man natürlich auch davon ausgehen kann, daß bei allem, was mit WLAN und Mesh in Verbindung zu bringen ist, die Unterschiede zwischen 06.93 und 07.01 ausreichend groß sind, daß ein nahtloser Wechsel eben nicht möglich ist ... solange es "nur" die normalen WLAN-Funktionen betrifft, ist das aber auch kein Problem, zumindest nicht bei mir hier.
Wenn niemand mehr größere Probleme berichtet, gibt's die 0.5.0-beta (in der Pause zwischen den beiden NFL-Spielen) nachher noch als "Release" ... aber damit wäre dann die Auslieferung der 0.4.6 über "yourfritz.de" auch Geschichte und jeder, der die ältere Version haben will (die für Boxen ohne 07.0x ja auch noch "gängig" wäre), müßte sie sich selbst aus dem älteren Stand im Repo zusammenstellen - daß bzw. warum ich nur noch eine einzige Version (abgesehen von der Beta für die nächste) über "yourfritz.de" bereitstelle, habe ich schon früher erläutert.
-------------------------------------------------------------------------------------------------------
Beim Modifizieren einer 07.01 (bzw. 06.98-Labor) von einer früheren Version aus, sollte die alte Version (in Grenzen, weil nicht alle Patches funktionieren) durchaus arbeiten können ... das ist dieselbe Situation, wie sie bis zum Erscheinen des 07.01-Release bestand.
In der Beta sind geänderte Patches enthalten, die u.a. auch Änderungen in der 07.01 berücksichtigen und damit beim Modifizieren der 07.01 auch ein besseres Ergebnis liefern ... man muß halt immer zwischen dem Framework (das ist das "modfs"-Skript mit dem Kram drumherum, der nicht im "modscripts"-Verzeichnis steht) und den eigentlichen Patches (das sind dann die Skripte in "modscripts") unterscheiden. Wenn ich die in einer Datei zusammenpacke, ist das nur für größere Bequemlichkeit beim Benutzen ... rein theoretisch besteht da kein direkter Zusammenhang und für das "modfs"-Paket an sich ist es wichtig, daß es die Plattform unterstützt, auf der es ausgeführt wird, während es für die Patches wichtiger ist, daß sie die Version des Zielsystems (also die zu modifizierende Version) unterstützen. Da das zwei Paar Schuhe sind, kann man mit "besser unterstützt" nur schwer argumentieren.
-------------------------------------------------------------------------------------------------------
Ich kann aber gerne den "Beta-Status" für die 0.5.0 aufheben und von "modfs.tgz" dahin verlinken ... bisher war ich noch nicht der Ansicht, daß ich "fertig" wäre. Aber ich kann auch einfach eine Version dazwischen schieben ... wenn es keine größeren Probleme mit der "Beta" bisher gab. Dann wandert die "Installation" als signiertes Image halt in die nächste Versionsnummer.
Ich selbst habe damit allerdings in den vergangenen zwei Wochen bestimmt 30-40x sowohl die 06.93 als auch die 07.01 für die 7490 modifiziert (wenn auch nicht jede dieser Modifikationen am Ende installiert wurde) und dabei keine weiteren Probleme mit der Beta gefunden (das Permissions-Problem ist inzwischen gelöst, s.o.) bzw. habe die dann gleich entsprechend gefixt.
Dabei habe ich aber auch festgestellt, daß es bei mir keinerlei Probleme bereitet, zwischen einer 07.01 und einer 06.93 hin und her zu springen (auch die verwendete Konfiguration macht nicht wirklich Probleme), allerdings läuft die Box als LAN1-Router. Auch der Wechsel zwischen der deutschen und der internationalen Version (der 07.01) klappt problemlos - wenn ich das Branding fest setzen lasse, sogar auf der 7580 (auch wenn die von "modfs" nicht direkt unterstützt wird, geht es mir hier um den Boot-Manager).
Wobei man natürlich auch davon ausgehen kann, daß bei allem, was mit WLAN und Mesh in Verbindung zu bringen ist, die Unterschiede zwischen 06.93 und 07.01 ausreichend groß sind, daß ein nahtloser Wechsel eben nicht möglich ist ... solange es "nur" die normalen WLAN-Funktionen betrifft, ist das aber auch kein Problem, zumindest nicht bei mir hier.
Wenn niemand mehr größere Probleme berichtet, gibt's die 0.5.0-beta (in der Pause zwischen den beiden NFL-Spielen) nachher noch als "Release" ... aber damit wäre dann die Auslieferung der 0.4.6 über "yourfritz.de" auch Geschichte und jeder, der die ältere Version haben will (die für Boxen ohne 07.0x ja auch noch "gängig" wäre), müßte sie sich selbst aus dem älteren Stand im Repo zusammenstellen - daß bzw. warum ich nur noch eine einzige Version (abgesehen von der Beta für die nächste) über "yourfritz.de" bereitstelle, habe ich schon früher erläutert.
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Da keine weiteren Fehler berichtet wurden, ist ab sofort die Version 0.5.0 aktiv und als "modfs.tgz" verlinkt. Die ältere 0.4.6 ist damit obsolet und müßte bei Bedarf aus dem "modfs"-Repo selbst zusammengestellt werden (am richtigen Commit dann natürlich).
Gegenüber der Beta-Version hat dieses Release noch folgende Änderungen erfahren:
Es wird jetzt getestet, ob mind. 256 MB Swap-Space verfügbar sind - ist das nicht der Fall, wird die Ausführung abgebrochen. Wer diese Prüfung absichtlich übergehen und trotzdem keinen Swap-Space bereitstellen will (dann aber bitte auch nicht mit entsprechenden Fehlerberichten hier auflaufen - zur Ausführung ohne Swap-Space steht weiter oben meine Warnung), der muß sicherstellen, daß für das Skript die Environment-Variable
gesetzt ist. Man kann die Prüfung also übergehen, aber man sollte es nicht tun.
Beim Start von "modfs" wird versucht, anhand der Kernel-Version des Host-Systems die passenden Binärdateien zu finden und - wenn die vorhanden sind und nicht mit den aktuell verlinkten übereinstimmen - den Link im "bin"-Unterverzeichnis von "modfs" entsprechend anzupassen. Damit sollten auf einer 07.01 als Host für "modfs" auch die Dateien für diese Version genutzt werden - selbst wenn die eigentlich alle statisch gelinkt sein sollten.
Der Abbruch vor dem Einpacken unter Beibehalten der modifizierten Dateistruktur ist auch mit der Environment-Variablen "MODFS_ABORT_BEFORE_PACK=Q" steuerbar.
--------------------------------------------------------------------------------------------------------------
Auch wenn sich die Frage nicht an mich richtete ... wie man die Dateistruktur vor dem Einpacken noch zusätzlich modifizieren kann, habe ich hier vor gar nicht soo langer Zeit noch einmal ausgeführt: https://www.ip-phone-forum.de/threads/modfs-squashfs-image-avm-firmware-ändern-für-nand-basierte-fritz-boxen.273304/page-73#post-2295245
--------------------------------------------------------------------------------------------------------------
Weiter geht es jetzt mit 0.5.1-beta, wenn jemand neue Versionen testen möchte. Ich werde das Bereitstellen neuer Beta-Versionen dann weiterhin hier ankündigen.
--------------------------------------------------------------------------------------------------------------
EDIT:
Ich habe mal die aktuellen Ausführungszeiten von "modfs" (scharf und "mit allem") auf (m)einer 7490 gemessen. Dabei kommt eine ältere PATA-HDD (WD Scorpio, WD2500BEVE-00WZT0) in einem USB2-Gehäuse mit Prolific-Wandler-Chip (067b:2506) zum Einsatz, die neben einer 4 GB Swap-Partition noch zwei Partitionen mit jeweils einem ext3-Dateisystem enthält. Als Arbeitsverzeichnis wird eines dieser Volumes benutzt. Das "modfs"-Verzeichnis mit dem Inhalt des Archivs von yourfritz.de befindet sich auf der anderen ext3-Partition.
Die gesamte Ausführung (weitgehend automatisch, also nur in sehr geringem Maße von Reaktionszeiten bei Fragen beeinflußt) dauerte keine 7' 15" - das Packen brauchte alleine schon 6' 10" davon.
Welche von mehreren, entsprechend ungünstigeren Bedingungen jetzt wieviel Zeit zusätzlich kostet (langsamerer USB-Speicher bei Schreibzugriffen, falsches Dateisystem), weiß ich auch nicht ... aber die Scorpio ist nun auch nicht die schnellste denkbare HDD, erst recht nicht mit dem Prolific-Wandler mit USB2. Aber 90 Minuten sind dann doch schon sehr heftig und mir fehlt etwas die Phantasie, wo die Zeit bleiben sollte. Das Debug-Protokoll ist aber auch hier hilfreich ... es enthält ja auch für jeden Eintrag eine Uhrzeit und so kann man zumindest mal sehen, wo die größten Lücken zwischen zwei Einträgen auftauchen:
Gegenüber der Beta-Version hat dieses Release noch folgende Änderungen erfahren:
Es wird jetzt getestet, ob mind. 256 MB Swap-Space verfügbar sind - ist das nicht der Fall, wird die Ausführung abgebrochen. Wer diese Prüfung absichtlich übergehen und trotzdem keinen Swap-Space bereitstellen will (dann aber bitte auch nicht mit entsprechenden Fehlerberichten hier auflaufen - zur Ausführung ohne Swap-Space steht weiter oben meine Warnung), der muß sicherstellen, daß für das Skript die Environment-Variable
Code:
MODFS_WITHOUT_SWAP=i_am_sureBeim Start von "modfs" wird versucht, anhand der Kernel-Version des Host-Systems die passenden Binärdateien zu finden und - wenn die vorhanden sind und nicht mit den aktuell verlinkten übereinstimmen - den Link im "bin"-Unterverzeichnis von "modfs" entsprechend anzupassen. Damit sollten auf einer 07.01 als Host für "modfs" auch die Dateien für diese Version genutzt werden - selbst wenn die eigentlich alle statisch gelinkt sein sollten.
Der Abbruch vor dem Einpacken unter Beibehalten der modifizierten Dateistruktur ist auch mit der Environment-Variablen "MODFS_ABORT_BEFORE_PACK=Q" steuerbar.
--------------------------------------------------------------------------------------------------------------
Auch wenn sich die Frage nicht an mich richtete ... wie man die Dateistruktur vor dem Einpacken noch zusätzlich modifizieren kann, habe ich hier vor gar nicht soo langer Zeit noch einmal ausgeführt: https://www.ip-phone-forum.de/threads/modfs-squashfs-image-avm-firmware-ändern-für-nand-basierte-fritz-boxen.273304/page-73#post-2295245
--------------------------------------------------------------------------------------------------------------
Weiter geht es jetzt mit 0.5.1-beta, wenn jemand neue Versionen testen möchte. Ich werde das Bereitstellen neuer Beta-Versionen dann weiterhin hier ankündigen.
--------------------------------------------------------------------------------------------------------------
EDIT:
Ich habe mal die aktuellen Ausführungszeiten von "modfs" (scharf und "mit allem") auf (m)einer 7490 gemessen. Dabei kommt eine ältere PATA-HDD (WD Scorpio, WD2500BEVE-00WZT0) in einem USB2-Gehäuse mit Prolific-Wandler-Chip (067b:2506) zum Einsatz, die neben einer 4 GB Swap-Partition noch zwei Partitionen mit jeweils einem ext3-Dateisystem enthält. Als Arbeitsverzeichnis wird eines dieser Volumes benutzt. Das "modfs"-Verzeichnis mit dem Inhalt des Archivs von yourfritz.de befindet sich auf der anderen ext3-Partition.
Die gesamte Ausführung (weitgehend automatisch, also nur in sehr geringem Maße von Reaktionszeiten bei Fragen beeinflußt) dauerte keine 7' 15" - das Packen brauchte alleine schon 6' 10" davon.
Welche von mehreren, entsprechend ungünstigeren Bedingungen jetzt wieviel Zeit zusätzlich kostet (langsamerer USB-Speicher bei Schreibzugriffen, falsches Dateisystem), weiß ich auch nicht ... aber die Scorpio ist nun auch nicht die schnellste denkbare HDD, erst recht nicht mit dem Prolific-Wandler mit USB2. Aber 90 Minuten sind dann doch schon sehr heftig und mir fehlt etwas die Phantasie, wo die Zeit bleiben sollte. Das Debug-Protokoll ist aber auch hier hilfreich ... es enthält ja auch für jeden Eintrag eine Uhrzeit und so kann man zumindest mal sehen, wo die größten Lücken zwischen zwei Einträgen auftauchen:
Code:
2018-10-08 09:33:14.717 - progress: mode=1, msg=Packen des neuen root-Dateisystems ...
2018-10-08 09:33:14.736 - run_spinner: dir=/var/media/ftp/system/1538983933, command=pack_squashfs /var/media/ftp/system/1538983933 /var/media/ftp/system/1538983933/newroot.squashfs 0 65536 4
2018-10-08 09:33:14.767 - pack_squashfs: using SquashFS version 4
2018-10-08 09:33:14.801 - sq_mksquashfs: /var/media/ftp/YourFritz/modfs/bin/185/mksquashfs4 squashfs-root /var/media/ftp/system/1538983933/newroot.squashfs -info -b 65536 -force-uid 0 -force-gid 0
2018-10-08 09:39:21.731 - sq_mksquashfs: exiting, rc=0
2018-10-08 09:39:21.749 - pack_squashfs: exiting, rc=0
2018-10-08 09:39:21.773 - run_spinner: exiting, rc=0
2018-10-08 09:39:21.821 - progress: mode=3, msg= OK
2018-10-08 09:39:21.839 - modfs: packing done, rc=0
Zuletzt bearbeitet:
Bei mir dauerte das Packen von modfs mit zusätzlichem Link im Dateisystem ca. 7:35 min, USBStick 3.0 am seitlichen USB-Anschluss, auch auf 3.0 gestellt, 2 GB SWAP.
Der anschließende Neustart der FB 7490 kommt auf knapp 5:45 min.
!!!Danke für die Super Arbeit!!! Alle Fragen liefen problemlos durch.
Edit: gestoppte Zeiten verwechselt, jetzt korrigiert.
Der anschließende Neustart der FB 7490 kommt auf knapp 5:45 min.
!!!Danke für die Super Arbeit!!! Alle Fragen liefen problemlos durch.
Edit: gestoppte Zeiten verwechselt, jetzt korrigiert.
Zuletzt bearbeitet:
So... ich habe es hinbekommen...
Was war mein Fehler?
Ich hatte gedacht, dass "http://yourfritz.de/modfs.tgz" bereits die verwendbare Version für Fritz!OS 7.01 richtig wäre - was sie nicht war.
[Vielen Dank für den indirekten Hinweis von PeterPawn: "Da keine weiteren Fehler berichtet wurden, ist ab sofort die Version 0.5.0 aktiv und als "modfs.tgz" verlinkt."]
Ich musste also das File neu laden - bzw. jetzt (nach der Umstellung von PeterPawn) funktionierte ja dann auch das ursprüngliche:
mkdir -p /var/mod;cd /var/mod;wget -qO- http://yourfritz.de/modfs.tgz | gunzip -c | tar x
Nächste Hürde dann die Aktion mit dem Swap-File... Ext3 - USB-Stick wurde von der FirtzBox 7940 verweigert mit "unbekanntes Filesystem" - mag aber daran liegen, dass das Tool mit dem ich den Stick an meinem Windows-PC formatiert habe kein "echtes" Ext3 schreibt / formatiert.
Mit Ext2 - Formatierung stand ich vor dem schon beschriebenen Problem des "schreibgeschützt" - aber immerhin erkannte die Box den Stick ordentlich.
Dann hatte ich keine Lust mehr auf Ext2 und Ext3 und habe den Stick schlicht unter Windows 10 mit FAT32 formatiert...
In der Box wurde er erkannt und mit FAT eingebunden.
Dann: per Telnet auf der Box...
dd if=/dev/zero of=/var/media/ftp/USBDISK3-0-01/swapfile bs=1024 count=327680
mkswap /var/media/ftp/USBDISK3-0-01/swapfile
swapon /var/media/ftp/USBDISK3-0-01/swapfile
free [nur zur Kontrolle]
und schon hatte ich ein ausreichend großes Swapfile um über die von PeterPawn eingebundene Hürde zu überspringen...
mkdir -p /var/mod;cd /var/mod;wget -qO- http://yourfritz.de/modfs.tgz | gunzip -c | tar x
lief durch und diesmal dauerte es noch ganze 20 Minuten bis die Box mit 7.01 fertig da stand.
Danach konnte ich den USB-Stick mit dem Swapfile auch wieder abziehen - den benötige ich ja nur beim nächsten Update wieder...
Kurzer Test noch:
"Telnet_enable" (#96*7*) - funktioniert!
"Telnet_disable" (#96*8*) - funktioniert!
Ich denke damit kann ich wieder alles machen was ich benötige.
[Irgendwie war ich zwar der Meinung dass statt #96*7* und #96*8* jetzt zwar #97*3* und #97*2* genutzt werden sollten - die blieben aber ohne Funktion und die alten Einträge in meinem Telefonbuch funktionierten weiterhin - egal - geht!]
[Unklar ist mir noch, warum ich mit der alten modfs.tgz - die ja wohl dann für 06.93 war (oder so) - recht problemlos (jedenfalls ohne Swapfile) - wenn auch ohne funktionierendes Telnet - wenn auch mit recht langer Installationsdauer - auf 7.01 gekommen bin; aber gut - man muss nicht alles verstehen.]
Allen die eine Idee geliefert haben um soweit zu kommen: HERZLICHEN DANK!
Was war mein Fehler?
Ich hatte gedacht, dass "http://yourfritz.de/modfs.tgz" bereits die verwendbare Version für Fritz!OS 7.01 richtig wäre - was sie nicht war.
[Vielen Dank für den indirekten Hinweis von PeterPawn: "Da keine weiteren Fehler berichtet wurden, ist ab sofort die Version 0.5.0 aktiv und als "modfs.tgz" verlinkt."]
Ich musste also das File neu laden - bzw. jetzt (nach der Umstellung von PeterPawn) funktionierte ja dann auch das ursprüngliche:
mkdir -p /var/mod;cd /var/mod;wget -qO- http://yourfritz.de/modfs.tgz | gunzip -c | tar x
Nächste Hürde dann die Aktion mit dem Swap-File... Ext3 - USB-Stick wurde von der FirtzBox 7940 verweigert mit "unbekanntes Filesystem" - mag aber daran liegen, dass das Tool mit dem ich den Stick an meinem Windows-PC formatiert habe kein "echtes" Ext3 schreibt / formatiert.
Mit Ext2 - Formatierung stand ich vor dem schon beschriebenen Problem des "schreibgeschützt" - aber immerhin erkannte die Box den Stick ordentlich.
Dann hatte ich keine Lust mehr auf Ext2 und Ext3 und habe den Stick schlicht unter Windows 10 mit FAT32 formatiert...
In der Box wurde er erkannt und mit FAT eingebunden.
Dann: per Telnet auf der Box...
dd if=/dev/zero of=/var/media/ftp/USBDISK3-0-01/swapfile bs=1024 count=327680
mkswap /var/media/ftp/USBDISK3-0-01/swapfile
swapon /var/media/ftp/USBDISK3-0-01/swapfile
free [nur zur Kontrolle]
und schon hatte ich ein ausreichend großes Swapfile um über die von PeterPawn eingebundene Hürde zu überspringen...
mkdir -p /var/mod;cd /var/mod;wget -qO- http://yourfritz.de/modfs.tgz | gunzip -c | tar x
lief durch und diesmal dauerte es noch ganze 20 Minuten bis die Box mit 7.01 fertig da stand.
Danach konnte ich den USB-Stick mit dem Swapfile auch wieder abziehen - den benötige ich ja nur beim nächsten Update wieder...
Kurzer Test noch:
"Telnet_enable" (#96*7*) - funktioniert!
"Telnet_disable" (#96*8*) - funktioniert!
Ich denke damit kann ich wieder alles machen was ich benötige.
[Irgendwie war ich zwar der Meinung dass statt #96*7* und #96*8* jetzt zwar #97*3* und #97*2* genutzt werden sollten - die blieben aber ohne Funktion und die alten Einträge in meinem Telefonbuch funktionierten weiterhin - egal - geht!]
[Unklar ist mir noch, warum ich mit der alten modfs.tgz - die ja wohl dann für 06.93 war (oder so) - recht problemlos (jedenfalls ohne Swapfile) - wenn auch ohne funktionierendes Telnet - wenn auch mit recht langer Installationsdauer - auf 7.01 gekommen bin; aber gut - man muss nicht alles verstehen.]
Allen die eine Idee geliefert haben um soweit zu kommen: HERZLICHEN DANK!
Zuletzt bearbeitet:
Micha0815
IPPF-Promi
- Mitglied seit
- 25 Feb 2008
- Beiträge
- 5,344
- Punkte für Reaktionen
- 467
- Punkte
- 83
Ich nutze das kostenlos-Tool Partition-Wizard was problemlos mit USB-Sticks extX und swap erstellen kann. Als Stick nutze ich seit modfs-Anfangszeiten Intenso-Microline-16GB-Sticks da sie sowohl hinten alsauch seitlich über den Rand nicht hinausragen. Bei 2GB SWAP und 8GB ext3 benötigt das aktuelle script hier ~5Min zum Einpacken wobei das Lesen der Choices nebst Inhalt länger gedauert hat, bis man sich entschieden hat
Hier nach dem Wechsel zum alten 6.93 nach dem Reboot erstmals "nur" die Willkommens-Nachricht "Erfolgreich Installiert" und der "AVM-Benachrichtigungsmaske" und endlich eine korrekte Übernahme der Internetverbindungseinstellung (hier WLAN-Repeater via 5GHz das siehe Anlage nicht existent aber verbunden) wobei die erste Abfrage ANNEX A/B diesmal fehlte.
LG
Anhänge
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Der "Zwang" zum Swap-Space resultiert einfach daraus, daß (zumindest gefühlt) 3 von 4 hier berichteten Fehlern (zumindest in der Zeit, wo ich nichts Neues hinzugefügt habe) am Ende daran lagen ... mein Hinweis in #1 (inzwischen vom 06.11.2015) wurde entweder ganz offensichtlich nicht gelesen oder nicht ernst genommen und mehr als "nice to have" angesehen.
Damit ist jetzt erst einmal Schluß ... und um jemandem, der das gerne für sich selbst entscheiden möchte, noch eine Wahl zu lassen, gibt es die weiter oben beschriebene Environment-Variable. Aber ich hoffe mal inständig, daß jemand, der sich - entgegen jeder Warnung meinerseits - gegen die Bereitstellung von Swap-Space entscheidet, dann hinterher nicht hier aufschlägt und von seinen Leiden berichtet, wenn er danach auf Nachfrage (wie z.B. in #1561) zugeben muß, daß er gar keinen verwendet.
Ansonsten tritt noch das "permission denied" in den Fällen "gehäuft" auf, wo die Volumes mit "noexec" gemountet wurden und das "modfs"-Paket eben nicht in "/var/mod" entpackt wurde, wie es beschrieben ist. Das ist zwar durchaus auch "erlaubt", aber dann muß man sich eben mit dem Problem auskennen und selbst Hand anlegen, damit das Volume mit "exec"-Option gemountet wird.
So ganz kann ich nämlich (um mal wieder zum Swap-Space zurückzukommen) den Text:
Auch vom Sinn des "mod_swapoff"-Patches habe ich inzwischen oft genug geschrieben ... solange nichts ausgelagert wurde, kann es auch kein Problem mit nicht eingelagertem Speicher geben und trotzdem konnte ich FRITZ!Boxen (gerade auch 7490) oft genug "aufhängen" beim Reboot, wenn Swap-Space vorhanden war und der USB-Stack beim Reboot "rücksichtslos" abgeräumt wurde, während noch Seiten ausgelagert waren, die zu später zu stoppenden Prozessen gehörten.
Immerhin ist diese "Warnung" meinerseits inzwischen auch fast drei Jahre alt und die Firmware hat sich in den drei Jahren schon einigermaßen verändert (und ist gewachsen - weniger vom Umfang der Dateien her, als vielmehr von der "utilization" des Hauptspeichers im Betrieb) ... damals war noch 06.3x "aktuell".
Damit ist jetzt erst einmal Schluß ... und um jemandem, der das gerne für sich selbst entscheiden möchte, noch eine Wahl zu lassen, gibt es die weiter oben beschriebene Environment-Variable. Aber ich hoffe mal inständig, daß jemand, der sich - entgegen jeder Warnung meinerseits - gegen die Bereitstellung von Swap-Space entscheidet, dann hinterher nicht hier aufschlägt und von seinen Leiden berichtet, wenn er danach auf Nachfrage (wie z.B. in #1561) zugeben muß, daß er gar keinen verwendet.
Ansonsten tritt noch das "permission denied" in den Fällen "gehäuft" auf, wo die Volumes mit "noexec" gemountet wurden und das "modfs"-Paket eben nicht in "/var/mod" entpackt wurde, wie es beschrieben ist. Das ist zwar durchaus auch "erlaubt", aber dann muß man sich eben mit dem Problem auskennen und selbst Hand anlegen, damit das Volume mit "exec"-Option gemountet wird.
So ganz kann ich nämlich (um mal wieder zum Swap-Space zurückzukommen) den Text:
nicht nachvollziehen ... noch deutlicher als in #1 (wie gesagt, nach dem 06.11.2015 schauen) kann man (ich) es kaum schreiben, daß es ansonsten Probleme mit dem freien Hauptspeicher (und durchaus auch bei 7490 und 3490, obwohl die den doppelten Hauptspeicher haben im Vergleich zu den anderen Modellen) gibt.
Auch vom Sinn des "mod_swapoff"-Patches habe ich inzwischen oft genug geschrieben ... solange nichts ausgelagert wurde, kann es auch kein Problem mit nicht eingelagertem Speicher geben und trotzdem konnte ich FRITZ!Boxen (gerade auch 7490) oft genug "aufhängen" beim Reboot, wenn Swap-Space vorhanden war und der USB-Stack beim Reboot "rücksichtslos" abgeräumt wurde, während noch Seiten ausgelagert waren, die zu später zu stoppenden Prozessen gehörten.
Immerhin ist diese "Warnung" meinerseits inzwischen auch fast drei Jahre alt und die Firmware hat sich in den drei Jahren schon einigermaßen verändert (und ist gewachsen - weniger vom Umfang der Dateien her, als vielmehr von der "utilization" des Hauptspeichers im Betrieb) ... damals war noch 06.3x "aktuell".
Fireball3
Mitglied
- Mitglied seit
- 22 Dez 2005
- Beiträge
- 286
- Punkte für Reaktionen
- 0
- Punkte
- 16
Ich war der Meinung, eine SWAP Partition ist leichter erstellt, als eine Datei.
(ext Partitionen mit Windows Bordmitteln sind ein Kreuz um nicht zu sagen unmöglich)
Die Partition wurde auch ordnungsgemäß eingebunden aber das Verzeichnis zum Entpacken der Firmware konnte nicht erstellt werden.
Ich konnte mit dem Inhalt von "showshringbuf modfs" nicht herausfinden wohin er das Verzeichnis erstellen will, muss aber wohl auf den Stick gehen.
Dann habe ich den Stick auch FAT32 formatiert und das swapfile darauf erstellt.
Damit lief dann auch modfs durch. Die Frage ist, ob es damit evtl. Probleme gibt?
Berechtigungen können auf FAT/FAT32 nicht gesetzt werden...
Da bin ich dann auch noch drüber geflogen.
Ich habe den callog-mod nicht aktiviert und dann ließ sich telnet nicht Aktivieren.
Die Lösung dafür steht in #1565
Dieser mod bringt die Codes #97*3* und #97*2*
Kann jemand bestätigen, ob/dass der mod_exec_on_usb auch funktioniert?
Obwohl ich den ausgewählt habe, konnte ich nichts auf dem Stick ausführen.
Bis auf Weiteres läuft das jetzt mit einem remount,exec in der debug.cfg
Dann war die Bastelstunde auch wieder vorbei.
könntest Du Bitte den Befehl "mount | grep var.media.ftp" nach Reboot eingeben und posten; vorher den Befehl "remount,exec" in der Datei "rc.user" temporär deaktivieren;
dann hat man mehr Diagnose-Inputs.
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Bei dem habe ich auch beschrieben, daß (und vor allem warum) er nur für Volumes mit nativen Dateisystemen gilt - zumindest in der Form, die ich "anbiete".
---------------------------------------------------------------------------------------------------------------------------
Man muß seinen USB-Stick auch nicht unter Windows vorbereiten ... das "modfs"-Paket enthält nämlich auch alles andere, was man für das Präparieren des eigenen Sticks benötigen würde:
Code:
root@FB7490:/var/media/ftp/YourFritz/modfs $ ls -la bin/$HWRevision/
drwxr-xr-x 2 1000 1001 4096 Oct 3 20:59 .
drwxrwxr-x 9 1000 1001 4096 Oct 7 20:12 ..
-rw-r--r-- 1 1000 1001 10 Aug 14 2017 .gitattributes
lrwxrwxrwx 1 root root 30 Sep 18 17:12 busybox -> ../common/busybox.34kc.3.10.73
lrwxrwxrwx 1 root root 37 Sep 18 17:12 busybox.config -> ../common/busybox.config.34kc.3.10.73
lrwxrwxrwx 1 root root 29 Sep 18 17:12 e2fsck -> ../common/e2fsck.34kc.3.10.73
lrwxrwxrwx 1 root root 29 Sep 18 17:12 mke2fs -> ../common/mke2fs.34kc.3.10.73
lrwxrwxrwx 1 root root 34 Sep 18 17:12 mksquashfs3 -> ../common/mksquashfs3.34kc.3.10.73
lrwxrwxrwx 1 root root 34 Sep 18 17:12 mksquashfs4 -> ../common/mksquashfs4.34kc.3.10.73
lrwxrwxrwx 1 root root 30 Sep 18 17:12 openssl -> ../common/openssl.34kc.3.10.73
lrwxrwxrwx 1 root root 33 Sep 18 17:12 unsquashfs3 -> ../common/unsquashfs.34kc.3.10.73
lrwxrwxrwx 1 root root 33 Sep 18 17:12 unsquashfs4 -> ../common/unsquashfs.34kc.3.10.73
root@FB7490:/var/media/ftp/YourFritz/modfs $Hier mal am Beispiel einer 7580 mit "originaler" AVM-Firmware:
Code:
# mkdir /var/mod; wget -O- http://yourfritz.de/modfs.tgz | gunzip -c | tar -C /var/mod -x
Connecting to yourfritz.de (85.214.20.177:80)
- 100% |*********************************************| 5340k 0:00:00 ETA
# cd /var/mod
# ./bin/$HWRevision/busybox sh
/var/mod #Jetzt kann man sich die vorhandenen Block-Devices anzeigen lassen und zunächst mal ermitteln, welche Pfade zum Stick führen, denn das Einbinden beim Einstecken (oder beim Start) kann man bei der AVM-Firmware nicht unterbinden. Wenn der Stick tatsächlich vollkommen "blank" ist und gar keine Partition enthält (ich habe hier zu Demonstrationszwecken eine 2 GB Mikro-SD-Karte im USB-Adapter genommen, die sind i.d.R. schon mit exFAT oder FAT32 (bei kleinen Kapazitäten wie 2 GB) vorformatiert), dann taucht er hier halt nicht auf und man muß mit "cat /proc/diskstat" suchen, welches Gerät es ist.
Code:
/var/mod # blkid
/dev/sdb5: LABEL="storage" UUID="33132262-834d-41a5-b4eb-59b4266e8789" TYPE="ext3"
/dev/sdb2: LABEL="YourFritz" UUID="ed85d36c-ae21-431f-be3a-41df0884d49a" TYPE="ext3"
/dev/sdb1: TYPE="swap"
/dev/sda1: UUID="563B-7C7E" TYPE="vfat"
/dev/ubi0_3: UUID="64007ccf-f1f2-4fa5-ae5a-99ff51c15ffe" TYPE="ubifs"
/dev/ubi0_1: TYPE="squashfs"
/dev/ubi0_0: TYPE="squashfs"
/var/mod #
Code:
/var/mod # umount /dev/sda1
/var/mod # mount
rootfs on / type rootfs (rw)
/dev/root on / type squashfs (ro,relatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=216100k,nr_inodes=54025,mode=755)
proc on /proc type proc (rw,relatime)
tmpfs on /var type tmpfs (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
none on /sys/kernel/debug type debugfs (rw,relatime)
/dev/ubi0_3 on /var/media/ftp type ubifs (rw,sync,noexec,relatime)
debug on /debug type debugfs (rw,relatime)
/dev/sdb2 on /var/media/ftp/YourFritz type ext3 (rw,noexec,relatime,errors=continue,barrier=1,data=writeback)
/dev/sdb5 on /var/media/ftp/storage type ext3 (rw,noexec,relatime,errors=continue,barrier=1,data=writeback)
/var/mod #
Code:
/var/mod # fdisk -u /dev/sda
The number of cylinders for this disk is set to 1882.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Command (m for help): p
Disk /dev/sda: 1882 MB, 1973420032 bytes, 3854336 sectors
1882 cylinders, 64 heads, 32 sectors/track
Units: sectors of 1 * 512 = 512 bytes
Device Boot StartCHS EndCHS StartLBA EndLBA Sectors Size Id Type
/dev/sda1 * 1,0,1 857,63,32 2048 3854335 3852288 1881M 83 Linux
Command (m for help): d <=== Löschen der alten Partition
Selected partition 1
Command (m for help): n <=== Anlegen einer Swap-Partition mit 384 MB (siehe Anmerkung weiter unten im Text)
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First sector (32-3854335, default 32):
Using default value 32
Last sector or +size or +sizeM or +sizeK (32-3854335, default 3854335): +384M
Command (m for help): t
Selected partition 1
Hex code (type L to list codes): L
0 Empty 1b Hidden Win95 FAT32 9f BSD/OS
1 FAT12 1c Hidden W95 FAT32 (LBA) a0 Thinkpad hibernation
4 FAT16 <32M 1e Hidden W95 FAT16 (LBA) a5 FreeBSD
5 Extended 3c Part.Magic recovery a6 OpenBSD
6 FAT16 41 PPC PReP Boot a8 Darwin UFS
7 HPFS/NTFS 42 SFS a9 NetBSD
a OS/2 Boot Manager 63 GNU HURD or SysV ab Darwin boot
b Win95 FAT32 80 Old Minix b7 BSDI fs
c Win95 FAT32 (LBA) 81 Minix / old Linux b8 BSDI swap
e Win95 FAT16 (LBA) 82 Linux swap be Solaris boot
f Win95 Ext'd (LBA) 83 Linux eb BeOS fs
11 Hidden FAT12 84 OS/2 hidden C: drive ee EFI GPT
12 Compaq diagnostics 85 Linux extended ef EFI (FAT-12/16/32)
14 Hidden FAT16 <32M 86 NTFS volume set f0 Linux/PA-RISC boot
16 Hidden FAT16 87 NTFS volume set f2 DOS secondary
17 Hidden HPFS/NTFS 8e Linux LVM fd Linux raid autodetect
Hex code (type L to list codes): 82
Changed system type of partition 1 to 82 (Linux swap)
Command (m for help): n <=== Anlegen einer weiteren Partition mit dem restlichen Platz auf dem Gerät
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 2
First sector (750033-3854335, default 750033):
Using default value 750033
Last sector or +size or +sizeM or +sizeK (750033-3854335, default 3854335):
Using default value 3854335
Command (m for help): t
Partition number (1-4): 2
Hex code (type L to list codes): 83
Command (m for help): p <=== Anzeige des Ergebnisses
Disk /dev/sda: 1882 MB, 1973420032 bytes, 3854336 sectors
1882 cylinders, 64 heads, 32 sectors/track
Units: sectors of 1 * 512 = 512 bytes
Device Boot StartCHS EndCHS StartLBA EndLBA Sectors Size Id Type
/dev/sda1 0,1,1 366,14,17 32 750032 750001 366M 82 Linux swap
Partition 1 does not end on cylinder boundary
/dev/sda2 366,14,18 1023,63,32 750033 3854335 3104303 1515M 83 Linux
Command (m for help): w <=== Schreiben der Daten auf den Stick
The partition table has been altered.
Calling ioctl() to re-read partition table
fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy
/var/mod #Wenn dann beim Schreiben ähnliche Nachrichten wie oben auftauchen, zieht man den Stick noch einmal ab, wartet eine Minute (damit das FRITZ!OS die alten Infos entsorgen kann) und steckt ihn dann wieder an:
Code:
/var/mod # cat /proc/diskstats
7 0 loop0 0 0 0 0 0 0 0 0 0 0 0
7 1 loop1 0 0 0 0 0 0 0 0 0 0 0
31 0 mtdblock0 0 0 0 0 0 0 0 0 0 0 0
31 1 mtdblock1 0 0 0 0 0 0 0 0 0 0 0
31 2 mtdblock2 0 0 0 0 0 0 0 0 0 0 0
31 3 mtdblock3 0 0 0 0 0 0 0 0 0 0 0
31 4 mtdblock4 0 0 0 0 0 0 0 0 0 0 0
254 0 zram0 0 0 0 0 0 0 0 0 0 0 0
31 5 mtdblock5 838 13235 28146 10724 0 0 0 0 0 10480 10716
31 6 mtdblock6 0 0 0 0 0 0 0 0 0 0 0
31 7 mtdblock7 0 0 0 0 0 0 0 0 0 0 0
31 8 mtdblock8 0 0 0 0 0 0 0 0 0 0 0
8 0 sda 240 5298 17704 2268 4 0 11 300 0 1400 2560
8 1 sda1 220 4929 14592 2028 3 0 3 156 0 1148 2176
8 16 sdb 323 4095 32820 1576 11 2 104 32 0 892 1600
8 17 sdb1 105 1524 11760 476 1 0 8 8 0 424 484
8 18 sdb2 90 1142 9850 536 5 1 48 12 0 384 540
8 19 sdb3 7 5 44 16 0 0 0 0 0 16 16
8 21 sdb5 92 1286 10498 488 5 1 48 12 0 404 500
/var/mod #
killall: ftpd: no process killed
killall: ftpd: no process killed
Oct 9 13:17:52 rpctrl[13522]: SET(0,start/0)
Oct 9 13:17:53 rpctrl[13530]: GET(0,mstate/0)
Oct 9 13:17:53 rpctrl[13531]: SETLIST(80000018,udev/0)
modprobe: module sd_mod not found in modules.dep
modprobe: module usb-storage not found in modules.dep
Mounting [Generic-USBSDReader-01] to device /dev/sda1...
MOUNT: use blkid to get device /dev/sda1 data
MOUNT: filesystem type is:
MOUNT: unknown filesystem type on device /dev/sda1
Mounting [Generic-USBSDReader-02] to device /dev/sda2...
MOUNT: use blkid to get device /dev/sda2 data
MOUNT: filesystem type is:
MOUNT: unknown filesystem type on device /dev/sda2
/var/mod # cat /proc/diskstats
7 0 loop0 0 0 0 0 0 0 0 0 0 0 0
7 1 loop1 0 0 0 0 0 0 0 0 0 0 0
31 0 mtdblock0 0 0 0 0 0 0 0 0 0 0 0
31 1 mtdblock1 0 0 0 0 0 0 0 0 0 0 0
31 2 mtdblock2 0 0 0 0 0 0 0 0 0 0 0
31 3 mtdblock3 0 0 0 0 0 0 0 0 0 0 0
31 4 mtdblock4 0 0 0 0 0 0 0 0 0 0 0
254 0 zram0 0 0 0 0 0 0 0 0 0 0 0
31 5 mtdblock5 838 13235 28146 10724 0 0 0 0 0 10480 10716
31 6 mtdblock6 0 0 0 0 0 0 0 0 0 0 0
31 7 mtdblock7 0 0 0 0 0 0 0 0 0 0 0
31 8 mtdblock8 0 0 0 0 0 0 0 0 0 0 0
8 16 sdb 323 4095 32820 1576 11 2 104 32 0 892 1600
8 17 sdb1 105 1524 11760 476 1 0 8 8 0 424 484
8 18 sdb2 90 1142 9850 536 5 1 48 12 0 384 540
8 19 sdb3 7 5 44 16 0 0 0 0 0 16 16
8 21 sdb5 92 1286 10498 488 5 1 48 12 0 404 500
8 0 sda 299 16711 18928 2980 0 0 0 0 0 984 2968
8 1 sda1 135 8386 9452 1436 0 0 0 0 0 588 1436
8 2 sda2 152 8325 9380 1516 0 0 0 0 0 580 1508
/var/mod #
Code:
/var/mod # mkswap /dev/sda1
Setting up swapspace version 1, size = 383996416 bytes
UUID=3786459b-6f2c-4aa9-9f72-b852cb1c7d12
/var/mod # bin/$HWRevision/mke2fs -t ext3 -L YourFritz /dev/sda2
mke2fs 1.42.13 (17-May-2015)
Creating filesystem with 388037 4k blocks and 97152 inodes
Filesystem UUID: bcdd697b-7453-4633-83a4-0479220c653d
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912
Allocating group tables: done
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done
/var/mod # blkid
/dev/sda2: LABEL="YourFritz" UUID="bcdd697b-7453-4633-83a4-0479220c653d" TYPE="ext3"
/dev/sda1: UUID="3786459b-6f2c-4aa9-9f72-b852cb1c7d12" TYPE="swap"
/dev/sdb5: LABEL="storage" UUID="33132262-834d-41a5-b4eb-59b4266e8789" TYPE="ext3"
/dev/sdb2: LABEL="YourFritz" UUID="ed85d36c-ae21-431f-be3a-41df0884d49a" TYPE="ext3"
/dev/sdb1: TYPE="swap"
/dev/ubi0_3: UUID="64007ccf-f1f2-4fa5-ae5a-99ff51c15ffe" TYPE="ubifs"
/dev/ubi0_1: TYPE="squashfs"
/dev/ubi0_0: TYPE="squashfs"
/var/mod #Wer den Stick jetzt nicht noch einmal durch Aus- und Einstecken "frisch" erkennen will, der teilt das einfach dem "udevd" mit, daß er die "add"-Aktionen noch einmal ausführen soll - man muß gar nicht genauer spezifizieren wofür (auch wenn man es könnte):
Code:
/var/mod # udevadm trigger --action=add
/var/mod #
Oct 9 13:27:46 rpctrl[17068]: GET(0,mstate/0)
Oct 9 13:27:46 rpctrl[17069]: SETLIST(80000018,udev/0)
Oct 9 13:27:46 rpctrl[17071]: GET(0,mstate/0)
Oct 9 13:27:46 rpctrl[17076]: SETLIST(80000018,udev/0)
rmdir: '/var/media/ftp/YourFritz': Device or resource busy
[YourFritz] already mounted
Mounting [YourFritz-1] to device /dev/sda2...
MOUNT: use blkid to get device /dev/sda2 data
MOUNT: filesystem type is: ext3
MOUNT:mount -t 'extX' /dev/sda2 /var/media/ftp/YourFritz-1
killall: ftpd: no process killed
Oct 9 13:27:48 tr069starter[17464]: starting ...
2018-10-09 13:27:48 tr069starter[17464]: ready (0sec)
Mounting [Generic-USBSDReader-01] to device /dev/sda1...
MOUNT: use blkid to get device /dev/sda1 data
MOUNT: filesystem type is: swap
MOUNT: try to add swap
MOUNT: swap added
Mounting [SanDisk-UltraFit-01] to device /dev/sdb1...
MOUNT: use blkid to get device /dev/sdb1 data
MOUNT: filesystem type is: swap
MOUNT: try to add swap
swapon: /dev/sdb1: Device or resource busy
MOUNT: swap added
Oct 9 13:27:58 tr069starter[17466]: tr069starter: /var/media/ftp/YourFritz-1/fritzboxconfig.import not found - exit
Code:
/var/mod # cat /proc/swaps
Filename Type Size Used Priority
/dev/sdb1 partition 1953772 0 -1
/dev/sda1 partition 374996 0 -2
/var/mod # cat /proc/partitions
major minor #blocks name
31 0 8192 mtdblock0
31 1 1024 mtdblock1
31 2 4096 mtdblock2
31 3 8192 mtdblock3
31 4 502784 mtdblock4
31 5 45108 mtdblock5
31 6 45108 mtdblock6
31 7 2268 mtdblock7
31 8 391356 mtdblock8
8 16 30031250 sdb
8 17 1953776 sdb1
8 18 15626240 sdb2
8 19 1 sdb3
8 21 12450800 sdb5
8 0 1927168 sda
8 1 375000 sda1
8 2 1552151 sda2
/var/mod # df -PT
Filesystem Type 1024-blocks Used Available Capacity Mounted on
/dev/root squashfs 20480 20480 0 100% /
devtmpfs devtmpfs 216100 96 216004 0% /dev
tmpfs tmpfs 216252 13240 203012 6% /var
/dev/ubi0_3 ubifs 363820 340 358644 0% /var/media/ftp
/dev/sdb2 ext3 15380880 7022676 7576892 48% /var/media/ftp/YourFritz
/dev/sdb5 ext3 12255400 9185788 2447072 79% /var/media/ftp/storage
/dev/sda2 ext3 1527716 35084 1415028 2% /var/media/ftp/YourFritz-1
/var/mod #Wer auch noch das "e2fsck" aus dem "modfs"-Paket mal verwenden will, muß halt vorher sicherstellen, daß das FRITZ!OS die Partition nicht mehr in Benutzung hat ... das geht wieder am einfachsten über das Auswerfen im GUI, wobei der Stick dann weiterhin angesteckt bleibt - entfernt man ihn und steckt ihn dann erst wieder an, bindet das FRITZ!OS die Partitionen auch umgehend wieder ein. Will man ein Volume "von Hand" entfernen lassen, ist das etwas komplizierter, weil die AVM-Skripte dafür die USB-Gerätenummer wissen wollen und man die erst auslesen muß (das ginge mit einem anderen Suchbegriff natürlich auch für den Mountpoint, denn der folgt dem Gerätenamen nach einem Doppelpunkt):
Code:
/var/mod # /etc/hotplug/storage umount_usb $(sed -n -e "s|^\([^=]*\)=/dev/sda2.*|\1|p" /var/tmp/mediadevmap)
storage:unmounting /var/media/ftp/YourFritz-1
killall: ftpd: no process killed
/var/mod # cat /var/tmp/mediadevmap
003/002=/dev/sda1:Generic-USBSDReader-01
001/002=/dev/sdb2:YourFritz
001/002=/dev/sdb5:storage
003/003=#removed
/var/mod # bin/$HWRevision/e2fsck -f -v -p /dev/sda2
11 inodes used (0.01%, out of 97152)
0 non-contiguous files (0.0%)
0 non-contiguous directories (0.0%)
# of inodes with ind/dind/tind blocks: 0/0/0
14879 blocks used (3.83%, out of 388037)
0 bad blocks
1 large file
0 regular files
2 directories
0 character device files
0 block device files
0 fifos
0 links
0 symbolic links (0 fast symbolic links)
0 sockets
------------
2 files
/var/mod #
Code:
/var/mod # env | grep ^PATH
PATH=/sbin:/usr/sbin:/bin:/usr/bin
/var/mod # export PATH=/var/mod/bin/$HWRevision:$PATH
/var/mod # env | grep ^PATH
PATH=/var/mod/bin/225:/sbin:/usr/sbin:/bin:/usr/bin
/var/mod #
Code:
/var/mod # ls -l bin
lrwxrwxrwx 1 root root 5 Oct 9 12:32 156 -> Vx180
lrwxrwxrwx 1 root root 11 Oct 9 12:32 175 -> VR9_3.10.73
lrwxrwxrwx 1 root root 11 Oct 9 12:32 185 -> VR9_3.10.73
lrwxrwxrwx 1 root root 11 Oct 9 12:32 192 -> VR9_3.10.73
lrwxrwxrwx 1 root root 11 Oct 9 12:32 193 -> VR9_3.10.73
lrwxrwxrwx 1 root root 11 Oct 9 12:32 203 -> VR9_3.10.73
lrwxrwxrwx 1 root root 11 Oct 9 12:32 212 -> VR9_3.10.73
lrwxrwxrwx 1 root root 6 Oct 9 12:32 213 -> P6ATOM
lrwxrwxrwx 1 root root 11 Oct 9 12:32 218 -> VR9_3.10.73
lrwxrwxrwx 1 root root 6 Oct 9 12:32 220 -> P6ATOM
lrwxrwxrwx 1 root root 12 Oct 9 12:32 221 -> GRX5_3.10.73
lrwxrwxrwx 1 root root 12 Oct 9 12:32 225 -> GRX5_3.10.73
lrwxrwxrwx 1 root root 12 Oct 9 12:32 226 -> GRX5_3.10.73
drwxr-xr-x 2 1000 1001 220 Oct 9 12:32 GRX5_3.10.73
drwxr-xr-x 2 1000 1001 260 Oct 9 12:32 P6ATOM
drwxr-xr-x 2 1000 1001 220 Oct 9 12:32 VR9_3.10.107
drwxr-xr-x 2 1000 1001 220 Oct 9 12:32 VR9_3.10.73
drwxr-xr-x 2 1000 1001 200 Oct 9 12:32 Vx180
drwxr-xr-x 2 1000 1001 400 Oct 9 12:32 common
drwxr-xr-x 3 1000 1001 160 Oct 9 12:32 scripts
/var/mod #Fazit: Man kommt bei der Benutzung von "modfs" auch ganz gut ohne ein Windows-System oder ein anderes Linux aus ... wenn man erst mal den Shell-Zugang hat, denn dafür braucht man ggf. noch irgendeine Möglichkeit des "Impfens" - zumindest bei den VR9-Boxen mit "wrapper" geht das ja.
Zuletzt bearbeitet:
Fireball3
Mitglied
- Mitglied seit
- 22 Dez 2005
- Beiträge
- 286
- Punkte für Reaktionen
- 0
- Punkte
- 16
Schöne Anleitung, Danke!
Hat was, wenn man sieht wie Einer in seinem Element ist. Die Befehle habe ich alle schonmal gesehen, aber soviel Umgang habe ich leider nicht, sie entsprechend zur richtigen Zeit zielführend einzusetzen. :-(
Die Box ist nämlich bereits 2x abgeschmiert.
Wie kann man sowas debuggen? Nach einem Neustart ist ja das log leer (nicht dass ich darin einen sinnvollen Hinweis erwarten würde...).
Hat was, wenn man sieht wie Einer in seinem Element ist. Die Befehle habe ich alle schonmal gesehen, aber soviel Umgang habe ich leider nicht, sie entsprechend zur richtigen Zeit zielführend einzusetzen. :-(
Das klappt aber auch nicht immer zuverlässig.
Dann wäre das auch geklärt. Könnte man als Hinweis in den modfs Abfragetext einbauen.
Kann es sein, dass das hier zum Problem wird?
Die Box ist nämlich bereits 2x abgeschmiert.
Wie kann man sowas debuggen? Nach einem Neustart ist ja das log leer (nicht dass ich darin einen sinnvollen Hinweis erwarten würde...).
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Na ja, das ist zwar eine "gute Idee", aber die hatte ich tatsächlich schon und daher steht das da bereits drin und zwar seit der "ersten Veröffentlichung" dieses "modscripts":
https://github.com/PeterPawn/modfs/blob/master/modscripts/mod_exec_on_usb#L7
Wäre die Frage, wobei das genau geschehen ist ... bei der Verwendung von "modfs" oder bei irgendwelchen anderen Aktionen. Ich höre jedenfalls irgendwie zum ersten Mal davon, daß eine mit "modfs" behandelte Box (deswegen) abstürzen würde ... eigentlich führt keine dieser Änderungen zur Abwandlung von wichtigen Abläufen in der AVM-Firmware - auch nicht von den kürzlich erst bereitgestellten, neuen.
Mit einer wichtigen Ausnahme, nämlich "mod_enable_calllog" ... und daß sich das nicht mit dem "Impfen" mit einem der "first_aid"-Images verträgt (weil das dort sein "Protokoll" abspeichert und dieses bei einer Firmware mit dem "privaten Modus" für den "telefon"-Daemon dann bei jedem Anruf ausgeführt werden soll), hatte ich auch schon erwähnt. Man muß also schon nach dem "Impfen" den Inhalt der "/var/flash/calllog" noch einmal löschen, bevor man künftig diese Zeilen bei jedem Anruf ausführen lassen will ... das geht mit einem einfachen Kommando (das erste zeigt den vorhandenen Inhalt an und das zweite löscht):
Code:
root@FB7490:~ $ cat /var/flash/calllog
#! /bin/sh
eventadd 1 "/var/flash/calllog was called with $*"
cat /proc/self/cmdline >/var/tmp/calllog.cmdline
ps l >>/var/tmp/calllog.cmdline
exit 0
+ new_script=/wrapper/etc/init.d/rc.shellinaboxd
+ shift
+ cp /etc/init.d/rc.S /tmp/init_rc_replacement
+ sed -e /^if ls.*S/a[ $gruppe -eq 9 ] && /bin/sh /wrapper/etc/init.d/rc.shellinaboxd start -i /tmp/init_rc_replacement
+ mount -o bind /tmp/init_rc_replacement /etc/init.d/rc.S
+ [ 1 -eq 1 ]
+ cat /etc/init.d/rc.S
#! /bin/sh
##########################################################################################
##########################################################################################
## Wird bei Broadcom bereits in einem anderen Script davor gemounted
mount -t proc proc /proc
mount -t tmpfs tmpfs /var
tar xf var.tar
if cat /proc/mounts | grep -q 'devtmpfs .*/dev' ; then
echo "nop - do not mount /dev"
else
tar cf /var/devices.tar /dev
mount -t tmpfs tmpfs /dev
tar xf /var/devices.tar
rm /var/devices.tar
fi
mount -t sysfs sysfs /sys
mkdir -p /dev/pts
mount -t devpts devpts /dev/pts
[ -d /sys/kernel/debug ] && mount -t debugfs none /sys/kernel/debug
if [ -e /etc/init.d/rc.core_sync.sh ] ; then
. /etc/init.d/rc.core_sync.sh
fi
##########################################################################################
## Festlegung des Dateinamens:
## [Kennbuchstabe][GruppenId][SubGruppeId]-<name>
## Kennbuchstaben:
## s/S shell Skript wird als Source gelesen
## e/E shell Skript wird mittels sh ausgeführt
## Große Buchstaben werden beim Systemstart, kleine beim Reboot genutzt.
## Aufteilung der Gruppen:
## 0x preinit
## 1x default Daten und Links zur Verfügung stellen
## 2x udev und andere system dämons starten
## 3x ---
## 4x netzwerk Komponenten
## 5x usb Komponenten
## 6x wlan Komponenten
## 7x Starten der Applikationen
## 8x ---
## 9x Abschluss der Initialisierung des Systems
## ACHTUNG: Alle Mitglieder einer Gruppe müssen so unabhängig sein dass die prinziepiell
## parrallel startbar sein sollen
##########################################################################################
for gruppe in 0 1 2 3 4 5 6 7 8 9 ; do
echo "source files in group ${gruppe} ...";
if ls /etc/init.d/S${gruppe}[0-9]-* 2>/dev/null ; then
[ $gruppe -eq 9 ] && /bin/sh /wrapper/etc/init.d/rc.shellinaboxd start
for skript in `ls /etc/init.d/S${gruppe}[0-9]-* | sort` ; do
echo "source ${skript}"
if [ ! -f /var/skip_init ] ; then
. ${skript}
else
echo "skip_init: ${skript} "
fi
done
fi
echo "execute files in group ${gruppe} ...";
if ls /etc/init.d/E${gruppe}[0-9]-* 2>/dev/null ; then
for skript in `ls /etc/init.d/E${gruppe}[0-9]-* | sort` ; do
echo "execute ${skript}"
if [ ! -f /var/skip_init ] ; then
if ! sh ${skript} ; then
echo "execute ${skript} failed."
fi
else
echo "skip_init: ${skript} "
fi
done
fi
echo "group ${gruppe} done ...";
done
echo "rc.S: System init scripts finished; detaching from console."
sleep 1
/usr/bin/detach
exit 0
+ sed -n -e s|^[ ]*\([0-9]*\) tffs$|\1|p /proc/devices
+ tffs=243
+ [ 3 -gt 0 ]
+ tffs_name=/tmp/add_startup_script.tffs
+ mknod /tmp/add_startup_script.tffs c 243 141
+ [ -c /tmp/add_startup_script.tffs ]
+ cat /tmp/add_startup_script.tffs /tmp/add_startup_script.log
root@FB7490:~ $
Code:
root@FB7490:~ $ echo clear_id 141 >/proc/tffs
root@FB7490:~ $ cat /var/flash/calllog
root@FB7490:~ $Wenn jemand eine Modifikation verwendet, die als "Verarbeitung der /var/flash/calllog bei eingehenden Anrufen reaktivieren" beschrieben ist (und ich hatte ja meine - weiter oben dargelegten - Gründe, den Patch nicht einfach "Telefon-Codes benutzbar machen" zu nennen), dann erwarte ich eigentlich auch, daß er sich kundig macht, was denn in dieser Datei wohl stehen mag. Wenn da nur ein
Code:
#! /bin/sh
exit 0EDIT: Links hinzugefügt
Zuletzt bearbeitet:
Fireball3
Mitglied
- Mitglied seit
- 22 Dez 2005
- Beiträge
- 286
- Punkte für Reaktionen
- 0
- Punkte
- 16
Ja, ich vermute da liegst Du relativ richtig. Ich muss es noch nachprüfen, aber die Indizien zeigen in die Richtung. Beim Eingehen eines Anrufes fliegt die Box.
Ich habe Deinen Beitrag nochmal gelesen und bin nicht sicher, ob ich das richtig verstanden habe.
Ein SIAB-Injektions-Image schreibt seinen log ins /var/flash/calllog und der modfs nimmt das mit ins neu erstellte Image?
Ich muss nochmal lesen gehen, aber der Zweck des calllogs ist mir noch nicht klar und was da normalerweise hinein gehört und was nicht.
Edit:
Und warum das Injektions-Image da hinein loggt?
A: OK, das ist halt dann so.
Edit2:
Und warum der Inhalt vor dem Einpacken des Images nicht geleert (oder auf Grundeinstellung gesetzt - was das auch sein mag) wird.
Edit3:
Wenn der Quark aus dem calllog ein paar Mal abgearbeitet wurde, sind die Änderungen dauerhaft bzw. ist es sinnvoll das Image neu zu flashen?
Ich habe Deinen Beitrag nochmal gelesen und bin nicht sicher, ob ich das richtig verstanden habe.
Ein SIAB-Injektions-Image schreibt seinen log ins /var/flash/calllog und der modfs nimmt das mit ins neu erstellte Image?
Ich muss nochmal lesen gehen, aber der Zweck des calllogs ist mir noch nicht klar und was da normalerweise hinein gehört und was nicht.
Edit:
Und warum das Injektions-Image da hinein loggt?
A: OK, das ist halt dann so.
Edit2:
Und warum der Inhalt vor dem Einpacken des Images nicht geleert (oder auf Grundeinstellung gesetzt - was das auch sein mag) wird.
Edit3:
Wenn der Quark aus dem calllog ein paar Mal abgearbeitet wurde, sind die Änderungen dauerhaft bzw. ist es sinnvoll das Image neu zu flashen?
Zuletzt bearbeitet:
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Die "/var/flash/calllog" wurde früher (und wird heute noch, wenn der "telefon"-Daemon im "privaten Modus" läuft) bei jedem eingehenden Anruf ausgeführt.
Das wurde in der "normalen" Firmware von AVM dann mal abgeschaltet, gleichzeitig blieb jedoch der Ex- und Import dieser Datei beim Sichern und Wiederherstellen der Einstellungen erhalten. Damit kann man also auch bei einer Box ohne Shell-Zugriff auf den Inhalt dieser Datei zugreifen ... und genau deshalb schreibt das Skript zum "Impfen" einer Box mit originaler Firmware in diese Datei hinein ... sie wird dort nämlich nicht ausgeführt und trotzdem kann man ihren Inhalt (auch mit den "regulären Mitteln" des FRITZ!OS) ansehen - das ist für andere Dateien gar nicht so einfach, wie man denken würde. Ohne gestarteten USB-Stack und gemountete Volumes kann man dort auch kein Protokoll ablegen und auch das YAFFS2-FS für NAS ist nicht überall erreichbar - die 7412 hat zum Beispiel keine NAS-Funktionen und damit kommt man dort unter der "originalen Firmware" gar nicht an den Inhalt irgendwelcher Dateien unter "/var/media/ftp" heran, selbst wenn man dorthin vermutlich schon protokollieren könnte, wenn man den Speicher mountet.
Der Dateiinhalt wird also nicht beim "modfs" irgendwo eingebunden ... aber wenn man den "mod_enable_calllog" verwendet, wird eben ihre Abarbeitung bei eingehenden Anrufen wieder reaktiviert und dann wird genau das ausgeführt, was zuvor vom Image zum Implantieren von SIAB dort abgelegt wurde als Protokoll.
Das sind zwei vollkommen unabhängige Vorgänge ... und wie bereits geschrieben: Wenn man sich der Konsequenzen bewußt ist (und rechtzeitig ein "exit" erfolgt), stört das "Fortschreiben" dieser Datei durch das Image auch nicht wirklich - allerdings muß man dann auch irgendwann den Inhalt der Datei mal auswerten/auslesen/löschen, wenn man zu oft das Image anwendet, denn es wird eben fortgeschrieben und bei 32 KB (ZIP-komprimiert) ist Schluß mit lustig.
--------------------------------------------------------------------------------------------------
Es gibt zwar beim "mod_rc_tail_sh" eine Ausnahme von dieser Regel und da schreibt das Skript tatsächlich auch auf der aktuell verwendeten Box (wo "modfs" ausgeführt wird) etwas in die "rc.user" - aber auch nur dann, wenn die ansonsten vollkommen leer ist und damit wird nichts anderes beeinflußt, weil die Datei ohne den Patch (wenn sie leer ist, darf man unterstellen, daß der Patch zuvor auch auf diesem System nicht angewendet wurde) auch nicht zur Ausführung gelangt ... und letztlich ist das eingefügte Kommando, was nur eine zusätzliche Zeile ins Event-Log schreibt, auch absolut harmlos.
Auch verwechselst Du hier ganz offensichtlich zwei unterschiedliche "Speicher" (ist aber auch wieder alles beschrieben, also kann ich mir den Hinweis auf "mehr Lesen" auch nicht ganz verkneifen) - während das Image tatsächlich zweimal existiert (für jedes System eines), gibt es die "/var/flash/calllog" eben nur ein einziges Mal - die ist Bestandteil der Einstellungen, die für beide Systeme gelten. Basierend auf der Feststellung, daß die ex- und importiert wird, ist das aber irgendwo auch klar - warum sollte etwas exportiert werden, was normalerweise "read-only" ist (wie alles im SquashFS) ... das kann man ja dann auch nicht wieder importieren.
Da ist also nichts mit "Löschen vor dem Einpacken" ... nicht einmal mit "Löschen beim Patch", weil man gar nicht entscheiden kann (ohne sehr ausführliche Tests), ob das "absichtlicher Inhalt" in dieser Datei ist (der auch tatsächlich bei einem eingehenden Anruf ausgeführt werden soll auf dem "build host") oder ob das Kunst wäre oder ob das wirklich weg kann.
Ich kann ja auch nachvollziehen, daß man sich als "Neuling" so manche Frage stellt, warum etwas so und nicht anders umgesetzt wurde. Das ist (in Grenzen) auch legitim ... aber ich bin nun bei Erklärungen auch nicht so zurückhaltend, daß man nur sehr schlechte Chancen hätte, daß ich meine Überlegungen bei bestimmten Patches auch aufgeschrieben habe (und zwar schon in der Vergangenheit) und man das also einfach nachlesen könnte, ohne daß ich es (erneut) beantworten muß - einfach mal mit dem Namen so eines Patches auf die Suche gehen, ist bestimmt auch keine so abwegige Idee.
Und ebenso häufig mache ich mir tatsächlich auch Gedanken, warum ich etwas so und nicht anders implementiere ... wenn man also Verbesserungsvorschläge hat, wäre es schöner, wenn man diese dann auch mit passenden Begründungen abgibt, warum das besser ist und warum es an anderen Stellen (für die ich meine Gründe dargelegt habe in der Vergangenheit) nicht schadet oder warum meine alten Überlegungen keine Rolle mehr spielen sollten.
Das erspart mir doppelte Erklärungen und es zeigt gleichzeitig, daß man Notiz genommen hat von meinen Überlegungen und trotzdem der Ansicht ist, man hätte die bessere Alternative vorzuschlagen. Was auch absolut sein kann, nicht daß man das mißversteht ... aber es macht auch nicht wirklich Spaß, dasselbe mehrfach zu schreiben (auch wenn's vielleicht die Chancen erhöht, daß jemand davon Notiz nimmt), nur weil jemand anderes die richtige Stelle nicht gefunden hat, wo ich das schon einmal beschrieben hatte.
Wenn es Änderungen an den Einstellungen sind, die durch die (falschen) Statements in der "calllog" vorgenommen würden, sind die auch bereits nach dem ersten Mal persistent und es spielt gar keine Rolle, wie oft man diese Kommandos noch abarbeiten läßt.
Das wurde in der "normalen" Firmware von AVM dann mal abgeschaltet, gleichzeitig blieb jedoch der Ex- und Import dieser Datei beim Sichern und Wiederherstellen der Einstellungen erhalten. Damit kann man also auch bei einer Box ohne Shell-Zugriff auf den Inhalt dieser Datei zugreifen ... und genau deshalb schreibt das Skript zum "Impfen" einer Box mit originaler Firmware in diese Datei hinein ... sie wird dort nämlich nicht ausgeführt und trotzdem kann man ihren Inhalt (auch mit den "regulären Mitteln" des FRITZ!OS) ansehen - das ist für andere Dateien gar nicht so einfach, wie man denken würde. Ohne gestarteten USB-Stack und gemountete Volumes kann man dort auch kein Protokoll ablegen und auch das YAFFS2-FS für NAS ist nicht überall erreichbar - die 7412 hat zum Beispiel keine NAS-Funktionen und damit kommt man dort unter der "originalen Firmware" gar nicht an den Inhalt irgendwelcher Dateien unter "/var/media/ftp" heran, selbst wenn man dorthin vermutlich schon protokollieren könnte, wenn man den Speicher mountet.
Der Dateiinhalt wird also nicht beim "modfs" irgendwo eingebunden ... aber wenn man den "mod_enable_calllog" verwendet, wird eben ihre Abarbeitung bei eingehenden Anrufen wieder reaktiviert und dann wird genau das ausgeführt, was zuvor vom Image zum Implantieren von SIAB dort abgelegt wurde als Protokoll.
Das sind zwei vollkommen unabhängige Vorgänge ... und wie bereits geschrieben: Wenn man sich der Konsequenzen bewußt ist (und rechtzeitig ein "exit" erfolgt), stört das "Fortschreiben" dieser Datei durch das Image auch nicht wirklich - allerdings muß man dann auch irgendwann den Inhalt der Datei mal auswerten/auslesen/löschen, wenn man zu oft das Image anwendet, denn es wird eben fortgeschrieben und bei 32 KB (ZIP-komprimiert) ist Schluß mit lustig.
--------------------------------------------------------------------------------------------------
Weil es nicht "Pflicht" ist, das "modfs" auf der Box auszuführen, wo das erzeugte Image auch installiert werden soll - die verschiedenen Modi sind aber dokumentiert und können nachgelesen werden. Die "/var/flash/calllog" ist auch gar kein Bestandteil des erzeugten Images und daher per se schon nicht vom "modfs" auf dem "build host" zu verändern.
Es gibt zwar beim "mod_rc_tail_sh" eine Ausnahme von dieser Regel und da schreibt das Skript tatsächlich auch auf der aktuell verwendeten Box (wo "modfs" ausgeführt wird) etwas in die "rc.user" - aber auch nur dann, wenn die ansonsten vollkommen leer ist und damit wird nichts anderes beeinflußt, weil die Datei ohne den Patch (wenn sie leer ist, darf man unterstellen, daß der Patch zuvor auch auf diesem System nicht angewendet wurde) auch nicht zur Ausführung gelangt ... und letztlich ist das eingefügte Kommando, was nur eine zusätzliche Zeile ins Event-Log schreibt, auch absolut harmlos.
Auch verwechselst Du hier ganz offensichtlich zwei unterschiedliche "Speicher" (ist aber auch wieder alles beschrieben, also kann ich mir den Hinweis auf "mehr Lesen" auch nicht ganz verkneifen) - während das Image tatsächlich zweimal existiert (für jedes System eines), gibt es die "/var/flash/calllog" eben nur ein einziges Mal - die ist Bestandteil der Einstellungen, die für beide Systeme gelten. Basierend auf der Feststellung, daß die ex- und importiert wird, ist das aber irgendwo auch klar - warum sollte etwas exportiert werden, was normalerweise "read-only" ist (wie alles im SquashFS) ... das kann man ja dann auch nicht wieder importieren.
Da ist also nichts mit "Löschen vor dem Einpacken" ... nicht einmal mit "Löschen beim Patch", weil man gar nicht entscheiden kann (ohne sehr ausführliche Tests), ob das "absichtlicher Inhalt" in dieser Datei ist (der auch tatsächlich bei einem eingehenden Anruf ausgeführt werden soll auf dem "build host") oder ob das Kunst wäre oder ob das wirklich weg kann.
Ich kann ja auch nachvollziehen, daß man sich als "Neuling" so manche Frage stellt, warum etwas so und nicht anders umgesetzt wurde. Das ist (in Grenzen) auch legitim ... aber ich bin nun bei Erklärungen auch nicht so zurückhaltend, daß man nur sehr schlechte Chancen hätte, daß ich meine Überlegungen bei bestimmten Patches auch aufgeschrieben habe (und zwar schon in der Vergangenheit) und man das also einfach nachlesen könnte, ohne daß ich es (erneut) beantworten muß - einfach mal mit dem Namen so eines Patches auf die Suche gehen, ist bestimmt auch keine so abwegige Idee.
Und ebenso häufig mache ich mir tatsächlich auch Gedanken, warum ich etwas so und nicht anders implementiere ... wenn man also Verbesserungsvorschläge hat, wäre es schöner, wenn man diese dann auch mit passenden Begründungen abgibt, warum das besser ist und warum es an anderen Stellen (für die ich meine Gründe dargelegt habe in der Vergangenheit) nicht schadet oder warum meine alten Überlegungen keine Rolle mehr spielen sollten.
Das erspart mir doppelte Erklärungen und es zeigt gleichzeitig, daß man Notiz genommen hat von meinen Überlegungen und trotzdem der Ansicht ist, man hätte die bessere Alternative vorzuschlagen. Was auch absolut sein kann, nicht daß man das mißversteht ... aber es macht auch nicht wirklich Spaß, dasselbe mehrfach zu schreiben (auch wenn's vielleicht die Chancen erhöht, daß jemand davon Notiz nimmt), nur weil jemand anderes die richtige Stelle nicht gefunden hat, wo ich das schon einmal beschrieben hatte.
Auch hier hast Du vermutlich wieder das Verständnisproblem für den Aufbau der AVM-Firmware und -Geräte ... egal wie oft man die "calllog" bei einem Anruf auch abarbeitet - solange darin keine Kommandos enthalten sind, die ein SquashFS-Image verändern würden, wird auch das Image nicht geändert - warum sollte man also ein neues erstellen lassen?.
Wenn es Änderungen an den Einstellungen sind, die durch die (falschen) Statements in der "calllog" vorgenommen würden, sind die auch bereits nach dem ersten Mal persistent und es spielt gar keine Rolle, wie oft man diese Kommandos noch abarbeiten läßt.
Neueste Beiträge
-
[Problem] Tonwahl beim T48S- Letzte: NDiIPP
-
[Frage] Dect-WS500S Verbindungen an Compact 4000
- Letzte: oezi
-
Analoges Wählgerät einer Alarmanlage an VoIP betreiben ...
- Letzte: provisorischerFtmmsch
-
[Frage] Kompletter Ausfall von DNS over TLS (DoT)- Letzte: stoney
