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

[PeterPawn]

Wie gesagt, die Erkenntnisse entwickeln sich ja weiter ... vieles, was dort noch unklar war (z.B. wie das Flashen aus dem laufenden System dann läuft), ist heute geklärt.

 

[RAMler]

Ich bin jetzt gerade mal den Thread hier durchgegangen, vielleicht habe ich es trotzdem übersehen.
Gibt es für die aktuelle 6.35 Labor auf der 7490 eine Möglichkeit telnet per pseudo-image wieder zu aktivieren? Konnte ich so nicht finden, nur eben der Weg, es aktiviert zu lassen, wenn man vorher schon modfs drauf hatte (und für die 6.35 bist du da ja am weiterentwickeln).

Wenns ein pseudo-image geben sollte, wäre ich für einen Link/C&P Code sehr dankbar.

EDIT:
Als Querverweis, für Leute die ähnliches suchen:
http://www.ip-phone-forum.de/showthread.php?t=279936

 

[KiRKman]

Mit modfs kann man ja die 06.35 noch nicht installieren. Und ein Pseudo-Image, um Telnet wieder zu aktivieren, ist mir für die 06.35 ebenso bisher nicht untergekommen.

Genau aus diesem Grunde habe ich die 06.35 auch noch nicht installiert Ich würde das halt gerne direkt aus modfs heraus machen, um mir Telnet zu erhalten. Gerne würde ich die 06.35 installieren, wenn ich danach auf ein Pseudo-Image für die Telnet-Reaktivierung zurückgreifen könnte.

Es ist aber auch (manchmal) ein Kreuz mit AVM.

 

[PeterPawn]

@KiRKman:
Es wird definitiv im Laufe der Woche ... das mksquashfs4 läuft schon, nur das modfs muß eben erst einmal zur Unterscheidung zwischen SquashFS4 und SquashFS3 "aufgebohrt" werden; das muß ja alles noch von 06.25 im "update"-Modus erfolgen und auch wenn das gepackte Image "von außen" gut aussieht, ist die wahre Nagelprobe das Mounten des neu gepackten Images unter dem neuen Kernel und ich habe den immer noch nicht aktiviert.

 

[RAMler]

@KiRKman:

Schau mal in den Link einen Post über deinem, Post 15. Pseuoimage - welches mit der 6.35 geht.

 

[KiRKman]

Danke für den Hinweis, aber ich suche im Prinzip schon nach einer dauerhaften Lösung. An der Vorgehensweise mit Pseudo-Image stört mich, dass viele Dienste der Box für den Update-Vorgang regelmäßig beendet werden und man diese nachher nicht wieder 100% neu gestartet bekommt. Man müsste halt ordnungsgemäß neu booten, wodurch die Änderungen aber wieder nichtig wären

 

[koyaanisqatsi]

Moins

Das...

wodurch die Änderungen aber wieder nichtig wären

...stimmt so nicht.

Erhalten bleiben...
1. Richtige, fehlerfreie Änderungen der /var/flash/ Zeichengerätedateien
2. Richtige und Falsche des Eva/ADAM2 Environments

 

[RAMler]

@KiRKman:

Du könntest halt jetzt schon einmal auf die 6.35 wechseln und müsstest nicht bangen, dass du später kein modfs mehr drauf bekommst.
Sobald das fertig ist könntest du es dann ja über telnet installieren.

Oder einfach gleich auf das fertige modfs für die 6.35 warten.

 

[PeterPawn]

So, eine neue Version von modfs ist verfügbar, sie unterstützt jetzt auch den 06.35er-Labor-Zweig.

Der zum Bauen des mksquashfs-Binaries für die Ausführung auf der FRITZ!Box notwendige Patch steht unter der URL

http://yourfritz.de/7490/avm_be_xz_mksquashfs_target.patch

zum Download zur Verfügung. Dieser Patch verträgt sich nicht mit meinem Patch für unsquashfs, es ist also ein "frisches Base-Directory" mit der Version 4.3 der squashfs-tools erforderlich. Der Patch steht da vorerst auch nur, um der GPLv2 zu entsprechen, denn das modfs-Archiv enthält ein mksquashfs4-Binary und damit ist das Veröffentlichen des Quellcodes erforderlich. Nachdem das nur ein Patch gegen das Original ist, braucht es keine weiteren Skript-Files o.ä. zum Erstellen dieses Binaries, das ist "normales Vorgehen", nachdem der Patch angewandt wurde.

Die Integration beider Patches in ein gemeinsames Paket (ggf. auch gleich noch in ein gemeinsames Paket für einen LE-Build-Host und die VR9-Targets (BE)) wird noch einiges an Aufwand erfordern, ich stand jetzt vor der Entscheidung, das bisher Funktionierende endlich mal zu veröffentlichen oder weiter an Optimierungen zu basteln, die bestimmt noch locker zwei Wochen brauchen.

In diesem Kontext ist auch der "unvollständige Boot-Manager" zu sehen. Wenn man in einer Box mit unterschiedlichen Kernel-Versionen in den beiden Partitionen auf der Reboot-Seite die Auswahl zwischen beiden Systemen aktiviert hat (ist ja ein optionaler Patch), dann können diese Systeme wechselseitig die Versionsnummer des jeweils anderen nicht auslesen, das endet im Moment im besten Falle (wenn schon die aktuelle Version verwendet wird) mit "unknown" für die variablen Texte ... solange da aber eine ältere Version von "guibootmanager" im Dateisystem ist, liefert die nur einem "mount"-Fehler. Da dort dann das Ermitteln der Versionen von "mount" auf "unsquashfs" umgestellt werden müßte und das alles andere als "responsive" wäre, verzichte ich auf diese Spielchen und nehme dieses "Problem" in Kauf. So muß man sich halt merken, welche Version in der anderen Partition liegt, das Umschalten funktioniert ja trotzdem. Das Problem der unterschiedlichen Einstellungen (beim Wechsel von 06.35 auf 06.25 relevant) ist damit aber auch noch nicht gelöst, das könnte dann nur der "richtige" bootmanager und der kennt im Moment die Versionsgeschichte beim Mounten auch noch nicht. Die Sicherung von Einstellungen (liegen ja dann im yaffs2 und nicht im SquashFS) funktioniert, auch das Umschalten ... nur das Auslesen von Versionen klappt eben wechselseitig ebenfalls nicht zwischen 06.25 und 06.35 - wie beim guibootmanager auch.

Ansonsten funktionieren die wichtigsten "mitgelieferten" modscripts auch bei der neuen Version problemlos bei mir, sowohl Telnet als auch "guibootmanager" (Einschränkung s.o.) und "debug.cfg/rc.user" klappten auf Anhieb, nachdem erst einmal das Format des erzeugten Dateisystems stimmte.

Wichtig wäre es noch, daß man beim Download beachtet, daß die vorherige Version unter der URL

http://yourfritz.de/modfs.tgz

weiterhin zur Verfügung steht, die neue Version ist nur über die URLs

http://yourfritz.de/modfs_with_0635.tgz oder
http://yourfritz.de/7490/modfs.tgz

zu erreichen.

Wenn ich jetzt nicht beim Deployment etwas durcheinander gebracht habe, sollte es klappen ... über Rückmeldungen (gerade für 06.35 natürlich) würde ich mich freuen, auch über positive - man kann nach solchen Änderungen nicht alles komplett erneut testen.

Für eine "Machbarkeitsstudie" ist das Ganze inzwischen ohnehin zu komplex geworden ... das muß weiter modularisiert werden, damit da auch so etwas wie "unit tests" möglich werden. Ob "ash" dafür die richtige Basis ist? In mir baut sich immer mehr der Gedanke an eine Umstellung auf Lua auf ... das ist ebenfalls auf der Box vorhanden (wichtig für den "ersten Kontakt"), kann objektorientiert genutzt werden (gut zu modularisieren) und wäre ein Schritt hin zu einer "graphischen" Lösung, wenn man die Ausgabe entsprechend flexibel gestaltet.

 

[koyaanisqatsi]

Hört Hört
Verfolgen tu ich dieses Projekt ja interessiert im Hinblick auf künftige Hardwareanschaffung (7262SL oder 7490).

In mir baut sich immer mehr der Gedanke an eine Umstellung auf Lua auf

Deswegen gestatte mir die Frage: Für/Wegen dem AVM Webinterface?
Sozusagen als GUI für modfs?

 

[PeterPawn]

Auch ... habe ich ja schon genug zu geschrieben.

Aber das AVM-Interface fluktuiert ohnehin zu stark, als daß man sich da "anhängen" sollte - da ist ein eigenes Interface (unter Nutzung von AVM-APIs, u.a. zum AAA) dann schlauer (meines Erachtens).

Lua "kann" ja auch STDIO und mir geht es in erster Linie darum, mit möglichst wenigen zusätzlichen Komponenten (für modfs - was der Benutzer installieren will, interessiert mich nicht) auszukommen. Da ist dann Lua die einzige "Programmiersprache", die auf der Box vorhanden ist. Da braucht man weder Perl, noch PHP oder Python nachinstallieren, damit überhaupt modfs erst einmal läuft.

 

[koyaanisqatsi]

Nananah...

Da ist dann Lua die einzige "Programmiersprache", die auf der Box vorhanden ist

...wohl Shellskriptmüde geworden? Oder Betriebsblind?

Webserver
Als ich endlich kapiert habe was CGIs sind, habe ich mir gewünscht, die PHPler wüssten das auch.
...auf der Box gehts damit einfach am einfachsten/schnellsten.

LUA ist halt auch noch da. Und wird als "Makrosprache" ja Vielerorts angewandt.
...und bei LUA und/oder PHP ist halt das Plattformübergreifende vorteilhaft.

 

[PeterPawn]

In Shell-Code sind nur eben "unit tests" (das sind kleine Tests für die korrekte Funktion und Fehlerbehandlung einzelner Code-Teile) "a pain in the ass" und für einen wartbaren Code braucht es genau so eine Zerlegung in kleinere Einheiten (geht bei Shell auch, aber mit einem riesigen Aufwand beim Austausch von Variableninhalten zwischen diesen Einheiten), die jede für sich ein genau definiertes Verhalten zeigen. Wenn man dann irgendwo ändert, muß man nicht den gesamten Code erneut testen ... der Theorie nach funktioniert so ein Modul dann, wenn es diese Unit-Tests besteht. Das macht schon einen gewaltigen Unterschied ... selbst wenn man den anderen Aspekt der Modularisierung (das wäre die Wiederverwendbarkeit) gar nicht braucht oder haben will.

 

[BurningCrash]

Wenn Telnet noch vorhanden ist auf der Box ist mir das Vorgehen ja klar. Aber wie läuft das z.b. bei der 6.35-FW ab? Wie patche ich dort?

Danke im Voraus

 

[PeterPawn]

Entweder

- auf eine vorher installierte Version vor 06.25 "zurückschalten" oder

- Recovery auf eine Version mit Telnet oder

- Pseudo-Image für den Telnet-Start unter 06.35 verwenden (vorher das modfs-Paket nach /var/media/ftp schieben, sonst wird es eng mit dem Laden aus dem Internet)

Das wären jetzt so die ersten drei Möglichkeiten, die mir einfallen, wobei ich die in der Reihenfolge 3, 1, 2 probieren würde ... in diesem Sinne: It's tool time and pimping your Binford 7490 FRITZ!Box to get more power is even home improvement.

Das Thema "Pseudo-Image für Telnet-Start unter 06.35" hatten wir gerade erst irgendwo ...

 

[KiRKman]

Ich bin irgendwie zu blöde, das Script zu benutzen. Ich mache offensichtlich an irgendeiner Stelle einen entscheidenden Fehler.

Die "Labor.113.06.35-30896" liegt auf einer externen USB-Festplatte. Ist dies das Problem? Ort: "/var/media/ftp/Samsung-S2Portable-01/fw/labor.image"

Ich lege los:

mkdir -p /var/mod;cd /var/mod;wget -qO- http://yourfritz.de/[B]7490[/B]/modfs.tgz | gunzip -c | tar x

(ich gucke mir alles mal oberflächlich an, dann starte ich das Script)

./modfs update

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.29

Die Auswahl des 'update'-Modus erfordert eine neuere Firmware-Version vom
FTP-Server des Herstellers.

Ermitteln der neuesten Version durch Suche auf dem FTP-Server ..../modfs: line 1: head: not found
 Fehler
Die neueste Versionsnummer auf dem FTP-Server kann nicht ermittelt werden, Abbruch.

Soweit alles wie erwartet - der automatische Download der neuen Version geht ja beim Labor nicht. Also starte ich das Script erneut und gebe die Datei an.

# ./modfs update /var/media/ftp/Samsung-S2Portable-01/fw/labor.image

Er kann dann aber das Root-Filesystem nicht extrahieren:

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/Samsung-S2Portable-01/fw/labor.image' wird als Quelle für die Aktualisierung genutzt.

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 ... Fehler

Das extrahierte 'äußere Dateisystem' kann nicht eingebunden werden.

Wo liegen die Dateien denn jetzt? Ich würde sonst mal versuchen, mir das anzusehen. Bin jetzt ehrlich gesagt etwas hilflos. Die README.ger habe ich komplett gelesen, fand ich auch sehr interessant, aber irgendwie hilft mir das jetzt auch nicht weiter


Nachtrag: "Samsung-S2Portable-01" ist ext2, ebenso ein anderes angeschlossenes Laufwerk. Könnten beide also eigentlich sofort verwendet werden, ohne eine Containerdatei im ext3-Format erstellen zu müssen. Falls das damit zu tun haben könnte...

 

[PeterPawn]

Das hört sich eher so an, als wenn ich doch bei Auschecken der Version durcheinander gekommen bin - das kam mir gleich so merkwürdig vor, was da beim Packen passierte (daher auch das "Deployment-Problem").

Ich schaue mir das nachher gleich noch einmal an ... wobei ich noch ein Problem gesehen habe, was die Versionen vor 06.29 wohl noch nicht hatten.

/modfs: line 1: head: not found

Das liest sich ja so, als ob das head-Applet in der 06.29 nicht enthalten ist - das habe ich nie versucht, die 06.29 war bei mir nie Thema - und so wie sich der Update-Prozess darstellt, kann ich mir auch vorstellen, daß dort losetup ebenfalls nicht vorhanden ist.

Das könnte dann auch erklären, warum AVM den relativ komplizierten Weg über dd wählt, um das ext2-Image zu mounten ... wenn in der 06.29 wirklich kein losetup mehr enthalten ist, haben sie sich dieses Problem tatsächlich erst nach der 06.24 (von dort bin ich bei allen Tests vorgegangen) selbst "eingebrockt".

Bei einem Fehler bleiben auch (hoffentlich) keine Dateien liegen, die werden alle wieder ordentlich abgeräumt - das hilft Dir also nicht wirklich weiter, außer Du willst es "richtig zu Fuß" machen, dann kannst Du wenigstens die Programme zum Entpacken und Packen des SquashFS4 verwenden.

Ich werfe nachher mal einen Blick in die 06.29, was da sonst noch so an Veränderungen in Bezug auf die verfügbaren Programme passiert ist. Ob Dir die Empfehlung, von der 06.24 aus das Update - genau so, wie oben von Dir versucht - zu machen, weiterhilft, mußt Du selbst entscheiden.

Auch habe ich den Eindruck, daß bei der bereitgestellten Version (s.o. - Problem beim Auschecken) das "normale Modifizieren" innerhalb der 06.35 wieder fehlt, die Funktion zum Suchen des Firmware-Images in vorhandenen Mount-Points sieht komisch aus und beim Modifizieren des vorhandenen root-FS fehlt wohl auch beim Auspacken die Abfrage der Version und die Auswahl des richtigen "unsquashfs"-Programms.

Das ist genau der Zweig, den ich auch erst einbauen/testen konnte, als ich schon zum Test auf der 06.35 war (vorher ist ja die Änderung innerhalb der Version schlecht zu testen) und irgendwie sind diese Änderungen wahrscheinlich versehentlich von mir ebenfalls überschrieben worden (durch falsches Merge beim Checkout), als ich Änderungen am SquashFS4-Patch zurückrollen wollte.

Damit taugt das nun wohl nur noch zum Update von der 06.24 (von der 06.25 aus habe ich auch nicht getestet, wenn da weitere Applets (losetup) schon fehlen, wird das auch nicht funktionieren) auf die 06.35 - ob das jemandem etwas nutzt, weiß ich nicht.

Glücklicherweise kam mir das dann gleich so komisch vor, daß ich es unter einem anderen Namen bzw. Pfad bereitgestellt habe und damit wenigsten die vorherige Version noch vorhanden ist, wenn jemand die 06.25 modifizieren will. Das Update von der 06.24 (Release) auf die 06.25-RC (mit Einbau von Telnet) funktioniert ja auch - mit der Vorgängerversion -, genauso wie die Modifikation der 06.25 von der 06.25 aus (da sollte dann auch noch "head" vorhanden sein, denn dieser "Fehler" ist neu).

Ich schaue mir das wie gesagt noch einmal an ... komme aber erst gegen Abend dazu. Ob ich am Ende dann noch ein eigene Busybox in das Paket packe oder das Verhalten von fehlenden Applets nachbilde oder auf die 06.29 komplett "verzichte" (ist ja nur eine "Episode" bei AVM, da lohnt sich der Aufwand eigentlich fast nicht), kann ich noch nicht sagen.

 

[KiRKman]

Ich probiere das dann gerne wieder aus, wenn's was Neues gibt Vielen Dank für Deine Mühen!

In meinem Fall ist das alles eigentlich nur wegen Telnet. Verrückt. Aber was will man machen.

Zum etwaigen Ausprobieren käme ich allerdings erst morgen. Vorher könnte ich Dir leider sowieso kein Feedback geben. Vielleicht ist ja noch jemand da, der zufällig von der 06.29 auf die 06.35 möchte.

 

[KingTutt]

Das Thema "Pseudo-Image für Telnet-Start unter 06.35" hatten wir gerade erst irgendwo ...

RAMler hatte in #102 schon einmal danach gefragt. Allerdings habe ich auch mit der Suche nichts brauchbares gefunden.

Wenns ein pseudo-image geben sollte, wäre ich für einen Link/C&P Code sehr dankbar.

EDIT:
Als Querverweis, für Leute die ähnliches suchen:
http://www.ip-phone-forum.de/showthread.php?t=279936

Hier steht zumindest "zwischen den Zeilen" was man machen müsste, ein fertiges image gibt es jedoch nicht.

@Peter: warum stellst Du nicht bei Deinem modfs gleich noch ein passendes pseudoimage bereit? Ich lese immer wieder mit Begeisterung Dein (technisch guten) ausführlichen Beiträge. Leider sind die teilweise sehr verteilt/vertreut hier im Forum, so dass es ein wenig an einer Sammelstelle fehlt, wo man alles zusammenhängend nachlesen kann..
BTW. Hut ab vor Deiner Beschreibung für die Aktivierung von Telnet mit DOCIS Boxen.

 

[RAMler]

Bei mir wärs auch nur wegen Telnet. Da hat AVM uns schön was eingebrockt.
Wieso nicht einfach SSH und dann nur zu aktiveren über Umwege wie PseudoImage, dafür dann aber dauerhaft? Dann wäre der Dauschutz ja vorhanden gewesen, wir aber hätten es weiterhin bequem gehabt.

@KingTutt:

Dort im Post 15 den Inhalt mit z.B. Notepad++ korrekt formatiert (machte ich ja erst falsch) als \var\install als tar packen und als Firmware flashen. Bedenke das danach viele Dienste tot sind. koyaanisqatsi hat ja manches auskommentiert, was du beim "flashen" ggf. schon wieder starten lassen willst. Musst du halt vorher "aktiv stellen" (Raute davor weg).

Telefon kannst du einfach mit einem "telefon" über telnet starten, DECT bleibt tot. Wie man den dect-manager über "telefon" startet, weiß ich leider nicht. Ihn nach telefon einfach zu starten scheitert, DECT bleibt tot.