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

[PeterPawn]

- Frage: Dass schon die "1er" aktiv ist bedeutet aber nicht, das in der "0" noch was drin ist, oder?

Was soll denn "noch was drin" sein? In der anderen Partition (bzw. im anderen Set, denn bei der 7490 sind das pro Wert (0 bzw. 1) für "linux_fs_start" immer zwei Partitionen, eine für den Kernel und eine für das Dateisystem) steht natürlich die zuvor benutzte OS-Version drin und die kann (vorausgesetzt, sie ist funktionsfähig) auch problemlos durch das Umstellen der erwähnten Variablen gestartet werden.

- Das man damit die Datei "environment" komplett überschreibt ist kein Problem? Es geht nichts wichtiges verloren, oder doch?

Das "environment" ist eben keine reguläre Datei ... da wird also auch nicht wirklich etwas überschrieben. Wenn Du den Mechanismus dahinter verstehen willst, solltest Du nach "pseudo filesystem" im Zusammenhang mit Linux suchen und lesen.

- Schaltet man auf eine Partition um, die noch leer ist, gibts dann Probleme bei z.B. einem voreiligen Reboot?

Die Auswertung der Variablen erfolgt beim Start der Box ... wenn also die Variable 1025x geändert wird, ohne daß zwischendrin ein Neustart erfolgt(e), ändert sich erst einmal gar nicht. Schaltet man immer zwischen den beiden möglichen Zuständen bei der 7490 hin und her, muß man sich halt nur merken, daß bei einer ungeraden Anzahl von Aufrufen die Umschaltung wirksam ist und bei einer geraden Anzahl dann eben nicht.

- In den Ausfuehrungen von Eisbaerin steht zu lesen, dass die (erste) Ausfuehrung nur geht, wenn in beiden Partitionen was drin ist. Wenn nicht, koenne man aber die aktive Partition in die leere Partition kopieren.

Das gilt nur für den (ursprünglich einzigen) "inkrementellen Modus" (was das ist, steht in #1) ... der braucht halt in beiden Partitionen dieselbe Version, weil aus der aktiven die neue Version erstellt wird und dabei zusätzliche Änderungen vorgenommen werden. Alle anderen Modi brauchen diese identischen Versionen nicht.

- Nach Abschluss dieses Schrittes sollte doch in beiden Partitionen ein exakt gleiches Image sein. Davon kann man auch booten, nach entsprechendem Umschalten der Partition.

Wie soll das mit dem "exakt gleichen Image" funktionieren? Das geht doch schon theoretisch nicht (gut, mit ein paar "Kunstgriffen" geht es doch, aber die sind nicht Gegenstand von "modfs") ... das eine Set enthält das laufende System und kann im laufenden Betrieb nicht ersetzt werden.

Wenn Du hier mit "Nach Abschluß dieses Schrittes" das automatische Angebot meinst, den Inhalt des laufenden Systems in die inaktiven Partitionen zu kopieren, so wäre das tatsächlich richtig und man kann dann auch zwischen zwei identischen Systemen umschalten. Mir fällt nur im Moment kein logischer Grund ein, warum man so eine Konfiguration haben wollte ... vielleicht als "Sicherheitskopie". Wobei das eigentlich auch Quatsch ist, denn bei einem wirklich zerstörten System kann man das über das Recovery-Programm ja jederzeit wiederherstellen.

Die Umschaltung kann man bei einem mittels "modfs" geänderten System auch direkt in der "Neustart"-Seite vornehmen.

Ansonsten schreibt "modfs" selbst gar nichts in irgendwelche Dateien (egal ob die "rc.user" oder "debug.cfg" genannt werden) ... die Modifikation zur Wiederbelebung der "debug.cfg/rc.user" trägt dort nur dann eine Zeile mit einer Nachricht für das Ereignisprotokoll ein, wenn diese Datei leer ist. Das ist auch nur zur Vermeidung zusätzlicher Verwirrung bei einigen Benutzern ... wenn man die Abarbeitung der Datei reaktiviert und diese ist leer, sind die Auswirkungen ja nicht sichtbar und es gab mehrere Benutzer, die sich dann wunderten und die Wirksamkeit der Änderung bezweifelten.

Steht aber bereits etwas in der "debug.cfg", bleibt sie im Rahmen von "modfs" ungeändert. Wobei natürlich in so einer Datei dann entsprechende Vorkehrungen getroffen werden müssen ... diese Datei gibt es ja nur einmal und sie würde (wenn sie in beiden Systemen reaktiviert wurde) in beiden System identisch ausgeführt; wobei die Änderung durch "modfs" das etwas anders startet und damit dem (unkundigen) Benutzer weniger Chancen läßt, den Boot-Prozess zu stören) - das heißt natürlich auch, daß die Kommandos in dieser Datei ggf. geänderte Pfade u.ä. berücksichtigen müssen.

Nun hatte vor, über das Freetz-GUI das neue Firmware-Image zu installieren [...]

Hier habe ich jetzt meine Probleme, die Absicht dahinter zu verstehen. Welches Image willst Du wo installieren? Du kannst doch ganz simpel in der Freetz-Version eine Shell-Session starten und dort direkt das "modfs update" ausführen ... das installiert dann ganz von alleine in der inaktiven Partition das neue System und schaltet (nach erfolgreichem Abschluß aller Arbeiten) auf diese Version um. Startet die Box dann mit dieser Version, kannst Du problemlos in der "Neustart"-Seite (vorausgesetzt, Du hast den "bootmanager" installieren lassen als Modifikation) wieder auf die zuvor genutzte Freetz-Version zurückschalten. "modfs" faßt die Freetz-Einstellungen nicht an ... es gibt auch keine (öffentlichen) "modscripts", die irgendetwas im TFFS speichern. Alle Änderungen erfolgen an den Dateien im SquashFS-Image - einzige Ausnahme war die Installation von "ShellInABox" als Starter-System für "unmodifizierte" Firmware, was aber primär gar nicht direkt zu "modfs" gehört.

 

[eisbaerin]

@Peter:
Ich habe bei mir 2 modskripts etwas verändert, dann sieht es im Ergebnis besser aus, da die anderen ["help"] Zeilen in der menu_data.lua jetzt auch alle so aussehen (siehe mod_night 5 Zeilen über der Änderung):

mod_leddisplay Zeile 61:

--- usr/www/$TARGET_BRANDING/menus/menu_data.lua
+++ usr/www/$TARGET_BRANDING/menus/menu_data.lua
@@ -1273,6 +1273,11 @@
 ["dev"] = true,
 ["lua"] = "developer.lua"
 } or nil,
+["led"] = {
+["show"] = true,
+["lua"] = "system/led_display.lua",
+["help"] = [COLOR="#FF0000"][B]([/B][/COLOR]forLuaOnly and "hilfe_system_anzeige"[COLOR="#FF0000"][B]) or true[/B][/COLOR]
+} or nil,
 ["liveTv"] = {
 ["show"] = ("string" == type(data.lnkTv) and "non-emu" ~= data.lnkTv and "" ~= data.lnkTv),
 ["lnk"] = data.lnkTv

mod_night Zeile 40:

--- usr/www/$TARGET_BRANDING/menus/menu_data.lua
+++ usr/www/$TARGET_BRANDING/menus/menu_data.lua
@@ -442,6 +442,11 @@
 ["lua"] = "system/wlan_night.lua",
 ["help"] = (forLuaOnly and "hilfe_system_nachtschalt_wlan")[COLOR="#00FF00"] or true[/COLOR]
 } or nil,
+["night"] = config.TIMERCONTROL and {
+["show"] = true,
+["lua"] = "system/nacht.lua",
+["help"] = [COLOR="#FF0000"][B]([/B][/COLOR]forLuaOnly and "hilfe_system_nachtschalt_wlan"[COLOR="#FF0000"][B]) or true[/B][/COLOR]
+} or nil,
 ["wGuest"] = (config.WLAN and config.WLAN_GUEST) and {
 ["show"] = showWGuest(),
 ["lua"] = "wlan/guest_access.lua",

Vielleicht änderst du es ja auch bei dir und für uns vor einer "Neuauflage".
Ja, ich weiß es geht auch so, es ist ja nur wegen der Schönheit.

Ich danke dir auch noch für die Hilfe in #1057. Ich habe das modskript in #1056 noch überarbeitet, so daß es jetzt von dir übernommen werden kann.
Leider hat noch keiner einen Erfolg/Mißerfolg gepostet. Hat keiner eine gemod-f-s-te FB7412?

if [ "${TARGET_SYSTEM_VERSION%%.*}" = "209" ]; then
# 7412
else
# keine 7412
fi

da habe ich mir erlaubt die "209" durch "137" zu ersetzen, dann klappt es auch mit der Nachbarin dem Skript.

 

[Shirocco88]

da die anderen ["help"] Zeilen auch alle so aussehenmod_leddisplay Zeile 61:

+["help"] = [COLOR=#FF0000][B]([/B][/COLOR]forLuaOnly and "hilfe_system_anzeige"[COLOR=#FF0000][B]) or true[/B][/COLOR]

das verstehe ich nicht;
aus der booleschen Mathematik/Algebra habe ich noch in Erinnerung "A OR B" liefert für B=true als Ergebnis der Term-Evaluierung immer "1" oder "true"
d.h. Du könntest es gleich die Zeile auf "["help"] = true" reduzieren;
optische Mehrwerte kann ich auch nicht erkennen.

IMHO: wenn da 5 Zeilen weiter oben so etwas steht, dann sollten diese Korrektur-Hinweise (den rot markierten Teil aus dem LUA-Code herausnehmen) an den entsprechenden AVM-Programmierer gesendet werden ;-)

 

[PeterPawn]

Na ja, das ist so eine Sache mit Lua ... das sind hier binäre Operatoren und solange "forLuaOnly" hier nicht "false" ist (das kommt ja als Parameter beim Aufruf von "getPageData()" rein), ergibt das die Zeichenkette in der Klammer; ansonsten das "true" hinter der Klammer.

# lua
Lua 5.2.3  Copyright (C) 1994-2013 Lua.org, PUC-Rio
> [COLOR="#0000FF"]print ( ( false and "string" ) or true )[/COLOR]
true
> [COLOR="#0000FF"]print ( ( true and "string" ) or true )[/COLOR]
string
> [COLOR="#0000FF"]var=false[/COLOR]
> [COLOR="#0000FF"]print ( ( var and "string" ) or true )[/COLOR]
true
> [COLOR="#0000FF"]var=true[/COLOR]
> [COLOR="#0000FF"]print ( ( var and "string" ) or true )[/COLOR]
string
>

Rein mit Algebra kommt man also zum falschen Ergebnis.

 

[eisbaerin]

das verstehe ich nicht;

Ich noch viel weniger. Aber mit Algebra hat das wahrscheinlich nix mehr zu tun.

d.h. Du könntest es gleich die Zeile auf "["help"] = true" reduzieren;

Nein, denn dann würde ja nicht mehr die richtige Hilfe-Seite "hilfe_system_anzeige" angeboten.

Warum AVM aber neuerdings (seit 06.80?) das "or true" noch dazu setzt?
Vielleicht kann uns Peter oder ein anderer da Erleuchtung geben.
NEIN, NEIN, NEIN, Peter laß es! Du mußt dir keine Mühe machen!
Ich verstehe an deinen ausgiebigen tiefgründigen Ausführungen meist nur die Hälfte (oder weniger).

Mir ist nur aufgefallen, daß unsere dazu gemogelten Zeilen durch das fehlende "or true" etwas aus der Reihe tanzen.

 

[PeterPawn]

@eisbaerin:
Es ist nicht so, daß ich mich dem Hinzufügen verweigern würde ... aber mit der nächsten Änderung (in der nächsten Woche) kommt die Unterstützung für die 75x0-Modelle dazu (wobei die 7570 da ja nicht hineinpaßt, ich meine also nur die 7580 und die 7560) und im Zuge dessen wird es einen neuen Header für die Skript-Dateien geben, mit dem man Skripte für bestimmte Modelle ein- bzw. ausschließen kann.

Da würde ich dann lieber ein weiteres Skript integrieren, wenn es diese neue Variante bereits unterstützt - die Entscheidung dafür ist aber erst in dieser Woche gefallen, als ich mit der 7580-Umsetzung begonnen habe (weil bei den neuen Modellen auf einmal alle meine eigenen Skripte, die auf die yaffs2-Partition unter "/wrapper" gesetzt haben, eine Unterscheidung brauchen).

Auch wäre es nett, wenn ein zweiter Interessent Dein Skript mal bei sich anwenden könnte ... es geht mir nur um die Bestätigung (von dritter Seite), daß der Patch wie erwartet arbeitet. Ich habe zwar selbst auch noch eine 7412, aber wenig bis keinen Ehrgeiz, das meinerseits zu testen (weil ich es nicht wirklich brauche und meine 7412 eigentlich mit originaler Firmware läuft für die Suche nach weiteren Lücken).

 

[Goggo16]

So. Kurze Rueckmeldung von mir.

Update von 6.51 mit Freetz auf 6.80 mit Freetz hat funktioniert. Hab bislang keine Fehler gefunden. Umschalten zwischen den zwei Versionen geht auch.

Bei "modfs update image-datei" hatte es einen Signaturfehler gegeben. Hab dann das neue Image über das Freetz-GUI installiert. Da gibt es (noch) keine Signaturprüfung.

Vielen Dank für diesen komfortablen Weg, zwischen zwei Images bzw. Versionen hin und her schalten zu koennen.

LG, Goggo

 

[Shirocco88]

Bei "modfs update image-datei" hatte es einen Signaturfehler gegeben.

wie wäre es mit "NOVERIFY=1 ./modfs update image-datei", das funktioniert bei mir.

 

[koyaanisqatsi]

:!:

ich meine also nur die 7580 und die 7560

...die "Impffirmware" 6.52 wartet :ziggi: schon dadrauf.

 

[eisbaerin]

mit dem man Skripte für bestimmte Modelle ein- bzw. ausschließen kann.

So ähnlich hatte ich mir das ja mit meiner Frage in #1056 gedacht. Ein z.B. preprecheck, der modscripts nur zur Ja/Nein Frage anbietet, wenn sie sinnvoll für diese FB sind.

Oder du machst es ähnlich wie bei mod/bin, und verlinkst nur die für diese FB sinnvollen modscripts.


Das "or true" übernimmst du aber 2mal?

Auch wäre es nett, wenn ein zweiter Interessent Dein Skript mal bei sich anwenden könnte ... es geht mir nur um die Bestätigung (von dritter Seite), daß der Patch wie erwartet arbeitet.

Ja, darauf warte ich auch schon die ganze Zeit sehr gespannt! (es geht um #1056, um den Datenverbrauch in der FB7412 anzuzeigen)

- - - Aktualisiert - - -

Da würde ich dann lieber ein weiteres Skript integrieren, wenn es diese neue Variante bereits unterstützt

Ja, wenn du diese neue Variante schon mal vorstellst, dann könnte ich ja mal versuchen das Skript anzupassen. IMHO schaffst du aber die Anpassung schneller, da du ja weißt worauf es ankommt.

 

[Goggo16]

wie wäre es mit "NOVERIFY=1 ./modfs update image-datei", das funktioniert bei mir.

Ah, OK. So einfach.

Hab wohl nur die (gefuehlt) ersten 16 Kapitel gelesen und verzichtete dann unweise auf den Rest der Lesereise (frei nach den zwei Ameisen aus Hamburg). ;-)

LG, Goggo

 

[iol]

FRITZ!Box 4040 modfs geeignet?

Hallo zusammen, bin neu hier und dies ist mein erster Beitrag hier (bitte nicht zerfleischen):

Überlege mir, die FRITZ!Box 4040 zu kaufen.

Gibt es irgendwo nähere Infos zur FRITZ!Box 4040 (bzgl. RAM, NAND, dualboot, modfs)?

Da die Laborversion der 4040 zusammen mit einigen (inoffiziell) von modfs unterstützen Versionen gelistet ist (FRITZ!Box 7272, 6840, 6820, 5490 und 4040.), würde ich die Wahrscheinlichkeit, dass die FRITZ!Box 4040 auch modfs geeignet ist, relativ hoch einschätzen...

Sehen das die Experten hier auch so, d.h.: ist die FRITZ!Box 4040 modfs geeignet?

Wenn die Wahrscheinlichkeit hoch ist, würde ich sie bestellen und hier berichten (bin auch geneigt, sie aufzuschrauben und Fotos zu posten).

~
Danke, iol

 

[KunterBunter]

nähere Infos zur FRITZ!Box 4040 (bzgl. RAM, NAND, dualboot
Also: Wahrscheinlichkeit eher nicht hoch, sondern null

 

[Shirocco88]

modfs funktioniert IMHO nur für (ausgewählte NAND) Boxen; und bei Freetz ist die FB4040 auch nicht supportet; Quelle http://www.freetz.org/browser/trunk/FIRMWARES

 

[iol]

Hier noch ein paar Sachen zur Fritz!Box 4040, die ich in der Laborfirmware gefunden habe:

http://www.ip-phone-forum.de/showthread.php?t=279759&page=4&p=2212233#post2212233

 

[eisbaerin]

Auch wäre es nett, wenn ein zweiter Interessent Dein Skript mal bei sich anwenden könnte

Also ich habe es jetzt auf einer 2. FB7412 für einen Freund installiert. Läuft bestens! Alle Werte werden ordentlich angezeigt.

Der "boot_manager" scheint aber bei dieser FB nicht richtig zu funktionieren.
Bei mir habe ich das nicht gemerkt, da ich in der anderen Partition eine sehr alte FW habe, und die wird ja nicht erkannt.
Jetzt habe ich aber die 137.06.50 und 137.06.83 drauf gemacht. Dabei wird immer die aktive ordentlich erkannt, aber bei der nicht aktiven steht immer unbekannt.
Beide mit "gui_boot_manager_v0.3" erstellt. Soll ich mal die alte "gui_boot_manager_v0.2" probieren?

 

[PeterPawn]

Nein, mach mal bitte in der Konsole (ich hoffe, Telnet o.ä. ist aktiviert) einen Aufruf "sh -x /usr/bin/guibootmanager html_display" und stelle die Ausgabe hier ein. Da sollte man sehen können, woran die Erkennung des alternativen Systems scheitert.

 

[eisbaerin]

Bitteschön:
Anhang anzeigen Neustart.txt

 

[PeterPawn]

Danke.

Bei AVM fehlt offenbar (vielleicht sogar bei allen Versionen ohne NAS?) auch gleich das komplette "blkid"-Kommando. Bei mir macht sich das nicht bemerkbar, weil ich parallel immer noch die BusyBox gegen eine eigene austausche.

Bei fehlendem "blkid"-Kommando wird zwar "squashfs" als Dateisystem-Format für die "filesystem"-Partition angenommen, aber das stimmt bei der 7412 eben nicht, weil es dort "yaffs2" ist und erst darin das SquashFS-Image liegt.

Schnellster Workaround ist die Verwendung einer BusyBox mit "blkid"-Kommando oder auch ein passendes externes Kommando, was dieselbe Ausgabe erzeugt - da sind die "blkid"-Versionen auch manchmal etwas zickig.

Für eine generellere Lösung bin ich noch am Arbeiten - deshalb dauert das jetzt auch schon wieder länger, als ich eigentlich wollte.

Man braucht für bestimmte Skripte eben nicht nur eine Abhängigkeit vom Modell der behandelten Firmware (das kann sich eben auch noch vom Modell unterscheiden, auf dem "modfs" gerade läuft - ich lasse das gerade auf einem RasPi laufen), sondern am besten auch noch einem Mechanismus, daß ein Skript von einem zweiten abhängig ist (mit und ohne Einhalten einer Reihenfolge beim Patchen - das kann nämlich auch schiefgehen, weil zwei "modscripts" dieselbe Datei ändern wollen; ging mir bei der "menu_data.lua" so) bzw. von der Existenz eines bestimmten Kommandos im Zielsystem.

Letzteres ist auch die größere Hürde ... bei einem System mit einer "BusyBox" muß eben - je nach Optionen beim Erstellen der BB - nicht für jedes verfügbare Kommando auch ein Symlink existieren (weil die BusyBox irgendwann auch intern sucht und dann auch Applets ohne Symlink findet) und die Liste der in einem BusyBox-Binary enthaltenen Applets (normalerweise einfach durch "busybox --list" abzufragen) kriegt man auch nur auf dem modifizierenden System heraus, wenn das dieselbe Architektur ist und man das Kommando einfach ausführen kann. Also muß man die Liste der Applets mühsam auf anderem Weg aus dem BusyBox-Binary extrahieren (über "strings" und unter Berücksichtigung der Annahme, daß die Liste der Applets streng aufsteigend sortiert ist).

 

[remoter3406]

Update auf .83 nicht möglich

Hallo zusammen,
Update der 7490 auf .83 geht nicht. Wer kann mir helfen?

# ./check_update -d
===================================
Variables set:
Serial="xxxxxxxxx"
Major="113"
Minor="6"
Patch="80"
Build="42822"
Name="FRITZ!Box 7490"
HW="185"
OEM="avm"
Lang="de"
Annex="B"
Country="049"
Public=""
type="1001"
hostname="185.jws.avm.de"
nonce="sJk/N1/Eb4AIheHHu7duxQ=="

===================================
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/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:e="http://juis.avm.de/updateinfo" xmlns:q="http://juis.avm.de/request"><soap:Header/><soap:Body><e:BoxFirmwareUpdateCheck><e:RequestHeader><q:Nonce>sJk/N1/Eb4AIheHHu7duxQ==</q:Nonce><q:UserAgent>Box</q:UserAgent><q:ManualRequest>true</q:ManualRequest></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><q:Patch>80</q:Patch><q:Buildnumber>42822</q:Buildnumber><q:Buildtype>1001</q:Buildtype><q:Serial>xxxxxxx</q:Serial><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><q:Provider>oma_lan</q:Provider></e:BoxInfo></e:BoxFirmwareUpdateCheck></soap:Body></soap:Envelope>


./check_update: line 225: nc: not found
===================================
Received response:

======= end of debug output =======
Unexpected data received from network.
#

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.80-42822

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

Ermitteln der neuesten Version durch Abfrage beim Hersteller ... Fehler
Es wurde keine neuere Version als 113.06.80-42822 gefunden, Abbruch.
#