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

[PeterPawn]

Wenn "env" nichts ausgibt, ist vielleicht auch nur das Environment komplett leer.

Bei leerem Environment gibt es auch keinen Suchpfad (PATH) und damit kann das "blkid" nicht gefunden werden. Bleibt die Frage, warum das Environment leer ist ... baue ich die drei Zeilen in die Datei ein (am Anfang bei mir, aber das ist nicht entscheidend), sieht das so aus:

[COLOR="#FF0000"]+ env[/COLOR]
GATEWAY_INTERFACE=CGI/1.1
CONTENT_TYPE=application/x-www-form-urlencoded
CONFIG_FON_HD=y
CONFIG_TIMERCONTROL=y
[...]

Und das ist es auch, was ich in der Datei in #957 vermisse ... selbst wenn das Environment leer wäre, sollte zumindest die Zeile mit dem Aufruf von "env" sichtbar sein im Trace. Daher gehe ich davon aus, daß Du vielleicht die falsche Datei geändert hast oder irgendetwas in der Richtung - Deinem eigenen Protokoll nach wird jedenfalls kein "env" aufgerufen, damit war da auch kein Unterschied zu sehen. Damit bin ich nicht einmal sicher, daß das Environment wirklich leer ist - das ist nur eine mögliche Erklärung der fehlenden Ausgaben, aber eigentlich nicht für die fehlende rote Zeile.

Theoretisch wäre Abhilfe sogar leicht möglich (man muß nur PATH richtig setzen, notfalls im Skript), aber das kann eigentlich auch nicht die Lösung sein - irgendwo muß das Environment ja abgeblieben sein (wenn es tatsächlich leer ist) bzw. irgendjemand hat da vergessen, die "Vererbungen" richtig umzusetzen (oder es absichtlich unterlassen).

Hier widerstrebt mir ein simpler Workaround - das Erkennen der Ursache des Problems wäre viel entscheidender (und die definitive Klärung, was im Environment wirklich steht). Hier funktionieren ja andere Sachen dann auch nicht - sogar die Puma6-Erkennung von AVM scheitert und nur durch die Art des Aufrufs ("is_puma6" ist dann trotzdem "false", wenn "CONFIG_PRODUKT" nicht gesetzt ist) macht sich das nicht als weiterer Fehler auf einer 7490 bemerkbar.

 

[Micha0815]

Im Log steht unter dem env schon etwas? Sorry, dass ich die nicht angehängt hatte, hatte nur auf die blkid-Stelle geachtet.
LG

 

[PeterPawn]

Da steht ja nun

PATH=/bin:/usr/bin

im Environment, damit fehlen beide "sbin"-Verzeichnisse - es sieht fast so aus, als wenn der "ctlmgr" als Webserver da das Environment für den Aufruf von "luacgi" bereinigt, denn er selbst hat die Verzeichnisse noch drin:

 $ for v in $(sed -ne p /proc/$(pidof ctlmgr)/environ); do echo $v; done | grep ^PATH=
PATH=/bin:/usr/bin:/sbin:/usr/sbin

Wenn ich bei mir nach dem Pfad suche, steht da tatsächlich auch nur "/bin:/usr/bin" beim CGI-Aufruf und es funktioniert bei mir dann wirklich durch die ersetzte BusyBox, denn die findet das "blkid" auch direkt als Applet.

Damit wären wir dann doch wieder bei dem Problem, daß es verschiedene "blkid"-Versionen in verschiedenen Verzeichnissen mit verschiedenen Ausgaben geben könnte - das Einfachste wäre es jetzt, den Aufruf von blkid mit absolutem Pfad auszuführen. Genau das wollte ich aber mit der Suche über "command -v" verhindern, am Ende muß man vermutlich sowohl in "/sbin" als auch in "/usr/sbin" auf die Suche gehen, auch wenn bei AVM beides identisch ist. Das muß bei einem Freetz-Image oder einem selbstgebauten auch nicht zwingend so sein ... das macht es nicht gerade leichter.

Im Moment tendiere ich sogar dazu, einfach im "modscript" noch den Link "/bin/blkid" auf irgendein per "find" lokalisiertes "blkid"-Kommando zu setzen - oder ich müßte eben doch die "üblichen Verdächtigen" an Verzeichnissen durchsuchen lassen. Insgesamt ist das alles wenig erbaulich ... auch wenn ich es sehr interessant finde, daß da beim CGI-Aufruf nur noch "/bin" und "/usr/bin" im PATH stehen. Das ist als Security-Maßnahme (clean environment) ja sogar sehr sinnvoll für einen Webserver - damit werden keine Kommandos, die eigentlich dem "superuser" vorbehalten sein sollten, gefunden bei einer Suche.

Aber durch die Angabe eines absoluten Pfades kommt man da natürlich trotzdem noch heran, weil der User-Kontext ja weiterhin "root" ist und die notwendigen Rechte für die Verzeichnisse hat - das macht es etwas wieder weniger spektakulär/bemerkenswert/sicher, selbst wenn dann ggf. noch das Problem der "injection" von Schrägstrichen dazukommt für einen Angreifer.

Egal, ich füge jetzt einfach das (lokale) Setzen eines eigenen Pfades in der Funktion zum Mounten hinzu und dann sollte das erst einmal laufen ... ist inzwischen auch geändert, aber ohne eigenen Test meinerseits (so kompliziert sollte das Setzen einer Variablen nicht sein).

Das war dann bisher auch wirklich ein "generelles Problem", welches nur die Leute nicht haben, die (wie hier auch irgendwo gezeigt auf den vorhergehenden 48 Seiten) auch gleich noch die BusyBox von AVM durch die erweiterte Version aus dem "modfs"-Paket austauschen lassen - dort wird dann durch "PREFER_APPLETS" der Suchpfad erst dann wichtig, wenn es kein passendes Applet gibt. Das war genau der eine Fall (hatte ich oben auch geschrieben), den ich nicht mehr getestet habe ... manchmal kann man in der Theorie gar nicht verquast genug denken und dabei bin ich mir der Tatsache, daß die AVM-BusyBox immer wieder Probleme bereiten kann, durchaus bewußt und versuche sie zumindest auszuschließen. Hier ergab ja auch jeder einzelne Test das erwartete Ergebnis - erst in der Gesamtheit mit dem Aufruf über das CGI mit dem beschränkten PATH und mit der BusyBox ohne "PREFER_APPLETS" (was eigentlich sogar einen Geschwindigkeitsgewinn bringen sollte, wenn man es eingeschaltet hat beim Build) kommt es am Ende zu dem geschilderten Fehler.

 

[Micha0815]

Danke für Geduld

und die Änderung. Nun klappt es.
Dass die busybox nun wiederholt Ärger macht, werde ich mich mal daran begeben, diese mit-zu-tauschen. Andererseits ist es ja nicht verkehrt, wenn jemandem aus dem "Beginners-Kreis" eventuelle Probleme ihm dabei nicht gleich auf die Füsse fallen?

LG und lieben Dank

 

[Pokemon20021]

Dass die busybox nun wiederholt Ärger macht, werde ich mich mal daran begeben, diese mit-zu-tauschen.

Oh, das klingt irgendwie mutig oder sportlich;
Bitte keine Experimente wie "Busybox Tausch";
ich empfehle für Anwender aus dem "Beginnerkreis" die Out-of-Box modfs Variante ;-)

 

[Micha0815]

Trotz Stundenlangen Lesens und wie man die busybox tauschen könnte wie hier angekündigt und wohl auch unter .../modfs/VR9/*.* nach einem wget auf der FB7490 verfügbar scheint, fehlt mir der Ansatz -genauer der Durchblick- wie man das angehen könnte?

Unter https://github.com/PeterPawn/modfs/tree/master/modscripts erkenne ich kein "mod_change_busybox" oder ähnliches. Ob man dies nun über die rcuser-schiene, TFFS-Node98, oder Custom*.* realisieren kann, dass mit "eingepackt" werden muss oder bei einem restart mit eingebunden werden muss? Es übersteigt leider meinen Wissenshorizont. (Nach 6h Lesens raucht das Spatzenhirn schon etwas )

Verstanden habe ich so grob, dass der Austausch oder ein permanenter Sym-Link bzw. Verwendung ein gewisses Risiko insich birgt, wobei bisher eigentlich keine Negativ-Effekte (sofern ich im Forum hier nicht Wichtiges übersehen habe) bekannt sind versus der AVM-Eigenen? Im Gegenteil. Der Austausch würde doch manches Problem elegant umshippern?

Sollte ich in PeterPawns-Github an anderer Stelle (tools o.ä) etwas übersehen haben, bitte ich um Entschuldigung.

Über einen freundlichen "Schubser" in die richtige Richtung als "Happen vor die Füsse geworfen" bedanke ich mich schon im Voraus.

LG+TX

- - - Aktualisiert - - -

Sorry den Beitrag im Preview überlesen!

Oh, das klingt irgendwie mutig oder sportlich;
Bitte keine Experimente wie "Busybox Tausch";

No Risk No Fun

...ich empfehle für Anwender aus dem "Beginnerkreis" die Out-of-Box modfs Variante ;-)

OK wohl etwas zu drastisch formuliert

 

[PeterPawn]

@Micha0815:

http://www.ip-phone-forum.de/showthread.php?t=273304&p=2155613&viewfull=1#post2155613

 

[Micha0815]

Fettes DANKE! Obschon ich mir sicher bin ab ~page=23 alles bis 49 durchgelesen zu haben, ist mir das wohl wegen zuvielen offenen Tabs (Querverweise) durchgeflutscht.
TX:wow:

- - - Aktualisiert - - -

Wäre ja auch zu simple gewesen ... :blonk:

Verzeichnis des root-Dateisystems : /var/media/ftp/1478636429/squashfs-root

Das Skript 'mod_change_busybox' hat einen falschen Aufbau, es fehlt der MODFS_MODSCRIPT-Header.

Die Modifikation 'mod_change_busybox' wurde angewendet, Fehlercode = 61.

Ergo Weiterlesen, Lernen und Verstehen ...

 

[PeterPawn]

Keine Ahnung, was Du da gemacht hast ... ich habe nur die Zeilen aus der Code-Box in eine Datei kopiert und erhalte dann folgendes:

Die Modifikation 'replace Busybox' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... fallback to english
Soll die Modifikation 'replace Busybox' mit folgender Beschreibung
replace busybox with statically linked version from modfs
angewendet werden? (j/N) j
Überprüfen der Voraussetzungen für die Modifikation ... nicht unterstützt
Modifikation wird ausgeführt ... OK
Überprüfen des Erfolgs der Modifikation ... nicht unterstützt

Die Modifikation 'replace Busybox' wurde angewendet, Fehlercode = 0.

Entweder ein Fehler beim Abschreiben (C&P verwenden, notfalls per SSH und nicht per SIAB) oder Du wolltest Dir die Übernahme von Kommentarzeilen sparen oder oder oder ...

 

[Micha0815]

Hmm? Ich habe das als "mod_change_busybox" mit

# MODFS_MODSCRIPT
# SUPPORTS install
# NAME replace Busybox
# DESCRIPTION en
# replace busybox with statically linked version from modfs
# EOH
[ $4 == install ] && cp -a bin/VR9/busybox $2/bin/busybox

mit notepad+ abgespeichert, und via Totalcommander in das modscript-Verzeichnis kopiert und Dateirechte 777 verpasst, da ich wo las hier, das "world" abgearbeitet wird, was es wohl auch versucht. Ob da noch statements $1-x hineingehören oder rc? ... K.A. Imho sollte -sofern ich das als Beginner halbwegs verstanden habe- alles via modfs-main-script unter /modscripts aufgeführt- abgearbeitet werden?
Danke und nun bin ich schon etwas zu müde ... zumindest lief das script auch mit der 41942 durch als kleines/gegönntes (Bett-Hupfrl) Erfolgserlebnis

- - - Aktualisiert - - -

Mühsam ernährt sich das (Beginners-)Eichhörnchen?
Mit ein paar Tricks hat es schlussendlich doch geklappt!

 ~ # busybox
BusyBox v1.24.2 (2016-09-24 17:17:47 CEST) multi-call binary.
BusyBox is copyrighted by many authors between 1998-2015.
Licensed under GPLv2. See source distribution for detailed
copyright notices....

Das Grundproblem -hier als Beginner- in das modscripts Verzeichnis per Totalcommander (ftp-client) ein eigenes script zu kopieren. Statt root root ist der Besitzer -hier mal ein Bsp.-

/var/media/ftp/modfs8 # ls -la
drwxrwxrwx    1 root     root          2048 Nov  9 21:53 .
drwxrwxr-x    1 root     root          2048 Nov  9 22:13 ..
-rwxrwxrwx    1 boxusr11 root      27023360 Nov  9 14:03 41875.image
-rw-rw-rw-    1 boxusr11 root      27238400 Nov  8 22:17 41942.image
-r--r--r--    1 root     root         10745 Apr 26  2016 BOOTSELECTION.ger
-r--r--r--    1 root     root         18092 Feb 13  2016 LICENSE
-r--r--r--    1 root     root         28257 Feb 13  2016 README.ger.outdated
-r--r--r--    1 root     root         17964 Feb 13  2016 README.outdated
drwxr-xr-x    1 root     root          2048 Nov  8 22:15 bin
drwxr-xr-x    1 root     root          2048 Nov  8 22:15 files
drwxr-xr-x    1 root     root          2048 Nov  8 22:15 locale
-rwxr-xr-x    1 root     root         99109 Nov  8 12:19 modfs
drwxrwxrwx    1 root     root          2048 Nov  9 21:14 modscripts

boxusr11 was das Main-modfs-script wohl garnicht mag! Nach stundenlangem Probieren/Basics-Recherche mit "chown" und "cp" dachte ich mir, weshalb nicht einfach ein bestehendes script abändern, was ich eh im modfs-skript "verneine/abwähle"? BINGO mod_night auserkoren, temporär 777 als Dateirechte verpasst, per Notepad+ editiert und zurückgespielt

   # MODFS_MODSCRIPT
# SUPPORTS precheck postcheck install language(en,de)
# NAME add night time control to system menu
# DESCRIPTION en
# add a menu entry for night time control page          
# DESCRIPTION de
# Eintrag im System-Bereich zur Reaktivierung der Steuerung der Nachtschaltung
# EOH
#
# process parameters
#
language=$1
rootdir=$2
mode=$3
step=$4
[ $4 == install ] && cp -a bin/VR9/busybox $2/bin/busybox
rc=0

und im Anschluss wieder wie den übrigen scripts unter /modscripts 554 als Dateirechte verpasst.

Im Anschluss lief das main-modfs-script anstandlos durch.

Ich schreibe dies nur mal so auf für die "Beginners-Leserschaft", auch wenn PeterPawn und sonstige Experten dabei die Nase rümpfen. Es gäbe auch andere Möglichkeiten über bind-Befehle (von u.a.Koy hier mal erwähnt) wovon abgeraten wurde.

LG und sollte sich PeterPawn oder sonst wer daran stören, lösche ich es wieder.

 

[PeterPawn]

sollte sich PeterPawn oder sonst wer daran stören, lösche ich es wieder.

Warum sollte ich mich daran stören (wenn es inhaltlich stimmt, ich habe irgendwo den Faden verloren)?

Ich verstehe nur nicht so richtig, wieso Du davon ausgehst, das würde dann irgendein "beginner" hier auch noch finden ... solange er den Thread nicht sequentiell liest (und das macht wohl wirklich niemand). Wenn ich schreibe, daß ich irgendetwas irgendwo geschrieben habe und der Fragesteller möge danach suchen, dann würde da die Suche nach "modfs PeterPawn stichwort1 stichwort2 ..." naheliegen. Für die gezielte Suche nach #971 fehlt mir tatsächlich die Phantasie, was da zum Erfolg führen sollte. Warum geht denn niemand (der sich zu diesen "beginners" zählt und seine Erfahrungen - auch zu Klippen - teilen will) hin und nimmt den "Einsteiger-Thread" von @eisbaerin wieder auf? Da kann man dann ja durchaus die wichtigsten Erfahrungen und kleine Tipps oder was auch immer so aufschreiben, daß ein "Neuling" die auch finden kann. Wenn ich (bei den meisten Fragen jedenfalls) immer wieder auf #1 verweise, ist das ja auch der Tatsache geschuldet, daß ich da immer wieder Updates vornehme, wenn sich etwas entscheidendes ändert und daß dort auch Links auf Beiträge in diesem Thread zusammengetragen sind.

Ansonsten ist die Syntax von "chmod" und "chown" ja tatsächlich sehr einfach, so daß man da auch nichts "hineingeheimnissen" muß. Die FRITZ!Box verwendet beim FTP-Zugriff interne Benutzernamen und die sind einfach nicht "root" (das ist auch gut so, wobei das nur ein schwacher Schutz der Daten ist).

Warum der Besitzer von "modfs" und darunterliegenden Dateien (oder einer Image-Datei) nun unbedingt "root" sein muß, ist mir zwar nicht geläufig (und klingt auch irgendwie unwahrscheinlich, aber das müssen wir jetzt nicht aufdröseln), aber das ist ein einzelnes Kommando vor dem Aufruf von "modfs" (und der kann ja kaum über den TotalCommander erfolgen).

Ansonsten kann man die Zugriffrechte für eine Datei (solange sie einem noch gehört) auch per FTP-Zugriff ändern (die Rechte müssen dabei aber "numerisch" angegeben werden im resultierenden FTP-Kommando), die FRITZ!Box setzt sogar die "execute"-Flags korrekt (ein USB-Volume ist inzwischen ohnehin mit "noexec" gemountet). Das sollte auch der TotalCommander können und daher kann ich die Schwierigkeiten beim Erstellen des eigenen Skripts tatsächlich nicht so richtig nachvollziehen (auch ohne daß ich dabei die Nase rümpfe) und erst recht keine stundenlange Beschäftigung mit dem Problem.

 

[Pokemon20021]

mod_replace_busybox

# MODFS_MODSCRIPT
# SUPPORTS precheck postcheck install language(en,de)
# NAME [COLOR=#ff0000]add night time control to system menu[/COLOR]
# DESCRIPTION en
# [COLOR=#ff0000]add a menu entry for night time control page[/COLOR]          
# DESCRIPTION de
# [COLOR=#ff0000]Eintrag im System-Bereich zur Reaktivierung der Steuerung der Nachtschaltung[/COLOR]
# EOH
#
# process parameters
#
language=$1
rootdir=$2
mode=$3
step=$4
[ $4 == install ] && cp -a bin/VR9/busybox $2/bin/busybox
rc=0

Hallo Micha0815,
ich denke da hast Du den falschen Header "kopiert":

Besser wäre:

cat mod_replace_busybox
# MODFS_MODSCRIPT
# SUPPORTS precheck postcheck install language(en,de)
# NAME [COLOR=#0000ff]replace Busybox[/COLOR]
# DESCRIPTION en
# [COLOR=#0000ff]replace busybox with statically linked version from modfs[/COLOR]
# EOH
#
# process parameters
#
language=$1
rootdir=$2
mode=$3
step=$4
#
[ ${#4} -eq 0 ] && exit 59 # invalid call
#
rc=0
[ $4 == install ] && cp -p bin/VR9/busybox $2/bin/busybox
rc=$?
exit $rc

dann passen wenigstens die Dialog-Meldungen bei Ausführung des modscripts
siehe auch #970

Pokemon20021

 

[Micha0815]

Danke

@Pokemon200021

Ich hatte mich nach Studiums Owner und Dateirechte über

 # MODFS_MODSCRIPT
# SUPPORTS precheck postcheck install language(en,de)
# NAME replace busybox
# DESCRIPTION en
# change busybox          
# DESCRIPTION de
# tausche busybox
# EOH
#
# process parameters
#
language=$1
rootdir=$2
mode=$3
step=$4
[ $4 == install ] && cp -a bin/VR9/busybox $2/bin/busybox
rc=0

der Lösung als Beginner angenähert.

LG
P.S.+OT: Schade eigentlich, dass es zumindest hier im Forum so garkeinen Thread rund um rcedit und custom gibt, der Beginners mal einen anschaulichen Anwendungs-Ausblick gibt, was im Gegensatz zu freetz mit ein paar "Vorlagen als Script" so möglich wäre. Es liegt mir absolut fern hier mangels Kenntnissen herumzulamern und werde zukünftig nur bei echten Problemen etwas posten.

 

[Pokemon20021]

keinen Thread rund um rcedit und custom gibt, der Beginners mal einen anschaulichen Anwendungs-Ausblick gibt, was im Gegensatz zu freetz mit ein paar "Vorlagen als Script" so möglich wäre.

ich denke mit "rcedit" meinst Du das Modscript "./modscripts/edit_rcuser" und die "debug.cfg", aka "rc.user";
das ist jedoch schon unzählige male im IPPF diskutiert worden,
siehe auch modfs Gebrauchsanleitung von eisbaerin: http://www.ip-phone-forum.de/showthread.php?t=284778&p=2153621&viewfull=1#post2153621

aber was meinst Du mit "custom" ?
evtl. die Datei "./custom_modscripts" ?

oder das Modscript "./modscripts/mod_custom_images"

cat ./modscripts/mod_custom_images
# MODFS_MODSCRIPT
# SUPPORTS precheck postcheck install language(en,de)
# NAME customize the original firmware with extension packages
# DESCRIPTION en
# search the system for custom images and initialize the contained services
# DESCRIPTION de
# Einbinden eigener Erweiterungspakete auf der Basis von Dateisystem-Images,
# die beim Start gesucht und eingehangen werden, bevor dort hinterlegte
# Start-Skripte aufgerufen werden
# EOH
#
SNIP

hier wird IMHO nach einer Datei "files/E99-custom" z.B. zum Start eigener Daemons in den RunLevel-Control-Bereich der Fritzbox eingebettet.
ich denke hier könntest Du "dropbear" usw. starten.
sieht irgendwie nicht nach "rocket science" aus.

Wie sieht den der konkreten Use-Case aus ?

 

[Shirocco88]

Problem bei Versions-Ermittlung von FB7490_LabBETA.113.06.69-42111

Hallo modfs-Anwender und -Entwickler,
Beim Update von FB7490 FW 06.69-42073 nach FB7490_LabBETA.113.06.69-42111
mittels modfs-0.4.1-081120161219 ist Problem im Skript bin/scripts/check_update aufgetreten:

# ./modfs update
respawn script with custom BusyBox shell, SHLVL=4
/var/media/ftp/modfs-0.4.1-081120161219/bin/185/busybox sh ./modfs update
Using debug mode with a 64 KB buffer
Ermitteln 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

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

Im Moment läuft auf der Box die Version: 113.06.69-42073

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

Ermitteln der neuesten Version durch Abfrage beim Hersteller ..../modfs: eval: line 1: BETA: not found
 OK
Es wurde eine neuere Version () gefunden.
[COLOR=#ff0000]./modfs: eval: line 1: BETA: not found[/COLOR]
Download eines Firmware-Images für Version  vom Server des Herstellers ... OK

so wie es aussieht, liegt ein Problem im Skript bin/scripts/check_update bei Versions-Ermittlung vor;
der AVM-Server liefert bei XML-Feld version einen String, der von check_update nicht als validen Version-String an das übergeordnete Skript modfs übergeben wird.

# /var/media/ftp/modfs-0.4.1-081120161219/bin/185/busybox sh /var/media/ftp/modfs-0.4.1-081120161219/bin/scripts/wrap_script /var/media/ftp/modfs-0.4.1-081120161219/bin/scripts/check_update -d
SNIP 
<ns3:Name>_EXTERN C16-Labor</ns3:Name>
<ns3:Version>[COLOR=#ff0000]113.06.69-42111 BETA[/COLOR]</ns3:Version>

# cat bin/scripts/check_update
SNIP
[COLOR=#ff0000]"Version="$(extract_xml "$xmlresp" "ns3" "Version")"[/COLOR]

evtl. läßt sich das Problem fixen.

LG Shirocco88

 

[Master SaMMy]

06.69-42113 INTERN habe ich drauf und da lief das modfs script durch
das aktuell laufende System
Version 113.06.69-42113 vom 18.11.2016 13:59:47 (linux_fs_start=0), das System wurde am 18.11.16 19:47 zuletzt modifiziert

das derzeit inaktive System
Version 113.06.69-41498 vom 06.10.2016 20:18:50 (linux_fs_start=1), das System wurde am 09.11.16 07:39 zuletzt modifiziert

 

[Shirocco88]

06.69-42113 INTERN habe ich drauf und da lief das modfs script durch

wenn Du mit "lief durch" meinst, dass das Skript nicht abgebrochen ist und die FW konnte geflashed werden, dann gebe ich Dir Recht;
jedoch kommt in der ersten Hälfte der Abarbeitung diese Meldung im Zusammenhang mit Versions-Ermittlung;
ich habe es 3 x getestet; da hilft auch nicht "wegsehen";
ist auch mit "check_update -d" zu reproduzieren.

wie gesagt, evtl. kann ein Entwickler etwas dazu sagen (Problem qualifizieren) oder fixen.

 

[Master SaMMy]

===================================
Variables set:
Serial="xxxxxxxxxxxx"
Major="113"
Minor="6"
Patch="69"
Build="42113"
Name="FRITZ!Box 7490"
HW="185"
OEM="avm"
Lang="de"
Annex="B"
Country="049"
Public=""
type="1001"
hostname="185.jws.avm.de"
nonce="TVKAPyjHwJbtVnE++RgSZQ=="

===================================
Sent request:
POST /Jason/UpdateInfoService HTTP/1.0
Host: 185.jws.avm.de:80
Content-Length: 959
Content-Type: text/xml; charset="utf-8"
Connection: close

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soap -enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/20 01/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:e="htt p://juis.avm.de/updateinfo" xmlns:q="http://juis.avm.de/request"><soap:Header/>< soap:Body><e:BoxFirmwareUpdateCheck><e:RequestHeader><q:Nonce>TVKAPyjHwJbtVnE++R gSZQ==</q:Nonce><q:UserAgent>Box</q:UserAgent><q:ManualRequest>true</q:ManualReq uest></e:RequestHeader><e:BoxInfo><q:Name>FRITZ!Box 7490</q:Name><q:HW>185</q:HW ><q:Major>113</q:Major><q:Minor>6</q:Minor><qatch>69</qatch><q:Buildnumber>4 2113</q:Buildnumber><q:Buildtype>1001</q:Buildtype><q:Serial>xxxxxxxxx</q:Ser ial><q:OEM>avm</q:OEM><q:Lang>de</q:Lang><q:Country>049</q:Country><q:Annex>B</q :Annex><q:Flag></q:Flag><q:UpdateConfig>1</q:UpdateConfig><qrovider>oma_lan</q rovider></e:BoxInfo></e:BoxFirmwareUpdateCheck></soap:Body></soap:Envelope>


===================================
Received response:
HTTP/1.1 200 OK
Server: nginx
Content-Type: text/xml;charset=UTF-8
Content-Length: 1949
Connection: close
Date: Fri, 18 Nov 2016 22:57:02 GMT

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><SOAP-ENV: Header xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"></SOAP-ENV:Hea der><soap:Body ID="Body"><ns2:BoxFirmwareUpdateCheckResponse xmlns:ns2="http://j uis.avm.de/updateinfo" xmlns:ns3="http://juis.avm.de/response" xmlns:ns4="http:/ /juis.avm.de/request"><ns2:ResponseUpdateInfo><ns3:ResponseHeader><ns3:Nonce>TVK APyjHwJbtVnE++RgSZQ==</ns3:Nonce></ns3:ResponseHeader><ns3:UpdateInfo><ns3:Check Interval>24</ns3:CheckInterval><ns3:Found>false</ns3:Found><ns3:Version></ns3:Ve rsion><ns3ownloadURL></ns3ownloadURL><ns3:InfoURL></ns3:InfoURL><ns3:InfoTex t></ns3:InfoText><ns3:HintURL></ns3:HintURL><ns3riority>1</ns3riority><ns3:A utoUpdateStartTime>0</ns3:AutoUpdateStartTime><ns3:AutoUpdateEndTime>0</ns3:Auto UpdateEndTime><ns3:AutoUpdateKeepServices>true</ns3:AutoUpdateKeepServices></ns3 :UpdateInfo></ns2:ResponseUpdateInfo></ns2:BoxFirmwareUpdateCheckResponse><Signa ture xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMet hod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></CanonicalizationMethod ><SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"> </SignatureMethod><Reference URI="#Body"><Transforms><Transform Algorithm="http: //www.w3.org/2000/09/xmldsig#enveloped-signature"></Transform></Transforms><Dige stMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></DigestMethod><Dig estValue>OrF9iFMnZexFXU9kmDCkeoh8WcNJqkwdhu0RYF3ZUyE=</DigestValue></Reference>< /SignedInfo><SignatureValue>Zw7o7M12XKzIPG4/jHlJd2C6Qt/03nB5iE/l3ogVPLFgfcY0ygVP JBQ3o7TsEfV9YkIRWppY5U1c5rZYtDaiCZsGD6PUuf78Zna4qtNZy4yWdYTF9mGowYH39za4hCLz8Ab+ EdOthBYeH1m00BBTZZ6cNv/TOxvAhWm+rAtimnwE8nwpUnozg19nMIkP0hEfs02OdUxj7pExrstq7n6b YgNfbllG0rxS1aKeEltu85FZrM/v8S+WCtERvBtiL3GiYG5DSUdUUyV+YoKz25+nZYB6b1yB4L35WNs6 re4V/psIKloKggObcTjR02+PFjCn8zvAMbOLAnpSnLYgbehjTg==</SignatureValue></Signature ></soap:Body></soap:Envelope>
======= end of debug output =======
root@fritz:/var/mod/root/modfs/bin/scripts#

die fw ist ja beta

 

[Shirocco88]

den Befehl "check_update -d" mußt Du natürlich von System mit Vorgänger Labor-Firmware, z.B. 113.06.69-41498 absetzen,
damit im Received response Abschnitt "<ns3:Found>true</ns3:Found>" erscheint und Version "<ns3:Version>xxxxx</ns3:Version>" befüllt ist.

 

[Master SaMMy]

root@fritz:/var/mod/root/modfs# ./modfs update /var/media/ftp/USBDISK2-0-02/7490/FRITZ.Box_7490.113.06.69-42113.image
ln: /var/run/modfs/sh: File exists
respawn script with custom BusyBox shell, SHLVL=2
/var/mod/root/modfs/bin/185/busybox sh ./modfs update /var/media/ftp/USBDISK2-0-02/7490/FRITZ.Box_7490.113.06.69-42113.image
Using debug mode with a 64 KB buffer
Ermitteln 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

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

Im Moment läuft auf der Box die Version: 113.06.69-42113

Die Angabe einer Datei nach dem 'update'-Parameter unterbindet jede Versionprüfung.
Somit ist jeder selbst dafür zuständig, die Kompatibilität der vorhandenen Einstellungen
mit dem verwendeten System sicherzustellen, speziell wenn ein Downgrade ausgeführt wurde
oder ggf. die 'Werkseinstellungen' wiederherzustellen.

Die angegebene Datei '/var/media/ftp/USBDISK2-0-02/7490/FRITZ.Box_7490.113.06.69-42113.image' wird als Quelle für die Aktualisierung genutzt.
Überprüfen der Signatur der geladenen Datei ... OK
Extrahieren des neuen Kernel-Images aus dem Firmware-Image ... OK
Extrahieren des Flash-Filesystems aus dem Firmware-Image ... OK
Extrahieren des Wurzeldateisystems aus dem Flash-Filesystem ... OK
Entpacken des root-Dateisystems für die Modifikationen ... OK

Das entpackte Dateisystem ist jetzt bereit für die Modifikationen.

Verzeichnis des root-Dateisystems : /var/media/ftp/1479510359/squashfs-root


Die Modifikation 'own files' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Soll die Modifikation 'own files' mit folgender Beschreibung
Programme hinzufügen/ersetzen
angewendet werden? (j/N) n

Die Modifikation 'create edit_rcuser command' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Soll die Modifikation 'create edit_rcuser command' mit folgender Beschreibung
Kommando zum Bearbeiten der Datei 'rc.user' hinzufügen
angewendet werden? (j/N) j
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
Überprüfen des Erfolgs der Modifikation ... OK

Die Modifikation 'create edit_rcuser command' wurde angewendet, Fehlercode = 0.

Die Modifikation 'enable system and branding selection from GUI (v0.3)' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Soll die Modifikation 'enable system and branding selection from GUI (v0.3)' mit folgender Beschreibung
Auswahl des zu startenden Systems und des Brandings in der "Neustart"-Seite
angewendet werden? (j/N) j
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
Überprüfen des Erfolgs der Modifikation ... OK

Die Modifikation 'enable system and branding selection from GUI (v0.3)' wurde angewendet, Fehlercode = 0.

Die Modifikation 'customize the original firmware with extension packages' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Soll die Modifikation 'customize the original firmware with extension packages' mit folgender Beschreibung
Einbinden eigener Erweiterungspakete auf der Basis von Dateisystem-Images,
die beim Start gesucht und eingehangen werden, bevor dort hinterlegte
Start-Skripte aufgerufen werden
angewendet werden? (j/N) j
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
Überprüfen des Erfolgs der Modifikation ... OK

Die Modifikation 'customize the original firmware with extension packages' wurde angewendet, Fehlercode = 0.

Die Modifikation 'unhide MAC by default' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Soll die Modifikation 'unhide MAC by default' mit folgender Beschreibung
Anzeige von Heimnetz-Clients mit MAC-Adresse als Standard
angewendet werden? (j/N) j
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
patching file usr/www/avm/net/net_overview.js
patching file usr/www/1und1/net/net_overview.js
Überprüfen des Erfolgs der Modifikation ... OK

Die Modifikation 'unhide MAC by default' wurde angewendet, Fehlercode = 0.

Die Modifikation 'enable telnet daemon' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Soll die Modifikation 'enable telnet daemon' mit folgender Beschreibung
Busybox-Symlink für den Telnet-Daemon erstellen
angewendet werden? (j/N) j
Überprüfen der Voraussetzungen für die Modifikation ... Fehler (1)
Die Modifikation wurde bereits angewendet oder ist nicht erforderlich.

Die Modifikation 'enable telnet daemon' wurde angewendet, Fehlercode = 1.

Die Modifikation 'add led display tab' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Soll die Modifikation 'add led display tab' mit folgender Beschreibung
Wiederbeleben der GUI-Seite zur Steuerung der LED-Anzeige
angewendet werden? (j/N) j
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
patching file usr/www/avm/menus/menu_data.lua
patching file usr/www/avm/menus/menu_data.lua
patching file usr/www/avm/system/led_display.lua
patching file usr/www/1und1/menus/menu_data.lua
patching file usr/www/1und1/menus/menu_data.lua
patching file usr/www/1und1/system/led_display.lua
Überprüfen des Erfolgs der Modifikation ... OK

Die Modifikation 'add led display tab' wurde angewendet, Fehlercode = 0.

Die Modifikation 'mount by label' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Soll die Modifikation 'mount by label' mit folgender Beschreibung
USB-Volumes mit ihrem Label als Mountpoint einbinden
angewendet werden? (j/N) j
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
Überprüfen des Erfolgs der Modifikation ... OK

Die Modifikation 'mount by label' wurde angewendet, Fehlercode = 0.

Die Modifikation 'add night time control to system menu' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Soll die Modifikation 'add night time control to system menu' mit folgender Beschreibung
Eintrag im System-Bereich zur Reaktivierung der Steuerung der Nachtschaltung
angewendet werden? (j/N) j
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
patching file usr/www/avm/menus/menu_data.lua
patching file usr/www/avm/menus/menu_data.lua
patching file usr/www/1und1/menus/menu_data.lua
patching file usr/www/1und1/menus/menu_data.lua
Überprüfen des Erfolgs der Modifikation ... OK

Die Modifikation 'add night time control to system menu' wurde angewendet, Fehlercode = 0.

Die Modifikation 'show phone number names' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Soll die Modifikation 'show phone number names' mit folgender Beschreibung
Anzeige des Namens einer eigenen Telefonnummer in der Anrufliste
angewendet werden? (j/N) j
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
patching file usr/lua/foncalls.lua
Überprüfen des Erfolgs der Modifikation ... OK

Die Modifikation 'show phone number names' wurde angewendet, Fehlercode = 0.

Die Modifikation 'enable custom profile extension' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Soll die Modifikation 'enable custom profile extension' mit folgender Beschreibung
Kommandos in /var/custom/etc/profile in /etc/profile einschließen
angewendet werden? (j/N) j
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
Überprüfen des Erfolgs der Modifikation ... OK

Die Modifikation 'enable custom profile extension' wurde angewendet, Fehlercode = 0.

Die Modifikation 'enable rc.user execution' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Soll die Modifikation 'enable rc.user execution' mit folgender Beschreibung
Kommandos aus dem TFFS-Node 98 beim Systemstart ausführen
angewendet werden? (j/N) j
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
Überprüfen des Erfolgs der Modifikation ... OK

Die Modifikation 'enable rc.user execution' wurde angewendet, Fehlercode = 0.

Die Modifikation 'show device name instead of type on GUI' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Soll die Modifikation 'show device name instead of type on GUI' mit folgender Beschreibung
Start mit der Anzeige des Gerätenamens anstelle des Typs in der Kopfzeile und im HTML-Titel;
dann nützlich, wenn man mehrere Boxen desselben Typs verwaltet und sofort sehen will, auf
welcher man gerade ist
angewendet werden? (j/N) j
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
patching file usr/www/avm/content.lua
patching file usr/www/avm/content.lua
patching file usr/www/avm/content.lua
patching file usr/www/1und1/content.lua
patching file usr/www/1und1/content.lua
patching file usr/www/1und1/content.lua
Überprüfen des Erfolgs der Modifikation ... OK

Die Modifikation 'show device name instead of type on GUI' wurde angewendet, Fehlercode = 0.

Die Modifikation 'add VPN summary on overview page' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Soll die Modifikation 'add VPN summary on overview page' mit folgender Beschreibung
Anzeige der VPN-Verbindungen auf der Startseite, inkl. Schnell-Link zur VPN-Konfiguration
angewendet werden? (j/N) j
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
patching file usr/www/avm/home/home.lua
patching file usr/www/avm/home/home.lua
patching file usr/www/avm/home/home.js
patching file usr/www/avm/home/home.js
patching file usr/www/avm/home/home.js
patching file usr/www/1und1/home/home.lua
patching file usr/www/1und1/home/home.lua
patching file usr/www/1und1/home/home.js
patching file usr/www/1und1/home/home.js
patching file usr/www/1und1/home/home.js
Überprüfen des Erfolgs der Modifikation ... OK

Die Modifikation 'add VPN summary on overview page' wurde angewendet, Fehlercode = 0.

Die Modifikation 'remove affected swap space before stopping USB devices' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Soll die Modifikation 'remove affected swap space before stopping USB devices' mit folgender Beschreibung
wird das USB-Subsystem gestoppt, während wichtige Teile des Hauptspeichers
in eine Swap-Partition (oder -Datei) ausgelagert sind, bleibt es u.U. beim
Neustart hängen - das wird hier versucht zu korrigieren
angewendet werden? (j/N)
Bitte 'j' oder 'n' auswählen und erneut eingeben ...
Soll die Modifikation 'remove affected swap space before stopping USB devices' mit folgender Beschreibung
wird das USB-Subsystem gestoppt, während wichtige Teile des Hauptspeichers
in eine Swap-Partition (oder -Datei) ausgelagert sind, bleibt es u.U. beim
Neustart hängen - das wird hier versucht zu korrigieren
angewendet werden? (j/N) j
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
patching file etc/hotplug/storage
patching file etc/hotplug/usb.pandu
Überprüfen des Erfolgs der Modifikation ... OK

Die Modifikation 'remove affected swap space before stopping USB devices' wurde angewendet, Fehlercode = 0.

Das ist die letzte Chance zum manuellen Modifizieren des Dateisystems in folgendem Verzeichnis: /var/media/ftp/1479510359/squashfs-root

Die Eingabetaste drücken, um mit dem Packen des neuen root-Dateisystems zu beginnen
oder 'q' eingeben, um die letzte Möglichkeit zum Abbruch zu nutzen :