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

Bei positiven Rückmeldungen (oder ausbleibenden negativen) und nach einer gewissen "Reifezeit" für die v0.4 gewiß ... im Moment sollte #1116 ausreichend sein und da die "precheck"- und "postcheck"-Kontrollen bei beiden Versionen dieselben sind, sollte eine versehentliche Verwendung beider Versionen nicht auftreten können. Wenn jemand bei beiden mit "j" antwortet und der zweite Versuch mit "ist bereits integriert" gegen die Wand fährt, halte ich das nicht für ein wirkliches Problem (und es erzeugt ein "Bewußtsein", daß es eine neuere Version gäbe, auch wenn man hier nicht mitliest). Da wären meine Befürchtungen, daß die v0.4 noch Macken hat und jemand lieber die v0.3 verwenden will, das aber bei entferntem "x" für die Gruppe nicht finden kann, deutlich größer.
 
Vielen Dank für den Support, 6.80 und 6.83 auf der FritzBox 7362sl eingerichtet.

668b85b0600f0c950eebf1a90222cd70.jpg



AVM FritzBox 7490 6.60
AVM FritzBox 7363sl 6.50 modfs
Gesendet von iPhone mit Tapatalk
 
zwar OT: aber

@CyberKing2k nach knapp 13 Jahren und über 1k Beiträge solltest du wissen das externe Links geblockt werden (FileUpload ?? - falls probleme letzte Zeile meiner Signatur befolgen)
 
Zuletzt bearbeitet:
Meine FB7412 mit ungemodeter 137.06.21 in der anderen Partition:
Wenn die andere Partition eine Version mit einem 2.irgendwas-Kernel enthält, ist das normal. Dieser verwendet noch eine andere SquashFS-Version (die 3) und damit läßt sich dieses Dateisystem unter einem 3.10.73-Kernel (den hat wohl das laufende System) nicht mehr mounten (Zeile 124 in der angehangenen Datei). Das kriegt zwar ggf. "modfs" selbst noch auf die Reihe (den Wechsel zwischen den SquashFS-Versionen), aber das klappt auch nur beim "Entpacken" mittels "unsquashfs" - Mounten funktioniert halt nicht und damit auch die (wechselseitige) Erkennung nicht (war erstmals Thema, als mit der 06.5x der 3er-Kernel Einzug hielt). Aber man sieht zumindest im Protokoll auch, daß er sich jetzt nicht mehr am fehlenden "blkid" stößt ... das Mounten der yaffs2-Partition (dieses Format kennen beide Kernel-Versionen) erfolgt ja noch ohne Probleme.

Allerdings habe ich dabei dann gleich noch bemerkt, daß dieses "halbe Mounten" (wenn die yaffs2-Partition funktioniert, aber das SquashFS-Image dann nicht mehr) noch Probleme beim "Aufräumen" hat ... die yaffs2-Partition bleibt bei diesem Fehler noch gemountet und die Semaphore wird trotzdem wieder freigegeben. Zwar klappt es im "cleanup" am Ende dann doch, das yaffs2-FS wieder freizugeben, aber das sollte natürlich an einer Stelle passieren, wo es noch durch die Sperre geschützt ist. Das werde ich noch korrigieren.
 
Ich hatte mich nur gewundert, daß die FB7272 sogar noch eine 120.06.03 in der anderen Partition anzeigt.
Aber die hat ja noch den alten Kernel in der 120.06.83!

Warum macht das AVM nicht halbwegs bei allen FB mit dem Kernel gleich?
Welche weiteren FB haben jetzt bei der FW06.83 noch den alten Kernel?
 
Aber die hat ja noch den alten Kernel in der 120.06.83!
Siehst Du, das wußte ich gar nicht ... ich war der festen Überzeugung, daß AVM für alle VR9-Modelle auf den Kernel 3.10.73 gewechselt ist. Erst jetzt habe ich (bei @qwertz.asdfgh in der PDF-Datei - klopf, klopf, für die 7580 fehlt da fast alles ;-) - wobei ich mit der 7580-Version von "modfs" ja auch nicht aus dem Quark komme und mich deshalb nicht "beschweren" will) nachgesehen und bemerkt, daß die 7272 ja einen AR10 hat und damit wäre die "Theorie", daß es vom Prozessor abhängig ist, dann wieder "in Kraft".
 
Hat geholfen! ;) Und schon ist eine neue Tabelle da!

daß es vom Prozessor abhängig ist,
Dann sind es also z.Z. nur die FB3272 und FB7272 mit dem alten Kernel bei modfs.

- - - Aktualisiert - - -

Zugriff per Putty habe ich ja noch auf die FB7272, also habe ich mal deine Lieblingsdatei erstellt.

Aufgefallen ist mir:
das System wurde am unbekannt zuletzt modifiziert
Liegt vielleicht daran, daß die andere Partition mit einem älteren modfs gemacht wurde.

Anhang anzeigen Neustart7272.06.83_v0.4.txt


BTW: Meinem "mod_show_data_on_counter" für die FB7412 traust du wohl noch nicht so richtig, weil du es nicht mit aufgenommen hast?
Es läuft bestens, nicht nur bei der 137.06.80 sondern auch bei der 137.06.83!
 
Zuletzt bearbeitet:
@eisbaerin:
Schick' mir das einfach einmal per E-Mail, dann nehme ich es gleich mit auf ins Repository (solange da die besprochene Abfrage auf "nur bei 7412" enthalten ist, damit nicht "Nicht-Leser" am Ende hier aufschlagen und "geht nicht" postulieren) - wenn ich da Rückfragen haben sollte (z.B. weil ich vielleicht gerne Namen/Beschreibung ändern würde), können wir das "outband" klären - auch funktioniert das dann mit Tabulatoren besser, wenn ich es nicht aus einem Beitrag hier herauskopieren und nacheditieren muß.

Das Warten auf den Mechanismus, mit dem das bereits in der Auswahl, die dem "modfs"-Benutzer angezeigt wird, anhand von Modell und/oder Reihenfolge bzw. Äbhängigkeiten von anderen Skripten korrekt selektiert und sortiert werden soll, dauert wohl doch noch länger ... ich werde wohl auch bei den GRX5-Boxen einfach mal "irgendwas" veröffentlichen, egal ob das schon "das Endziel" abbildet oder nicht.

Dabei kommt dann auch Dein Skript dazu (dann auch zum "modfs"-Archiv, welches eine neue Versionsnummer kriegt) -> ich bin ja ausdrücklich an zusätzlichen Skripten interessiert (ich nehme auch "Ideen", was "die Leute" (also mehrere) noch so brauchen könnten und setze das um, wenn es mich überzeugt und möglich ist - die "issues" im Repo enthalten schon drei oder vier "Pläne", die noch auf ihre "allgemeintauglichen" Versionen warten und wo ich bisher nur etwas habe, was man bedienen kann, wenn man weiß wie es geht) und wollte Dein Skript keinesfalls "unter den Tisch fallen lassen", wenn schon mal jemand ein solches anbietet. Ich würde das in ein "contrib"-Verzeichnis packen und in das "modscripts"-Verzeichnis verlinken (oder das "contrib"-Verzeichnis zusätzlich durchsuchen lassen beim Aufbau der Liste) ... mal schauen, ob ich da noch etwas anderes ändern muß, falls ich bisher ein "find -type f" verwende.


-Das "unbekannt" bei der 7272 liegt halt daran, daß an dieser Stelle das Dateidatum des SquashFS-Images stehen soll und dessen Dateiname und -pfad ist ohne das SysFS nicht zu ermitteln (wenn das ein 2.6-Kernel ist, dann ist auch wieder klar, warum es dort an Daten fehlt) - zumindest kommt es inzwischen nicht mehr zu den vorherigen Problemen. Ich stehe nun vor der Frage, ob ich wirklich für diese Modelle (bei den anderen Modellen mit 2.6 - außer 6490 und die hat wieder das Image ganz woanders - fehlt die Möglichkeit der Umschaltung generell und es braucht den Boot-Manager gar nicht) weitere Anstrengungen unternehmen will - und da bin ich etwas unschlüssig. Man könnte hier wieder auf "feste" Vermutungen zurückgreifen und das mit festen Pfaden ermitteln. Das sollte auch keine größeren Probleme bei fehlendem alternativen System mit sich bringen, denn wenn ich das richtig verstehe (anhand des Protokolls), geht es ja nur beim "laufenden System" um diese Angabe - beim alternativen System sollte da irgendeine Zeitangabe stehen, oder?
 
Habe die Tage eine 7412 in die Hand bekommen. Nach Aktivierung von WLAN konnte dank der Anleitung von eisbaerin und Peters modfs problemlos die 6.83.
installiert werden. Wie in einem anderen Thread von Peter beschrieben, war Telnet zwar installiert aber nicht verfuegbar. Per analogem Telefon konnte es
dann aktiviert werden. Eine 7490 hat als Basis zum Erstellen und als Kopierquelle gedient. Vielen Dank fuer die tollen Tools und die guten Anleitungen.
MfG
sulihari
 
Ich habe mal eine Version 0.4.5 eingecheckt. die erstens das zwischenzeitlich aufgefallene Problem bei der 7412 von @eisbaerin beheben sollte (die Sperre wurde aufgehoben, obwohl das FS noch gemountet war) und zweitens bei der 7272 (und der 3272) das Datum der letzten Änderung des alternativen Systems von einem festen Pfad (zum root-Image) nimmt, wenn das SysFS keine Informationen zu den Loop-Devices herausrücken will.

Und nicht zuletzt kam ein neues Verzeichnis "contrib" hinzu, wo zusätzliche - von anderen beigesteuerte - Inhalte abgelegt werden sollen. Das kann irgendeine Text-Datei mit einer Beschreibung für "Anfänger" sein, wenn jemand so etwas erstellen möchte oder was auch immer. Jedenfalls kann es in diesem Verzeichnis dann auch ein weiteres Unterverzeichnis "modscripts" geben und dort hinterlegte Dateien werden dann genauso in die Modifikationen einbezogen, wie die Dateien direkt in "modscripts".

Wer mit einer "custom_modscripts"-Datei für das automatische Setzen der richtigen Attribute arbeitet, der kann auch in diesem Verzeichnis abgelegte Dateien dort angeben ... dazu ist vor den Dateinamen (ab Spalte 2) nur noch der zusätzliche Pfad "../contrib/modscripts" zu setzen.

Solange es noch keine richtigen Abhängigkeiten zwischen zwei oder mehr "modscript"-Dateien gibt, wird die Liste der Skript-Dateien einfach nur alphabetisch nach Dateinamen sortiert. Wer also zusätzliche Dateien hat, die auf anderen aufbauen, der kann das über den verwendeten Namen steuern, bis ich etwas anderes fertig habe.

@eisbaerin:
Wenn ich die o.a. E-Mail kriegen sollte, packe ich Dein Skript dann sowohl ins Repository als auch in das tgz-File - bisher ist aber noch nichts gekommen und für heute mache ich Schluß.
 
zwei kleine Korrekturen, neues Archiv-File (modfs.tgz), Versionsnummer und "date line" unverändert

- beim Wechsel eines Skripts von "automatisch" auf "nachfragen" über "custom_modscripts" wurde das x-Flag für 'andere' nicht korrekt zurückgesetzt
- bei der internationalen Firmware (06.83) haben sich beim Patch für die VPN-Anzeige in der Übersichtsseite die "Anker-Zeilen" geändert und die Modifikation wurde nur halb ausgeführt
 
Als ewiger Anfänger ...

habe ich mir wie vormals üblich über
Code:
wget -qO- http://yourfritz.de/modfs.tgz | gunzip -c | tar x
in ein neues Verzeichnis gesaugt.

Zu erkennen modfs_version=0.4.5-300320172215

Zugegeben tue ich mich mit dem GitHub schwer!

Was mir auffiel, dass mit o.g. Version ein eigenes Script

Code:
# 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
übergangen wird, was mit meiner letzten Version modfs_version=0.4.1-081120161219 und der aktuellen 06.83 (FB7490) brav abgearbeitet wird?

Falls ein geschultes Auge -neben PeterPawn- meinen Fehler sofort erkennt, ohne mich wieder in die Ringbuf-Chose einlesen zu müssen und Protokolle gefordert werden? ... Eine Fehlermeldung im Ablauf erkenne ich ja nicht, ausser dass o.g. Script "übergangen wird"

LG+Many TX
 
Flags und eine eventuell vorhandene "custom_modscripts" überprüfen.
 
Danke, das Problem lag wieder einmal vor dem Bildschirm :blonk:Ich hatte im falschen Verzeichnis geschaut.
Sorry+LG
 
7362SL Update 6.30 -> 6.83 schlägt fehl

Hallo zusammen.

Zunächst: Vielen Dank an alle hier Aktiven - insbesondere PeterPawn - für die viele Arbeit und und die tollen Ergebnisse.
Auf meiner 7490 läuft 6.83 mit modfs. Super!
Aber leider bekomme ich das Update auf einer 7362SL auf dias aktuelle FRITZ!OS 6.83 nicht hin.
Ich habe 2 Partitionen in denen jeweils 6.30 incl modfs installiert ist. Das Update schlägt fehl mit der Meldung

"Extrahieren des Wurzeldateisystems aus dem Flash-Filesystem ... Fehler"

Ich habe mal ein debug log erstellt. Nur kann ich es nicht anhängen.
Vielleicht kann mir jemand kurz sagen, wie das geht? Bin ich wohl zu blöd für.

Vielleicht liegt das Update Problem auch daran, dass 6.83 einen neueres Squashfs nutzt als 6.30.
Sicherheitshalber habe ich (unter zuhilfenahme von NOVERIFY=1) in meiner 7490 ain Squashfs filesystem auf Basis der aktuellenm Firmware für die 7362SL erstellt.
Leider habe ich noch nicht verstanden, wie ich nun dieses filesystem in die 7362SL reinkriege.
Da muss dann ja, wenn ich es nicht falsch verstanden habe zuerst ein passender Kernel in die Standby Partition.
Im Thread von eisbärin habe ich das nachgelesen, bin aber nicht ganz schlau daraus geworden.

Was kann ich nun tun, um die 6.83 auf die Box zu bekommen (natürlich mit modfs)?

Vielen Dank
 
Zuletzt bearbeitet:
Eine 06.30 hat ja dann noch ein altes Dateisystem-Image mit SquashFS3 - das gab es auch schon länger nicht mehr als Aufgabenstellung. Irgendwie wird es wohl an der Erkennung des richtigen Dateisystems unter dem alten Kernel klemmen, wenn Du Dir sicher bist, daß es keine Platzprobleme gibt - bei der 7362SL mit weniger Hauptspeicher kann auch wieder das Problem des Swap-Space relevant werden, wobei das eher mit einem spontanen Reboot geahndet würde.

Wie man Dateien trotz bestehender Probleme anhängen kann (bei mir klappt es), ist irgendwo im IPPF auch beschrieben und ohne das Protokoll (am besten als ZIP-File eingepackt - entweder mit "gzip" oder halt mit Inhaltsverzeichnis im PKZIP-Format) ist es schwer, irgendwelche konkreten Tipps zu geben. Also wirst Du das mit dem Protokoll irgendwie hinkriegen müssen (und bitte nicht "inline", das Anhängen funktioniert - siehe Anhang).
 

Anhänge

  • modfs.gz
    23.2 KB · Aufrufe: 2
Danke für die schnelle Antwort.

Im erweiterten Editor clicke ich auf den Button "Anhänge verwalten" und dann erscheinz nur ein neues 'ausgegrautes' Fenster mit dieser URL: "http://www.ip-phone-forum.de/newattachment.php?do=assetmanager&values[t]=273304&contenttypeid=1&poststarttime=1493738027&posthash=19aca8f02bb4445dc420e15b3b14ef21&insertinline=1"
Kein Knopf, kein nix. Und da weiß ich nicht weiter.

@PeterPawn
Hatte meinen Beitrag noch erweitert. Schätze, dass die Version 6.30 noch ein altes Squashfs nutzt.
Hab mir dann mit der 7490 beholfen.
Speicher dürfte kein Problem sein. Da ist ein USB-Stick mit ext3 Partition und Swappartition dran.

Ha! Danke für den Suchtipp. Jetzt sollte das debug.log dran sein.
 

Anhänge

  • modfs.txt
    10.8 KB · Aufrufe: 5
Zuletzt bearbeitet:
Danke für die schnellen Antworten :p
 
die Funktion mount_ext2_image() liefert einen Fehler

Code:
2017-05-02 11:55:53.075 - mount_ext2_image: exiting, rc=255
..
2017-05-02 11:55:53.119 - extract_rootfs_from_wrapper: exiting, rc=40

das losetup liefert einen "ungünstigen" Returncode ;-)
Code:
mount_ext2_image()
SNIP
                $bb losetup -a >/dev/null 2>&1
                if [ $? -eq 0 ]; then
                        $bb losetup -r -f -o 256 $src 2>/dev/null
                        rc=$?

ggf. ist das Filesystem in Funktion detect_image_filesystem() nicht richtig erkannt worden
und in Folge war die Funktion mount_ext_image unzufrieden.
 
Zuletzt bearbeitet:
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.