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

Danke für die Erklärung zum calllog.
Das war auch genau die Ursache für die Abstürze.

Ich gebe zu, mit den Speicherarchitekturen habe ich mich nicht beschäftigt.
Da kann man sicher ein paar Stunden Material dazu konsumieren.
Man muss allerdings als "Neuling" auch irgendwo dem Faden folgen, sonst kommt man nie ans Ziel.
Genügend Interesse vorausgesetzt, ist das hier ja auch wie Wikipedia lesen.
Wenn man nicht aufpasst hat man vergessen, was man eigentlich gesucht hat. :confused:

Im Falle der calllog und des SIAB-Injektions-Image war es aber nur eine Frage der Zeit, bis einer über das Problem stolpert - lesen hin oder her. Das Hintergrundwissen (Themen: Speicher + calllog + SIAB loggt da rein) muss erstmal an einer Stelle zusammen finden, verstanden und weiter gedacht werden. o_O
Ich traue mich wetten, dass die meisten die das SIAB auf diese Art und Weise "untergeschoben" haben, unbewußt mit dem log-Inhalt im calllog weiter leben.
Wenn man das SIAB-image nicht gerade 4oder5 mal versucht, packt die Box das vermutlich.
Anbei der Inhalt der calllog. Da müssten auch die erfolglosen Versuche mit dem 3.10.107 SIAB-Image geloggt sein.

# cat /var/flash/calllog
+ 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.shellin aboxd 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
################################################################################ ##########
################################################################################ ##########
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
################################################################################ ##########
## 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 pr inziepiell
## 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 /etc/init.d/S${gruppe}[0-9]-* ; do
. ${skript}
done
fi
echo "exceute files in group ${gruppe} ...";
if ls /etc/init.d/E${gruppe}[0-9]-* 2>/dev/null ; then
for skript in /etc/init.d/E${gruppe}[0-9]-* ; do
if ! sh ${skript} ; then
echo "exceute ${skript} failed.";
fi
done
fi
echo "group ${gruppe} done ...";
done
echo "System init finished ...";
+ 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
+ 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.shellin aboxd 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
################################################################################ ##########
################################################################################ ##########
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
################################################################################ ##########
## 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 pr inziepiell
## 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 /etc/init.d/S${gruppe}[0-9]-* ; do
. ${skript}
done
fi
echo "exceute files in group ${gruppe} ...";
if ls /etc/init.d/E${gruppe}[0-9]-* 2>/dev/null ; then
for skript in /etc/init.d/E${gruppe}[0-9]-* ; do
if ! sh ${skript} ; then
echo "exceute ${skript} failed.";
fi
done
fi
echo "group ${gruppe} done ...";
done
echo "System init finished ...";
+ 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
+ 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.shellin aboxd 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
################################################################################ ##########
################################################################################ ##########
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
################################################################################ ##########
## 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 pr inziepiell
## 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 /etc/init.d/S${gruppe}[0-9]-* ; do
. ${skript}
done
fi
echo "exceute files in group ${gruppe} ...";
if ls /etc/init.d/E${gruppe}[0-9]-* 2>/dev/null ; then
for skript in /etc/init.d/E${gruppe}[0-9]-* ; do
if ! sh ${skript} ; then
echo "exceute ${skript} failed.";
fi
done
fi
echo "group ${gruppe} done ...";
done
echo "System init finished ...";
+ 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

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.
Gut, modfs ist nicht dafür verantwortlich, es hinterläßt ja die SIAB-Image-Injektion die Reste.
Dann sollte das Aufräumen da passieren. Ob das nun technisch möglich ist oder ob man die Aufgabe am Ende doch anderweitig auslagert kann ich nicht sagen, aber nur über die Erklärung im Forum wird man das "Problem" nicht in den Griff bekommen.

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.
Es ist ja nicht so, dass man zu faul zum Lesen wäre, aber ein Grundschüler wird einer Uni-Vorlesung auch nur in Teilen folgen können - wenn überhaupt (ohne Anderen hier zu nahe treten zu wollen) ;).

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.
Verstanden, die Frage ist ob man diese Änderungen auch gleich mibekommt oder klappt irgenwann etwas um und man weiß nicht wieso?
 
Ich habe mir zwischenzeitlich überlegt, das Kopieren des Debug-Logs vom "add_startup_skript" noch so abzuändern, daß da als erstes noch ein "exit"-Statement in die "calllog" geschrieben wird. Das sorgt zumindest dafür, daß es nicht mehr bis zu den Statements aus der "rc.S" geht und selbst wenn da vorher schon anderer Content drin steht, stört das Fortschreiben mit einem zusätzlichen "exit" auch nicht wirklich.

Ich selbst brauche das Protokollieren eigentlich auch nicht ... ich habe ja die Serielle. Aber wer das quasi "blind" macht beim "implant_siab...", der hat keine andere Möglichkeit der Kontrolle bzw. Fehlersuche.

Wobei es an der Änderung der "rc.S" ohnehin nicht liegt, wenn "shellinaboxd" in 3.10.107 tatsächlich nicht starten sollte ... die relevante Zeile mit dem "if ls ... S$gruppe" ist sowohl bei der 06.93 als auch bei der 07.01 vorhanden, das hatte ich schon geprüft.

Das, was Du da aus der "calllog" zeigst, kann aber von keiner 07.01 sein - denn dann würde die "rc.S" mit einem "detach" enden und nicht mit dem "echo", wie man das oben sieht. Da hat sich also keine einzige 07.01 beim Startversuch mit ihrem Protokoll verewigt - bleibt die Frage, ob das entsprechende Image die Daten nicht richtig in die "wrapper"-Partition schreiben konnte, denn dann kommt man natürlich auch nicht beim "add_startup_script"-Aufruf vorbei.

Aber auch das erklärt ja noch nicht richtig, warum da - wenn Du doch die 07.01 installiert und gestartet haben willst, ansonsten wäre das ja das falsche "implant_siab_..."-Image gewesen, wenn Du mit der 3.10.107 probiert hast - kein einziger Versuch von der 3.10.107 aus protokolliert ist ... oder bist Du dann wieder auf eine 06.93 zurück? Ich hatte ja schon mal festgestellt, daß die "implant_siab_..."-Images eigentlich austauschbar sein sollten zwischen den Kernel-Versionen, denn die sind statisch gelinkt. Man hätte also auch problemlos das 3.10.73-Image für eine 07.01 verwenden können.

Ansonsten ist halt die Reaktivierung des "calllog" als Patch noch ziemlich neu ... ich habe auch lange überlegt, ob ich das überhaupt "anbieten" sollte (und ohne das Abschalten der Telefon-Codes hätte ich es vermutlich auch nicht getan) - eben weil ich die "calllog" häufiger mal "mißbraucht" habe. Das geht zurück bis zum Shell-Zugang für die 6360: https://www.ip-phone-forum.de/threa...der-was-kann-man-damit-schon-anfangen.278703/ ... und wie ich schon mal gezeigt hatte, ist die Feststellung, daß im "private mode" auch die "calllog" wieder verarbeitet wird, schon über sechs Monate alt gewesen (wenn sie auch weitgehend untergegangen ist).

Wegen der recht kurzen Verfügbarkeit des "mod_enable_calllog"-Patches gab es bisher noch nicht so viele "Unfälle" ... ich weiß auch beim besten Willen nicht, wo man (allerdings sinnvoll, das ist Voraussetzung) den Inhalt der "calllog" bei Patchen löschen sollte.

Es gibt eigentlich auch gar kein "Problem", solange man sich direkt mit dem verfügbaren Shell-Zugang (dazu dient das Image ja schließlich) daran macht, das Debug-Protokoll vom "Impfen" zu löschen - allerdings wird ja bei jedem neuen Systemstart auch das Debug-Protokoll wieder gesichert - es wäre ja dämlich, wenn die SIAB-Instanz nach dem Einpflanzen nur ein einziges Mal startet. Erst das neue Schreiben der "wrapper"-Partition (wenn man ein neues System installiert - egal womit man das macht) entfernt dann den Code, der bei jedem Start die "shellinaboxd"-Instanz startet - dann wird der aber auch nicht mehr wirklich gebraucht.
 
Aber auch das erklärt ja noch nicht richtig, warum da - wenn Du doch die 07.01 installiert und gestartet haben willst, ansonsten wäre das ja das falsche "implant_siab_..."-Image gewesen, wenn Du mit der 3.10.107 probiert hast - kein einziger Versuch von der 3.10.107 aus protokolliert ist ... oder bist Du dann wieder auf eine 06.93 zurück?
Ja, ich habe die 6.93 Recovery aufgespielt und dann das 3.10.73 SIAB-Image. Vermutlich fehlt mir an dieser Stelle wieder ein Puzzlestück, wenn ich davon aus gehe, dass das calllog den Recover überlebt!?

Man hätte also auch problemlos das 3.10.73-Image für eine 07.01 verwenden können.
Ich meine, das auch versucht zu haben. Sicher bin ich mir allerdings nicht mehr.

Ansonsten ist halt die Reaktivierung des "calllog" als Patch noch ziemlich neu ... ich habe auch lange überlegt, ob ich das überhaupt "anbieten" sollte
Du hattest ja noch "mod_telnet_start_as_dtrace" als Möglichkeit aufgeführt. Ist das eine bessere Lösung? Wäre aber auch nur ein "Umschiffen" des Problems mit der calllog.

Es gibt eigentlich auch gar kein "Problem", solange man sich direkt mit dem verfügbaren Shell-Zugang (dazu dient das Image ja schließlich) daran macht, das Debug-Protokoll vom "Impfen" zu löschen
Das ist kein Problem, wenn man darauf gestoßen würde - am Besten gleich wenn man SIAB erstmalig startet.

allerdings wird ja bei jedem neuen Systemstart auch das Debug-Protokoll wieder gesichert - es wäre ja dämlich, wenn die SIAB-Instanz nach dem Einpflanzen nur ein einziges Mal startet. Erst das neue Schreiben der "wrapper"-Partition (wenn man ein neues System installiert - egal womit man das macht) entfernt dann den Code, der bei jedem Start die "shellinaboxd"-Instanz startet - dann wird der aber auch nicht mehr wirklich gebraucht.
Das verstehe ich jetzt nicht. Habe offensichtlich noch Wissenslücken bezüglich des Ablaufs wie/wann das log ins calllog kommt. Bis jetzt dachte ich, das kommt einmalig beim Injezieren rein. Und da das log übergreifend gilt, also egal welches Image aktiv ist, sollte es nach einmaligem Löschen auch für immer weg sein.
 
Gehört zwar eigentlich nicht in diesen Thread, aber ich erkläre mal den Ablauf noch einmal:

Das Image wird in den Speicher der Box geladen und dort gestartet. Das mountet dann nur das YAFFS2-Dateisystem in der Partition des aktiven Systems (und zwar mit Schreibzugriff, wo das FRITZ!OS es sich ansonsten read-only mounten würde) und kopiert ein paar Dateien zusätzlich in diese Partition. Parallel wird die dort liegende "/etc/inittab" (darin stehen die beim Start auszuführenden Kommandos für das FRITZ!OS) so geändert, daß eine dieser zusätzlichen Dateien ausgeführt wird, nachdem ein paar Vorbereitungsarbeiten (insb. das Mounten des richtigen "rootfs" aus der "filesystem_core.squashfs" in der YAFFS2-Partition) erledigt sind.

Bevor es aber zu dieser Ausführung kommt, wird die Box erst einmal neu gestartet ... denn diese Änderung erfolgt(e) ja für das installierte FRITZ!OS in der Box und nicht für das zuvor in den Speicher geladene Image (aber eben durch dieses Image). Das Dateisystem in der YAFFS2-Partition ist aber das einzige, was man ohne größeren Aufwand beschreibbar machen kann ... um ein SquashFS-Image zu ändern, muß man das tatsächlich erst neu packen, weil es da keine Möglichkeit gibt, ein solches Dateisystem auch r/w zu benutzen.

Deshalb wird dieser zusätzliche Aufruf genau an dieser Stelle eingebaut und deshalb funktioniert diese Art des "Impfens" auch nur bei den Modellen, die mit dem YAFFS2-Dateisystem in der "filesystem"-Partition arbeiten (das sind überwiegend die VR9-Boxen, zzgl. der beiden AR10-Boxen).

Bei den GRX5-Modellen gibt es das YAFFS2 nicht und man müßte das SquashFS in den UBI-Partitionen erst neu packen (mit den passenden Änderungen), bevor man das ganze Image wieder in die Partition schreiben kann - eine Änderung, die nur mal schnell eine oder zwei Dateien dort hinzufügt, gibt es nicht ... das braucht das komplette Neupacken (und das ist der Prozess, der bei "modfs" > 80% der (Prozessor-)Zeit verbraucht).

Jedenfalls startet also die Box dann neu und jetzt wird beim Start auch der zusätzliche Aufruf aus der "/etc/inittab" in der YAFFS2-Partition wirksam und das dort angegebene Skript gestartet. Zu diesem Zeitpunkt ist aber das System nur in Teilen "hochgefahren" (praktisch ist noch nicht ein Service gestartet, der nicht direkt im Kernel implementiert ist) und so kann man da noch keinen "shellinaboxd" starten, der viel mehr Voraussetzungen bräuchte (angefangen beim Netzwerk).

Deshalb geht dieses erste Skript nur hin und ändert die "Startdatei" des Systems (/etc/init.d/rc.S) temporär so ab, daß gegen Ende der Systeminitialisierung (wenn die ganzen anderen Services schon gestartet sind) auch noch der "shellinaboxd" gestartet wird ... in die "Gruppe 9" der Init-Skripte wird noch ein Aufruf der "/wrapper/etc/init.d/rc.shellinaboxd" (das ist eine der Dateien, die das SIAB-Image dort hineinkopiert hat) eingebaut.

Genau das ist es auch, was in die "calllog" protokolliert wird (bzw. eigentlich wird ja erst mal ins "tmpfs" protokolliert und nur am Ende ins TFFS kopiert) - der Vorgang der Änderung an der "rc.S" und zu diesem Protokoll gehört auch die Ansicht, wie die "rc.S" nach der Änderung dann aussieht.

Da dieser Vorgang auch bei jedem Systemstart ausgeführt wird (er muß ja immer wieder erfolgen, weil eben das SquashFS-Image mit dem "eigentlichen System" nicht geändert wird - dafür wäre dann "modfs" zuständig), wächst die "calllog" auch immer weiter - ich habe auch nicht ganz umsonst immer betont, daß es sich bei diesem "Impfen" nur um den Schlüssel zum Eingang der FRITZ!Box handelt und das keine dauerhafte Lösung darstellen soll (und in dieser Form auch nicht darstellen kann). Das Ding wurde von mir nicht ohne Vorbedacht als "modfs-Starter 2.0" angekündigt ...

Wer tatsächlich diesen implantierten SIAB-Service als Dauerlösung nutzen will, der muß sich selbst ein passendes Image erstellen mit dem "build_shellinabox_implant_image"-Skript und dabei die "-d"-Optionen beim Aufruf von "add_startup_script" (es gibt drei davon) weglassen ... dann kopiert "add_startup_script" das Debug-Protokoll nicht ins TFFS.

Ansonsten interessiert(e) bisher auch der Inhalt der "calllog" nicht wirklich (die Abarbeitung erfolgte in der AVM-Firmware ja nicht mehr) und wenn der Benutzer sich an die "Gebrauchsanweisung" hält und das tatsächlich nur benutzt, um in der Shell danach mit "modfs" eine "richtige" Modifikation auszuführen, dann macht er vielleicht zwei oder drei Starts mit dem implantierten "shellinaboxd" - danach ist dann ohnehin sein neues, mit "modfs" erstelltes System aktiv und da ist der ganze Part des "Impfens" dann automatisch nicht mehr enthalten, weil das neue System auch ein anderes YAFFS2-Dateisystem hat und damit die Aufrufe dort in der "/etc/inittab" genauso fehlen, wie die notwendigen anderen Dateien.
 
Gehört zwar eigentlich nicht in diesen Thread, aber ich erkläre mal den Ablauf noch einmal:
Danke für die Geduld! Das habe ich jetzt auch verstanden.
Also jedes mal, wenn man das System mit dem geimpften SIAB hochfährt, wird in die calllog protokolliert. Das hatte ich falsch verstanden.
PeterPawn schrieb:
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.
Und weil die Einstellungen für beide Systeme gelten sollte man daran denken und die calllog leeren.
Idee: Den Inhalt von tmpfs mit Kommentarzeichen versehen, bevor sie ins calllog wandern? Dann wären sie noch vorhanden würden jedoch keinen stören.
Wer tatsächlich diesen implantierten SIAB-Service als Dauerlösung nutzen will, der muß sich selbst ein passendes Image erstellen
Oder man lädt, aus dem telnet-befähigten System, die inaktive YAFFS2 und ändert das so.
 
Idee: Den Inhalt von tmpfs mit Kommentarzeichen versehen, bevor sie ins calllog wandern? Dann wären sie noch vorhanden würden jedoch keinen stören.
Genau das habe ich doch in #1582 gerade erst als Vorhaben angeführt? Zwar nicht mit "Kommentarzeichen", aber mit einem "exit" davor und damit kommt die Abarbeitung auch nicht mehr weiter. Was ist da jetzt anders, wenn man das mit Kommentaren machen wollte?
 
So, ich habe jetzt die Images neu erstellt, mit einem geänderten Skript-File.

Bei der 3.10.107 startete nämlich der "shellinaboxd" tatsächlich nicht ... aber nicht, weil die "Integration" in die vorhandenen AVM-Dateien nicht mehr funktionieren würde, sondern weil ich das ursprünglich so "eingetaktet" hatte, daß es vor den S9x-Dateien ausgeführt wird. Nur gibt es in der 07.0x keine S9x-Dateien mehr und damit wird der ganze Zweig nicht ausgeführt, wo das zusätzliche Kommando eingefügt wurde.

Zur "Behebung" des Problems war es bereits ausreichend, den Aufruf einfach um eine Zeile in der "rc.S" nach oben zu schieben. Dabei habe ich auch gleich noch das "exit"-Statement am Beginn und eine Trennzeile für die leichtere Erkennung mehrerer Ausgaben eingebaut.

Damit funktioniert das "implant_siab_..." jetzt auch bei der 07.0x - die Vorgängerversionen sollte es auch nicht stören, wenn der Aufruf jetzt eine Zeile höher erfolgt.

Code:
  1 exit
  2 # <<<<< debug output of /wrapper/sbin/add_startup_script /wrapper/etc/init.d/rc.shellinaboxd start >>>>>
  3 + new_script=/wrapper/etc/init.d/rc.shellinaboxd
  4 + shift
  5 + cp /etc/init.d/rc.S /tmp/init_rc_replacement
  6 + sed -e /^if ls.*S/i[ $gruppe -eq 9 ] && printf "Starting '%s %s'\\n" /wrapper/etc/init.d/rc.shellinaboxd "start" >/dev/console && /bin/sh /wrapper/etc/init.d/rc.shellinaboxd start -i /tmp/init_rc_replacement
  7 + mount -o bind /tmp/init_rc_replacement /etc/init.d/rc.S
  8 + [ 1 -eq 1 ]
  9 + cat /etc/init.d/rc.S
 10 #! /bin/sh
 11 ##########################################################################################
 12 ##########################################################################################
 13 ## Wird bei Broadcom bereits in einem anderen Script davor gemounted
 14 mount -t proc proc /proc
 15 mount -t tmpfs tmpfs /var
 16 tar xf var.tar
 17 if cat /proc/mounts | grep -q 'devtmpfs .*/dev' ; then
 18 echo "nop - do not mount /dev"
 19 else
 20 tar cf /var/devices.tar /dev
 21 mount -t tmpfs tmpfs /dev
 22 tar xf /var/devices.tar
 23 rm /var/devices.tar
 24 fi
 25 mount -t sysfs sysfs /sys
 26 mkdir -p /dev/pts
 27 mount -t devpts devpts /dev/pts
 28 [ -d /sys/kernel/debug ] && mount -t debugfs none /sys/kernel/debug
 29 if [ -e /etc/init.d/rc.core_sync.sh ] ; then
 30 . /etc/init.d/rc.core_sync.sh
 31 fi
 32 ##########################################################################################
 33 ## Festlegung des Dateinamens:
 34 ## [Kennbuchstabe][GruppenId][SubGruppeId]-<name>
 35 ## Kennbuchstaben:
 36 ## s/S shell Skript wird als Source gelesen
 37 ## e/E shell Skript wird mittels sh ausgeführt
 38 ## Große Buchstaben werden beim Systemstart, kleine beim Reboot genutzt.
 39 ## Aufteilung der Gruppen:
 40 ## 0x preinit
 41 ## 1x default Daten und Links zur Verfügung stellen
 42 ## 2x udev und andere system dämons starten
 43 ## 3x ---
 44 ## 4x netzwerk Komponenten
 45 ## 5x usb Komponenten
 46 ## 6x wlan Komponenten
 47 ## 7x Starten der Applikationen
 48 ## 8x ---
 49 ## 9x Abschluss der Initialisierung des Systems
 50 ## ACHTUNG: Alle Mitglieder einer Gruppe müssen so unabhängig sein dass die prinziepiell
 51 ## parrallel startbar sein sollen
 52 ##########################################################################################
 53 for gruppe in 0 1 2 3 4 5 6 7 8 9 ; do
 54 echo "source files in group ${gruppe} ...";
 55 [ $gruppe -eq 9 ] && printf "Starting '%s %s'\n" /wrapper/etc/init.d/rc.shellinaboxd "start" >/dev/console && /bin/sh /wrapper/etc/init.d/rc.shellinaboxd start
 56 if ls /etc/init.d/S${gruppe}[0-9]-* 2>/dev/null ; then
 57 for skript in `ls /etc/init.d/S${gruppe}[0-9]-* | sort` ; do
 58 echo "source ${skript}"
 59 if [ ! -f /var/skip_init ] ; then
 60 . ${skript}
 61 else
 62 echo "skip_init: ${skript} "
 63 fi
 64 done
 65 fi
 66 echo "execute files in group ${gruppe} ...";
 67 if ls /etc/init.d/E${gruppe}[0-9]-* 2>/dev/null ; then
 68 for skript in `ls /etc/init.d/E${gruppe}[0-9]-* | sort` ; do
 69 echo "execute ${skript}"
 70 if [ ! -f /var/skip_init ] ; then
 71 if ! sh ${skript} ; then
 72 echo "execute ${skript} failed."
 73 fi
 74 else
 75 echo "skip_init: ${skript} "
 76 fi
 77 done
 78 fi
 79 echo "group ${gruppe} done ...";
 80 done
 81 echo "rc.S: System init scripts finished; detaching from console."
 82 sleep 1
 83 /usr/bin/detach
 84 exit 0
 85 + sed -n -e s|^[ ]*\([0-9]*\) tffs$|\1|p /proc/devices
 86 + tffs=243
 87 + [ 3 -gt 0 ]
 88 + tffs_name=/tmp/add_startup_script.tffs
 89 + mknod /tmp/add_startup_script.tffs c 243 141
 90 + [ -c /tmp/add_startup_script.tffs ]
 91 + cat /tmp/add_startup_script.tffs /tmp/add_startup_script.log
 
Zuletzt bearbeitet:
Die nächste Beta-Version ist verfügbar: http://yourfritz.de/modfs-0.5.1-beta.tgz

Geändert hat sich nur die Version des inkludierten Boot-Managers, die neue Version ist jetzt weniger anfällig für abgebrochene Ausführungen.

Ich hatte bei der 7490 den merkwürdigen Effekt, daß beim ersten Aufruf des "System"-Menüs auch (im Hintergrund) die "reboot.lua" offenbar "angestartet" wurde und dann aber der aufrufende Prozess mittendrin beendet wurde (woher der genau kam, habe ich noch nicht herausgefunden), was dann nicht nur in einer "orphaned semaphore" mündete, sondern auch in einer weiterhin gemounteten YAFFS2-Partition für das alternative System.

Beides waren keine wirklich guten Voraussetzungen für einen weiteren Aufruf aus der "reboot.lua"-Seite ... das Ergebnis war dann häufig eine Seite, in der die Auswahl des Systems nicht möglich war bzw. wo die Anzeige dann unvollständig blieb und der JavaScript-Code teilweise ins Leere lief.

Daher habe ich das mit dem Lock etwas überarbeitet (wenn das wegen eines Abbruchs tatsächlich verwaist ist, wird es gleich gelöscht) und verwende ein bereits gemountetes YAFFS2-Dateisystem für den Wrapper bei VR9 und AR10 einfach ... selbst wenn das ein "übergebliebenes" sein sollte, wird damit keine zweite Kopie mehr gemountet (auch wenn die ebenfalls r/o wäre, gibt es offenbar Probleme im YAFFS2-Treiber bei mehrfachem Mounten).

Außerdem hatte der Boot-Manager beim "umount" auch das Problem der geänderten "-d"-Option beim Entfernen von gemounteten Loop-Devices (wie zuvor schon "modfs" selbst) ... das ist nun auch berücksichtigt.

Und zu guter Letzt ist es ja eher unwahrscheinlich, daß sich zwischen zwei Aufrufen der "Neustart"-Seite etwas an den installierten Systemen ändert (man kann die Seite ja auch aufrufen, ohne auf "Neu starten" zu drücken und dann wird die auch mehrfach aufgerufen zwischen zwei Reboots) - daher wird jetzt beim ersten Aufruf die HTML-Ausgabe gespeichert und bei jedem nachfolgenden Aufruf nur noch aus der Datei ausgelesen ... mit dem Ergebnis, daß es fast keine Verzögerungen mehr beim zweiten Aufruf gibt.

Allerdings gibt das dann natürlich falsche Informationen in der Seite, wenn man zwischenzeitlich "modfs" auf der Box ausgeführt hat ... daher gibt es einen neuen Parameter "clear_cache" für den "gui_bootmanager" und wenn "modfs" einen installierten Boot-Manager findet (allerdings wird nur genau unter "/usr/bin/gui_bootmanager", wo das angebotene "modscript" ihn installieren würde, gesucht), dann schiebt es nach dem Umschalten des Systems (nach seiner Installation) noch einen passenden Aufruf hinterher.

Ich bin noch am Überlegen, wo man den ersten Aufruf von "gui_bootmanager" so einbauen könnte, daß er zu einer Zeit stattfindet, wo seine Dauer gar keine Rolle spielt ... dann würde schon der erste Aufruf der "reboot.lua"-Seite praktisch verzögerungsfrei erfolgen ... im Moment kann es da - abhängig vom Modell und der Auslastung - schon mal zu zwei bis drei Sekunden Verzögerung kommen, wenn die Daten für die Anzeige zusammengesucht werden. Am ehesten werde ich das wohl in irgendein Start-Skript packen ... dank des (neuen) Cachings ist es ja egal, wann das erfolgt. Aber das ist dann etwas für die nächste (Beta-)Version und noch nicht enthalten.

EDIT:
Nun habe ich mich kurzerhand doch noch entschlossen, das Cachen der Ausgabe gleich in die "/etc/init.d/S85-apps" mit einzubauen ... und den Cache aus "modfs" heraus nicht nur zu löschen, sondern gleich die Daten neu zu erstellen.
 
Zuletzt bearbeitet:
Hallo zusammen,

ich versuche gerade meine Fritzbox 7490 mit modfs zu updaten habe gerade 6.93 mit modfs installiert und wollte nun über ein Onlineupdate vom Hersteller auf 7.01 updaten. Habe dazu einfach die "mkdir -p /var/mod;cd /var/mod;wget -qO- http://yourfritz.de/modfs.tgz | gunzip -c | tar x;./modfs update" eingeben und bekomme immer diesen Fehler:
Code:
rmitteln der Hardware-Version ... OK
Prüfen, ob die Hardware-Version unterstützt wird ... OK
Suchen der Einstellung zur Umschaltung auf das alternative System ... OK
Prüfen der aktuell zu startenden Systemversion ... OK
Suchen der aktuellen Kernel-Partition ... OK
Suchen der alternativen Kernel-Partition ... OK
Vergleich der Systeme in den Kernel-Partitionen ... übersprungen
Suchen der aktuellen Dateisystem-Partition ... OK
Suchen der alternativen Dateisystem-Partition ... OK
Überprüfen des zur Verfügung stehenden Speicherplatzes im RAM ... OK
Überprüfen des freien Speicherplatzes für das Auspacken des Dateisystems ... OK
Überprüfen des verfügbaren Swap-Space ... OK

Das System erfüllt die Voraussetzungen zur Modifikation des root-Dateisystems.

Im Moment läuft auf der Box die Version: 113.06.93-48385

Die Auswahl des 'update'-Modus erfordert eine neuere Firmware-Version vom Hersteller.

Ermitteln der neuesten Version durch Abfrage beim Hersteller ...punt!
 OK
Es wurde eine neuere Version (113.07.01) gefunden.
Download eines Firmware-Images für Version 113.07.01 vom Server des Herstellers ... OK
Überprüfen der Signatur der geladenen Datei ... OK
mkdir: can't create directory '/1540028724': Read-only file system
Extrahieren des neuen Kernel-Images aus dem Firmware-Image ..../modfs: line 2: can't create /1540028724/kernel.image: nonexistent directory
 Fehler
Beim Extrahieren des Kernel-Abbilds aus der Firmware-Datei ist ein Fehler aufgetreten.
#

Kann mir jemand dabei helfen?

Vielen Dank.

Gruß kami
 
Hier wegen remount/noexec nachlesen. Vorsichtshalber empfehle ich einen USB-Speicherstick mit SWAP zu erstellen. Sonst hakt es u.U. gleich wieder ;)
LG
 
Ermitteln der neuesten Version durch Abfrage beim Hersteller ...punt! OK
Das ist schon die erste komische Stelle ...
mkdir: can't create directory '/1540028724': Read-only file system Extrahieren des neuen Kernel-Images aus dem Firmware-Image ..../modfs: line 2: can't create /1540028724/kernel.image: nonexistent directory Fehler
und hier fehlt dann offenkundig das "working directory" für die Speicherung von Daten beim Entpacken.

Also: Protokoll-Datei zeigen ... alles andere wäre Raten.

PS: Swap-Space ist offenbar ja da ... letzte Zeile beim Überprüfen der Voraussetzungen.

PPS: Eine generelle Fehlfunktion würde ich im Moment eigentlich ausschließen - bei mir arbeitet das auch auf "jungfräulichen" Installationen problemlos und ist damit nicht von bereits installierten Programmen abhängig.

EDIT:
OK, das "punt!" ist erklärlich ... da fehlt ein Ignorieren der Ausgabe eines "kill"-Kommandos (bzw. der Reaktion des 'nc'-Applets auf dieses 'kill').
 
Zuletzt bearbeitet:
Das ist schon die erste komische Stelle ...

und hier fehlt dann offenkundig das "working directory" für die Speicherung von Daten beim Entpacken.

Also: Protokoll-Datei zeigen ... alles andere wäre Raten.

PS: Swap-Space ist offenbar ja da ... letzte Zeile beim Überprüfen der Voraussetzungen.

PPS: Eine generelle Fehlfunktion würde ich im Moment eigentlich ausschließen - bei mir arbeitet das auch auf "jungfräulichen" Installationen problemlos und ist damit nicht von bereits installierten Programmen abhängig.

EDIT:
OK, das "punt!" ist erklärlich ... da fehlt ein Ignorieren der Ausgabe eines "kill"-Kommandos (bzw. der Reaktion des 'nc'-Applets auf dieses 'kill').

Hallo,

wo finde ich denn die Protokolldatei??

Gruß kami
 
Hier wurde es grundlegend erklärt. Kann sein, dass es überholt ist und grundsätzlich ein *.log im Arbeitsverzeichnis angelegt wird.
LG
 
Da hat sich nichts grundlegend geändert und wie man das auslesen könnte, kann man sich in der "modnow.sh" selbst ansehen. Diese ist bisher aber nur ein Vorschlag, wie man die zunehmende Menge an notwendigen Zusatzinformationen beim Aufruf von "modfs" selbst automatisieren kann.

Ich kann es auch nicht ändern, daß da noch ein paar "Entscheidungen" ständig dazukommen - die einzige Alternative zur Veränderung wäre der Stillstand und den kann jeder für sich selbst organisieren, indem er sich einen älteren Stand auscheckt und mit diesem arbeitet.
 
Hi,

hier ist der Debug Output:

Code:
showshringbuf modfs
2018-10-20 17:40:38.186 - modfs: starting modfs script version 0.5.0-071020182154
2018-10-20 17:40:38.203 - modfs: script=./modfs
2018-10-20 17:40:38.225 - modfs: using language de
2018-10-20 17:40:38.244 - modfs: PATH=/var/mod/bin/185
2018-10-20 17:40:38.262 - modfs: SHELL=/var/run/modfs/sh
2018-10-20 17:40:38.281 - modfs: SHLVL=5
2018-10-20 17:40:38.315 - modfs: BusyBox: BusyBox v1.27.2 multi-call binary.
2018-10-20 17:40:38.332 - modfs: Filesystems mounted
2018-10-20 17:40:38.350 - rootfs / rootfs rw 0 0
2018-10-20 17:40:38.350 - /dev/root /wrapper yaffs ro,relatime 0 0
2018-10-20 17:40:38.350 - devtmpfs /wrapper/dev devtmpfs rw,relatime,size=119444k,nr_inodes=29861,mode=755 0 0
2018-10-20 17:40:38.350 - /dev/loop0 / squashfs ro,relatime 0 0
2018-10-20 17:40:38.350 - devtmpfs /dev devtmpfs rw,relatime,size=119444k,nr_inodes=29861,mode=755 0 0
2018-10-20 17:40:38.350 - proc /proc proc rw,relatime 0 0
2018-10-20 17:40:38.350 - tmpfs /var tmpfs rw,relatime 0 0
2018-10-20 17:40:38.350 - sysfs /sys sysfs rw,relatime 0 0
2018-10-20 17:40:38.350 - devpts /dev/pts devpts rw,relatime,mode=600,ptmxmode=000 0 0
2018-10-20 17:40:38.350 - none /sys/kernel/debug debugfs rw,relatime 0 0
2018-10-20 17:40:38.350 - /dev/mtdblock4 /var/flash yaffs2 rw,sync,relatime 0 0
2018-10-20 17:40:38.350 - /var/dev/nand /var/media/ftp yaffs2 rw,sync,relatime 0 0
2018-10-20 17:40:38.350 - debug /debug debugfs rw,relatime 0 0
2018-10-20 17:40:38.367 - modfs: Free space
2018-10-20 17:40:38.387 - Filesystem                Size      Used Available Use% Mounted on
2018-10-20 17:40:38.387 - /dev/root                48.0M     22.5M     25.5M  47% /wrapper
2018-10-20 17:40:38.387 - devtmpfs                116.6M     68.0K    116.6M   0% /wrapper/dev
2018-10-20 17:40:38.387 - /dev/loop0               20.1M     20.1M         0 100% /
2018-10-20 17:40:38.387 - devtmpfs                116.6M     68.0K    116.6M   0% /dev
2018-10-20 17:40:38.387 - tmpfs                   116.8M     12.8M    104.0M  11% /var
2018-10-20 17:40:38.388 - /dev/mtdblock4            2.0M    876.0K      1.1M  43% /var/flash
2018-10-20 17:40:38.388 - /var/dev/nand           406.0M     28.7M    377.3M   7% /var/media/ftp
2018-10-20 17:40:38.406 - modfs: Swap space
2018-10-20 17:40:38.423 - Filename                              Type            Size    Used    Priority
2018-10-20 17:40:38.423 - /dev/sda1                               partition     2097148 0       -1
2018-10-20 17:40:38.440 - modfs: Loop devices
2018-10-20 17:40:38.489 - /dev/loop0: 0 /filesystem_core.squashfs
2018-10-20 17:40:38.516 - modfs: using temporary file list from /var/tmp/3870_filelist_1540050038
2018-10-20 17:40:38.535 - modfs: cleanup trap set
2018-10-20 17:40:38.553 - modfs: invoked with: update
2018-10-20 17:40:38.573 - modfs: noversioncheck=1, update_file_provided=0
2018-10-20 17:40:38.594 - check_prerequisites: starting checks
2018-10-20 17:40:38.642 - progress: mode=1, msg=Ermitteln der Hardware-Version ...
2018-10-20 17:40:38.669 - check_prerequisites: hwrev=185
2018-10-20 17:40:38.717 - progress: mode=3, msg= OK
2018-10-20 17:40:38.765 - progress: mode=1, msg=Prüfen, ob die Hardware-Version unterstützt wird ...
2018-10-20 17:40:38.785 - check_prerequisites: supported hardware revision
2018-10-20 17:40:38.834 - progress: mode=3, msg= OK
2018-10-20 17:40:38.882 - progress: mode=1, msg=Suchen der Einstellung zur Umschaltung auf das alternative System ...
2018-10-20 17:40:38.911 - check_prerequisites: system switch value is 0
2018-10-20 17:40:38.958 - progress: mode=3, msg= OK
2018-10-20 17:40:39.006 - progress: mode=1, msg=Prüfen der aktuell zu startenden Systemversion ...
2018-10-20 17:40:39.105 - progress: mode=3, msg= OK
2018-10-20 17:40:39.153 - progress: mode=1, msg=Suchen der aktuellen Kernel-Partition ...
2018-10-20 17:40:39.178 - check_prerequisites: kernel device is /dev/mtdblock0
2018-10-20 17:40:39.229 - progress: mode=3, msg= OK
2018-10-20 17:40:39.278 - progress: mode=1, msg=Suchen der alternativen Kernel-Partition ...
2018-10-20 17:40:39.304 - check_prerequisites: alternative kernel device is /dev/mtdblock2
2018-10-20 17:40:39.352 - progress: mode=3, msg= OK
2018-10-20 17:40:39.402 - progress: mode=1, msg=Vergleich der Systeme in den Kernel-Partitionen ...
2018-10-20 17:40:39.450 - progress: mode=3, msg= übersprungen
2018-10-20 17:40:39.498 - progress: mode=1, msg=Suchen der aktuellen Dateisystem-Partition ...
2018-10-20 17:40:39.523 - check_prerequisites: filesystem device is /dev/mtdblock1
2018-10-20 17:40:39.571 - progress: mode=3, msg= OK
2018-10-20 17:40:39.620 - progress: mode=1, msg=Suchen der alternativen Dateisystem-Partition ...
2018-10-20 17:40:39.645 - check_prerequisites: alternative filesystem device is /dev/mtdblock3
2018-10-20 17:40:39.693 - progress: mode=3, msg= OK
2018-10-20 17:40:39.742 - progress: mode=1, msg=Überprüfen des zur Verfügung stehenden Speicherplatzes im RAM ...
2018-10-20 17:40:39.766 - check_free_tmpfs: wanted=25165824, needed=10485760
2018-10-20 17:40:39.793 - check_free_tmpfs: exiting, rc=0
2018-10-20 17:40:39.842 - progress: mode=3, msg= OK
2018-10-20 17:40:39.891 - progress: mode=1, msg=Überprüfen des freien Speicherplatzes für das Auspacken des Dateisystems ...
2018-10-20 17:40:39.914 - find_free_storage_space: needed=140509184, accept=nonand
2018-10-20 17:40:39.947 - check_space: needed=140509184
2018-10-20 17:40:40.054 - get_possible_usb_mountpoints: count=0
2018-10-20 17:40:40.073 - check_space:
2018-10-20 17:40:40.093 - find_free_storage_space:
2018-10-20 17:40:40.110 - find_free_storage_space: exiting, rc=0
2018-10-20 17:40:40.159 - progress: mode=3, msg= OK
2018-10-20 17:40:40.177 - check_prerequisites: exiting, rc=0
2018-10-20 17:40:40.226 - check_swap_space: requested space=256 MB
2018-10-20 17:40:40.276 - progress: mode=3, msg= OK
2018-10-20 17:40:40.294 - check_swap_space: finished, rc=0, space available=2147479552
2018-10-20 17:40:40.385 - get_system_version: version="113.06.93", subversion="-48385", date="13.12.2017 11:59:12", rc=0
2018-10-20 17:40:40.462 - modfs: source=download_update
2018-10-20 17:40:40.489 - get_version_from_manufacturer: target=newer
2018-10-20 17:40:40.576 - get_system_version: version="113.06.93", subversion="-48385", date="13.12.2017 11:59:12", rc=0
2018-10-20 17:40:40.625 - progress: mode=1, msg=Ermitteln der neuesten Version durch Abfrage beim Hersteller ...
2018-10-20 17:40:41.959 - progress: mode=3, msg= OK
2018-10-20 17:40:42.014 - get_version_from_manufacturer: found new version 113.07.01, URL=http://download.avm.de/fritzbox/fritzbox-7490/deutschland/fritz.os/FRITZ.Box_7490.113                                                                                                                                              .07.01.image
2018-10-20 17:40:42.032 - get_version_from_manufacturer: exiting, rc=0
2018-10-20 17:40:42.054 - find_free_space: wanted=54M, order=tmpfs nonand storage
2018-10-20 17:40:42.079 - check_free_tmpfs: wanted=56623104, needed=56623104
2018-10-20 17:40:42.105 - check_free_tmpfs: exiting, rc=0
2018-10-20 17:40:42.123 - find_free_space: tmpfs=/var/tmp
2018-10-20 17:40:42.140 - find_free_space: exiting, rc=0
2018-10-20 17:40:42.159 - get_working_directory: /var/tmp
2018-10-20 17:40:42.178 - modfs: working directory=/var/tmp
2018-10-20 17:40:42.234 - progress: mode=1, msg=Download eines Firmware-Images für Version 113.07.01 vom Server des Herstellers ...
2018-10-20 17:40:42.260 - modfs: download directory=/var/tmp/1540050042
2018-10-20 17:40:42.278 - download_firmware: target=/var/tmp/1540050042/firmware.image, source=http://download.avm.de/fritzbox/fritzbox-7490/deutschland/fritz.os/FRITZ.Box_749                                                                                                                                              0.113.07.01.image
2018-10-20 17:40:48.101 - download_firmware: 33310720 bytes downloaded
2018-10-20 17:40:48.119 - download_firmware: exiting, rc=0
2018-10-20 17:40:48.166 - progress: mode=3, msg= OK
2018-10-20 17:40:48.184 - try_to_check_integrity: target=/var/tmp/1540050042/firmware.image
2018-10-20 17:40:48.233 - progress: mode=1, msg=Überprüfen der Signatur der geladenen Datei ...
2018-10-20 17:40:50.655 - progress: mode=3, msg= OK
2018-10-20 17:40:50.673 - try_to_check_integrity: integrity check passed
2018-10-20 17:40:50.692 - try_to_check_integrity: exiting, rc=0
2018-10-20 17:40:50.712 - find_free_space: wanted=100M, order=tmpfs nonand storage
2018-10-20 17:40:50.737 - check_free_tmpfs: wanted=104857600, needed=104857600
2018-10-20 17:40:50.763 - check_free_tmpfs: exiting, rc=2
2018-10-20 17:40:50.785 - find_free_storage_space: needed=104857600, accept=nonand
2018-10-20 17:40:50.819 - check_space: needed=104857600
2018-10-20 17:40:50.926 - get_possible_usb_mountpoints: count=0
2018-10-20 17:40:50.945 - check_space:
2018-10-20 17:40:50.965 - find_free_storage_space:
2018-10-20 17:40:50.983 - find_free_storage_space: exiting, rc=0
2018-10-20 17:40:51.001 - find_free_space: storage=
2018-10-20 17:40:51.019 - find_free_space: exiting, rc=0
2018-10-20 17:40:51.038 - get_working_directory:
2018-10-20 17:40:51.094 - progress: mode=1, msg=Extrahieren des neuen Kernel-Images aus dem Firmware-Image ...
2018-10-20 17:40:51.112 - extract_kernel: src=/var/tmp/1540050042/firmware.image, target=/1540050051/kernel.image
2018-10-20 17:40:51.130 - extract_kernel: exiting, rc=62
2018-10-20 17:40:51.177 - progress: mode=3, msg= Fehler
2018-10-20 17:40:51.226 - cleanup: running cleanup from file /var/tmp/3870_filelist_1540050038
2018-10-20 17:40:51.245 - /var/mod/bin/185/busybox rm -r /var/tmp/1540050042
2018-10-20 17:40:51.245 - /var/mod/bin/185/busybox rm -r /1540050051

Danke.

Gruß kami
 
get_possible_usb_mountpoints: count=0
Anzahl der USB-Volumes: 0

Der Platz im "tmpfs" reicht auch nicht für Download und gleichzeitig noch fürs Auspacken.

Wenn mal alles das nicht hat, muß man schon dafür sorgen, daß der NAND für das NAS benutzt werden soll, siehe https://www.ip-phone-forum.de/threads/modfs-squashfs-image-avm-firmware-ändern-für-nand-basierte-fritz-boxen.273304/page-74#post-2295395 und auch später habe ich noch deutlich darauf hingewiesen.

Wobei da nach den Änderungen zum NAND tatsächlich noch ein Problem im Skript besteht (und es somit nicht erkennt, wenn jemand die Eingangsvoraussetzungen nicht wirklich erfüllt), denn das hier:
Code:
2018-10-20 17:40:39.914 - find_free_storage_space: needed=140509184, accept=nonand
2018-10-20 17:40:39.947 - check_space: needed=140509184
2018-10-20 17:40:40.054 - get_possible_usb_mountpoints: count=0
2018-10-20 17:40:40.073 - check_space:
2018-10-20 17:40:40.093 - find_free_storage_space:
2018-10-20 17:40:40.110 - find_free_storage_space: exiting, rc=0
soll tatsächlich zu einem Fehler und nicht zu "rc=0" führen. Wobei das eben nur die (inzwischen) nicht mehr korrekte Auswertung des Fehlers ist ... die eigentliche Ursache liegt in falschen Voraussetzungen (die das Skript aber erkennen sollte, wenn alles korrekt läuft).

Die falsche Prüfung der Voraussetzungen ändere ich zwar in der Beta, das reicht mir aber nicht für eine neue Version ... weil man es einfach durch den richtigen Aufruf auch dann "umgehen" kann, wenn man tatsächlich kein passendes USB-Volume zur Verfügung stellen will. Überlegt man sich das anders, habe ich erst vor kurzem hier: https://www.ip-phone-forum.de/threads/modfs-squashfs-image-avm-firmware-ändern-für-nand-basierte-fritz-boxen.273304/page-79#post-2299599 in aller Ausführlichkeit beschrieben, wie man sich den passenden USB-Speicher erstellen kann - auch dann, wenn man nur eine FRITZ!Box als Linux-Host zur Verfügung hat.

Ich werfe ohnehin gerade das "check_update" in "modfs" noch raus, weil es einfach das "juis_check" aus dem YourFritz-Repo verwenden kann - das war "historisch", daß es da zwei Versionen gab und bisher war ich nur zu faul, dem "juis_check" noch die anderen Kunststückchen (lokales Lesen der Daten, automatisches Finden einer URL für den Download von AVM auch für die aktuell installierte Version) beizubringen. Das neue "punt!" bei der Signal-Behandlung im "nc"-Applet der BusyBox hat mich wieder daran erinnert, daß es da zwei Versionen des Update-Checks gab und auch das Prüfen der Signatur war noch die alte Version, die mit OpenSSL 1.1.0 nicht klarkommen würde.

EDIT:
Neue Beta, die jetzt die Skripte aus dem YourFritz-Repo für die Signaturprüfung und die JUIS-Abfrage verwendet, ist online.
 
Zuletzt bearbeitet:
Hallo,

nach der richtigen Erstellung des USB Sticks, hat alles super geklappt ohne Probleme.

Danke Gruß kami
 
Hallo!

Weil das Ausführen meiner Änderungen in rc.user nicht mehr richtig klappt (wie noch zur Version 6.90) wollte ich versuchen, das System erneut über modfs zu flashen (in der Hoffnung, dass sich seitdem etwas verändert hat). Leider bekomme ich nun folgende Ausgabe (mit der Version 0.5.1-beta):

Code:
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 :

Packen des neuen root-Dateisystems ... Fehler
The specified message number 1 was not found at the language file for 'de'.

Die komplette Ausgabe von showshringbuf modfs als Anhang.

Weiß jemand woran das liegt und was mache ich falsch?

Danke Euch und viele Grüße
kmeleon
 

Anhänge

  • modfs_output.txt
    67.3 KB · Aufrufe: 6
Zuletzt bearbeitet:
Hmm ... das sind gut 5 Minuten, in denen das "mksquashfs" schon mal arbeitet. Am Aufruf liegt's also wohl nicht ... mehr sieht man aber in dem Schnipsel auch nicht und der ganze andere Teil (in dem u.a. die Infos zum freien Platz und zu den verwendeten Verzeichnissen stehen) fehlt ja ganz offensichtlich. Es ist schon komisch, daß hier das "tmpfs" für das entpackte Dateisystem benutzt wurde und nicht eines auf einem USB-Volume - da wäre ich schon das erste Mal skeptisch, ob die "Eingangsvoraussetzungen" vorliegen. Da ich aber das Abschalten der NAND-Benutzung erst "frisch" in der Version habe, will ich nicht ausschließen, daß da bei der vorbereitenden Prüfung auf genug freien Speicherplatz (sowohl im Dateisystem als auch im Hauptspeicher) noch etwas schiefgehen kann und das Skript trotz fehlender Voraussetzungen seine Arbeit beginnt.

Also: Bitte schon das ganze Protokoll - das oben nutzt mal genau gar nichts, weil die einzige Feststellung dort drin wäre: Nach 5 Minuten bricht das Packen ab. Auch wenn das mit den fünf Minuten schon mal besser ist zu wissen, als wenn das auch fehlen würde ... damit fällt der falsche Aufruf des "mksquashfs" schon mal weg.
 

Statistik des Forums

Themen
246,347
Beiträge
2,250,587
Mitglieder
374,001
Neuestes Mitglied
curious2315
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.