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

@eisbaerin:
Ja.

PS: Ich kann also auch "kurz und schmerzvoll", wie man sieht.

Als erstes würde mich mal interessieren, ob denn nun "modfs-Starter" mit SIAB auf der 7412 funktioniert (habe gerade keinen Überblick, ob das schon mal jemand positiv getestet hat).

Wenn das funktioniert, kann man natürlich an die Stelle des Schreibens in die Partition für das Dateisystem das Kopieren auf NAS-Speicher bei der 7490 vornehmen lassen und dann mit der 7412 von dort abrufen ... mindestens FTP-Download sollte die 7412 auch beherrschen, wenn "ftpget" in der BB enthalten ist. Am Ende ist das ja nur das Kopieren der Image-Datei ... weit weniger "kompliziert" als das (NOR-)Flashen bei den älteren Boxen. Wenn das wirklich auf der Box selbst nicht möglich sein sollte ... so viel weniger Ressourcen als die anderen Modelle hat die ja eigentlich nicht, nur der fehlende USB-Anschluß macht es komplizierter, weil man irgendwie auf das Netzwerk und damit dann tatsächlich auf ein zweites Gerät - was auch eine 7490 sein kann, aber die haben sicherlich die wenigsten mit einer 7412 auch noch daneben stehen - zugreifen muß für temporäre Datenspeicherungen. Irgendwas mit "fuse" wird da schon am Ende funktionieren ... notfalls eben per SSH oder WebDAV oder FTP oder mit WLAN-Kabel (WLAN kann man ja aktivieren).
 
Zuletzt bearbeitet:
Wäre es so nicht auch auf einer FB7390 möglich? Also für die 7390 selber.
Eben ohne Installation, so daß nur das .image zum Schluß im NAND liegt.
Das lädt man herunter und macht dann ein normales Update.
So brauchst du den "komplizierten" NOR nicht anfassen.
Als Quelle natürlich auch ein .image.
 
Zuletzt bearbeitet:
Das Image bei der 7390 muß wieder anders zusammengebaut werden (Kernel + Filesystem in einem) ... auch wenn es Freetz letztlich genauso macht oder meinetwegen auch vormacht, bleibt das für mich (auch wegen der sukzessiven Abschaffung dieser Modelle bei mir) keine wirkliche Option.

Klar kann man mit einem passenden "Pseudo-Update" sogar wieder ein Firmware-Update von einem beliebigen direkt im NAND-FS (also unterhalb von /var/media/ftp) abgelegten Image ausführen (muß man halt ins tmpfs schaffen, habe ich sogar mal gebaut mit Auswahl eines Images aus mehreren dort abgelegten) - aber die Vorbereitungsarbeiten bleiben trotzdem.

Bei den NAND-Modellen macht das für mich auch nur deshalb Sinn, weil es eben (schon heute und künftig zunehmend) Leute gibt, die gar keinen PC (ob mit Windows oder Linux) mehr haben. Die werden dann aber nicht mit alten FRITZ!Boxen starten ... und wer eine alte FRITZ!Box hat, hat auch einen PC (oder kennt jemanden, der einen hat :mrgreen:) und dann ist Freetz (bzw. genauer fwmod, denn Freetz muß man ja nicht nehmen) wieder das einfachere Werkzeug.

Aber die Anpassungen bei "modfs", damit das eben nicht sofort in die andere Partition geschafft wird, sind wirklich minimal ... ansonsten braucht es noch die andere Variante der SquashFS-Tools für Version 3 mit LZMA-Kompression, ist aber auch kein Problem. EDIT: Ich hatte glaube ich sogar mal eine Variante von unsquashfs in einem Freetz-Ticket, die ohne das Aufteilen der einen Image-Datei in den Kernel und das Dateisystem beim Entpacken auskam, damit da nicht der doppelte Platzverbrauch im tmpfs beim Umpacken entsteht, wenn man erst das SquashFS-Image vom Kernel trennen muß - das Zusammensetzen (bzw. das Überschreiben des Dateisystems) nach dem Packen ging dann auch direkt mit "dd" wieder ganz gut, deshalb brauchte es keine gesonderte Variante beim Packen, wo man den Kernel gleich noch vor dem Dateisystem ausgibt bzw. man braucht den vorhandenen Kernel im Flash gar nicht erst zu überschreiben, wenn der zum neuen Dateisystem paßt und kann sich auf das SquashFS-Image beschränken.

Ich will mir bloß die Probleme nicht antun, die ggf. bei den NOR-Boxen auch auftreten können (wie bei den NAND-Boxen hier ja nachzulesen) und dort dann aber fast zwangsläufig zu Recovery führen würden. Das macht ggf. dann auch den "Ruf" von modfs unnötig kaputt und dafür reichen dann schon 5-10 User, die negative Erfahrungen damit machen (auch wenn es am Ende vielleicht nicht einmal am modfs liegt), damit es da "schlechte Presse" gibt und die Leute eher vor der Verwendung zurückschrecken als sich darauf einzulassen. Das, was bei den NAND-Boxen noch mit einer ordentlichen "Fehlermeldung" im Terminal endet und dann die Box noch gar nicht verändert hat, ist ab einem bestimmten Punkt bei den NOR-Modellen nicht mehr umkehrbar.

Auf der anderen Seite habe ich auch etwas "Angst", daß es dann mehr Leute gibt, die ihre NOR-Boxen so behandeln, daß diese nicht mehr richtig starten und sich mit dem Problem dann an AVM wenden anstatt an uns hier. Daher sehe ich die älteren Modelle wie die 7270v-irgendwas wieder unkritischer als eine 7390 (dabei fehlt dort wieder der NAND-Flash an sich), weil die mittlerweile aus der fünfjährigen AVM-Garantie (weitestgehend) herausfallen dürften, was bei der 7390 noch lange dauern wird. Wenn die "Hemmschwelle" des Nicht-Verstehens, was da eigentlich passiert, so weit sinkt, daß sich das am Ende jeder zutraut, der noch nicht einmal ein ordentliches Recovery hinbekommt (angefangen bei der "Security-Suite" auf dem PC), dann steigt m.E. die Anzahl der "kaputten" Boxen ... hier hat eben Freetz mit der recht hohen Hürde beim Einstieg (sowohl was Kenntnisse/Fertigkeiten als auch Zeitaufwand angeht) eine dämpfende Wirkung auf allzu enthusiastische "Spielkinder". Bei den NAND-Modellen kann man wieder weniger "kaputt machen" bzw. es schneller/einfacher reparieren.

Zwar ist die Zerlegung in zwei Teilschritte (s. Dein Vorschlag) tatsächlich denkbar, aber ich habe auch keine "Angst" vorm Flashen oder finde das wirklich "kompliziert" (es braucht nur einen Dateinamen, eine Startadresse und eine Längenangabe, wenn man will noch eine passende CRC-Summe am Ende, wobei selbst die nicht sein muß und schon kann man einen Kernel-Treiber laden, der das ins Flash schreibt und die Box dann neu startet). Es ist halt etwas zu rechnen für die Größen und Startadressen beim Flashen, aber das ist auch nur ein sekundäres Problem.

Der entscheidende Punkt ist nach wie vor (auch bei dem, was ich selbst bei der 7390 regelmäßig ändere, das läuft i.d.R. auf das leicht abgewandelte Aktivieren von "YourFritz" (hier halt im NAND-FS abgelegt anstelle von /wrapper/custom) über die Hooks wie bei der 7490 hinaus, habe ich weiter vorne mal angetextet als es um YourFritz als Framework ging), daß es auf den NOR-Modellen echt eng zugeht und da ohnehin nur minimale Skript-Änderungen ohne das Hinzufügen irgendwelcher Binärdateien sinnvoll sind (allerdings kann man den Standard-Inhalt für den NAND-Flash entsorgen, das schafft ein wenig Platz). Aber schon das Ersetzen der Busybox durch eine besser ausgestattete wird ohne das Entfernen anderer Teile zu einer diffizilen Angelegenheit, je nachdem, wie es um den freien Platz bestellt ist.

Allerdings würde natürlich das Reaktivieren von Telnet funktionieren oder das Starten von Kommandos aus der rc.user oder das Hinzufügen des alten nmbd ... aber wer das einmal unter Linux mit einer angepaßten "fwmod_custom" fertig präpariert hat, der braucht das genau ein einziges Mal pro neuer Firmware-Version. Alles andere, was man bei den NAND-Modellen so machen kann mit iterativen Änderungen oder dem schnellen Wechsel zwischen zwei Versionen, fällt dort ohnehin flach ... das macht es in meinen Augen so uninteressant. Es ist natürlich kein Problem, ein Paket aus ein paar Skripten und den notwendigen Binaries für x86-Rechner zu schnüren, mit dem man auch ohne komplette Freetz-Toolchain die Skripte einer AVM-Firmware bei NOR-Boxen ändern kann ... aber auch im Freetz-Projekt steht diese Idee irgendwo auf den hinteren ToDo-Plätzen, weil es wohl keinen Bedarf gibt oder man ihn nicht "befriedigen" will. Die Leute mit dem Bedarf an "kleinen Änderungen" sind halt dort nicht das richtige Publikum ...

Daß ich selbst auch nicht allzu viel von Telnet-Zugriff halte (selbst im LAN), ist ja kein großes Geheimnis ... daß man es trotzdem auch mit den von mir bereitgestellten "Werkzeugen" wieder aktivieren kann, liegt am Ende nur daran, daß es eben der entscheidende Punkt ist, den die meisten von früher her kennen und den sie wieder haben wollen. Schon die SIAB-Installation "verträgt" sich wieder besser mit meinem Sicherheitsverständnis in Bezug auf den Zugriff auf das Gerät ... dafür "beißt" sie sich mit meinem Verständnis zur Verwendung von fremden Binärdateien. Da den schmalen Grat zu treffen, ist nicht so einfach - das muß ich mit der Einbeziehung von NOR-Modellen in meine Überlegungen nicht noch weiter verkomplizieren.

Von der Idee für die NOR-Boxen (vor > 1 Jahr war das wirklich noch auf dem Zettel) bin ich eigentlich wirklich weg ...
 
Zuletzt bearbeitet:
http://yourfritz.de/modfs-0.3.1.tgz & Danke !

Funktioniert einwandfrei auf FB 7490 , intl. FW 06.36 beta, trotz vorgerigem ohne/mit "prepare_fwupgrade start_tr069" gab's beim ersten Starten des scripts zwar eine Fehlermeldung (bei "Vergleich der Systeme in den Kernel Partitionen ... Fehler), neustart gemacht, script erneut aufgerufen (erstmal "prepare_fwupgrade start_tr069" und dann komplett "mkdir -p /var/mod;cd /var/mod;wget -qO- http://yourfritz.de/modfs-0.3.1.tgz | gunzip -c | tar x;./modfs"), dann fehlerfrei durchgelaufen, manueller Neustart.
Aktivierung/Deaktivierung von telnetd über die Wählhilfe (#96*7* bzw #96*8*) funktioniert (endlich, nach früheren sonstigen Versuchen und Fehlschlägen) EINWANDFREI.
Die vorher installierte starter-fs4 (mit terminal auf port :8010) funktioniert auch weiterhin, ebenso einwandfrei.
Nochmals Danke @PeterPawn
 
@coco722:
Ich würde es zwar nicht so drastisch formulieren, aber etwas Lesen schadet sicherlich wirklich nicht und wenn Du einfach noch einmal nachdenkst und Dir die Frage stellst, warum die Möglichkeit zur Auswahl des zu startenden Systems denn in beiden Partitionen enthalten sein soll, wenn Du doch mittels "modfs" nur eine der beiden geändert hast, dann kommst Du sicherlich auch selbst auf die Lösung.

Wenn Du diese Auswahl in beiden Systemen haben willst, mußt Du eben auch beide Systeme modifizieren oder einfach das bereits modifizierte System noch einmal in die alternativen Partitionen kopieren lassen ... das erledigt "modfs" m.W. von alleine, wenn man es aus dem modifizierten System heraus ohne Parameter aufruft. Dann hat man eben zwei (identische) modifizierte Versionen in der FRITZ!Box.

Auch die Bitte, Deinen Beitrag im "Anleitungsthread" zu "modfs-Starter" wieder zu löschen, erneuere ich gerne noch einmal ... dort hätte ich es (wenn ich es mir aussuchen darf) gerne etwas "aufgeräumter", das ermöglicht späteren "Einsteigern" in die Thematik das Lesen der Anleitung, ohne daß sie dabei mit (für sie selbst) irrelevanten Fragen "belästigt" werden. Du fändest es sicherlich auch schwerer, Dich durch einen Thread mit 10 Seiten arbeiten zu müssen, um die "Anleitung" in vollem Umfang gelesen zu haben, weil da andere Beiträge dazwischen stehen.
 
Und bis zum Profi ist es ein langer steiniger Weg, voller Irrtümer und auch mit somanchen "dummen" Fragen. Standes du nicht auch irgendwann mal am Anfang ?
Das bestreitet auch niemand und trotzdem hast Du ja offensichtlich schon zu dem Zeitpunkt, als Du die Frage im anderen Thread gestellt hast, den allerersten Beitrag in diesem Thread entweder sehr selektiv gelesen oder ihn nicht verstanden. Der letzte Absatz dort steht von Beginn an in diesem Beitrag, weil ich aus dem Thread zu "modfs" gelernt hatte.

Gelsen habe ich durchaus so Einiges... und bin davon ausgegangen, dass man zwischen den beiden Systemen hin- und her wechseln könnte. Daher hatte ich auch einen Neustart auf das ursprüngliche System gemacht und mich gewundert, dass danach das modifizierte nicht mehr erreichbar ist/war.[...]und konnte das vorhin nicht wissen
Auch das zeigt aber - ob Du mir das nun übel nimmst oder nicht -, daß Du den modfs-Thread dann eben doch nicht ganz gelesen hast, denn die Arbeitsweise mit dem (prophylaktischen) Kopieren des Systems, damit in beiden Partition-Sets eine identische Version steht, ist seit der allerersten Version schon enthalten gewesen (der Link zu diesem alten Thread steht auch im ersten Beitrag dieses Threads) und auch hier in #1 noch einmal (zumindest indirekt) in folgendem Text zum Ausdruck gebracht:
PeterPawn schrieb:
Es besteht jetzt auch die Möglichkeit, mit "modfs" anstelle des GUI der FRITZ!Box ein Update mit gleichzeitiger Integration der eigenen Änderungen zu machen bzw. auch Labor-Versionen auf diese Weise zu installlieren, ohne daß in beiden Partitionen-Sets dasselbe System vorhanden sein muß. Damit bleibt ein Rückweg zur letzten Version offen ... genaueres dazu findet sich in #72 in diesem Thread.
Erst seit dem Beitrag #72 in diesem Thread kann das modfs-Skript überhaupt im "update"-Modus arbeiten und das steht eben auch schon in #1, womit die schiere Länge dieses Threads auch nicht mehr als Begründung für "Nichtkenntnis" herhalten kann.

Auch die Frage, warum bei nur einem modifizierten System das "Boot-Menü" nicht funktioniert und was man stattdessen machen könnte, hatten wir schon in diesem Thread - allerdings das tatsächlich "etwas versteckt", wobei das innerhalb derselben Seite wie #72 auftauchen sollte, solange man das Forum in der standardmäßigen Anzahl der Beiträge pro Seite liest.

Auch wenn ich die Ausdrucksweise der eisbaerin in diesem Falle nicht nachvollziehen kann ... die (für mich) dort auch zum Ausdruck gebrachte Kritik, daß da jemand an die Stelle des eigenen Lesens eher das Schreiben neuer Fragen setzt, kann ich nachvollziehen und insofern bleibe ich bei meiner Aussage in #407.

Ich kenne die eisbaerin jetzt auch nicht als allzu emotional, insofern muß ich einfach mutmaßen, daß es andere/weitere Gründe für die (auch für mich etwas zu heftige, aber sicherlich bei Nachfrage auch erklärbare oder entsprechend zurückgenommene) Reaktion geben wird.

Daß man eine (offensichtlich aus der Faulheit geborene) Frage (wie z.B. die nach der Änderung der /etc/init.d/rc.custom in einem - per Definition nur read-only verwendbaren - Dateisystem-Image) auch ignorieren kann, ist mir durchaus bewußt ... das hindert einige Leute dann trotzdem nicht daran, die ignorierte Frage in anderen Threads einfach noch einmal zu wiederholen und sich dann darüber zu mockieren, daß in dem ersten Thread ihnen niemand antwortete.

Ich hoffe, Du gehörst nicht ebenfalls in diese Kategorie und ich bin mir sicher, daß Du auf wohlbegründete Fragen auch weiterhin hier fundierte Antworten erhalten wirst.

Aber "ohne Fleiß kein Preis" (um ein anderes Sprichwort meinerseits zu zitieren) und die Einarbeitung in die Materie kann und wird Dir niemand abnehmen.

Wenn man dann die entstehenden Fragen erst einmal nur für sich selbst notiert und sie erst dann an die Allgemeinheit richtet, wenn sie nach dem Abschluß der Lektüre auch noch weiterhin bestehen, ist das sicherlich auch eine erprobte Vorgehensweise.

Man kann natürlich auch eigene Gedanken (die nicht zwangsläufig richtig sein müssen, der Irrtum gehört zum Erkenntnisgewinn dazu) zur Diskussion stellen, das ist dann aber etwas anderes, als bereits anderswo beantwortete Fragen immer wieder aufs Neue (ad nauseam) zu stellen.
 
...
Funktioniert einwandfrei auf FB 7490 , intl. FW 06.36 beta,...

Habe ich irgendwann etw. verpasst zwecks beta...international?

Ich frage einfach deshalb, da m.W. das Flashen einer DE<->INTERNATIONAL (AT-CH ...) -FW eines entsprechenden Brandings (AVME<-> AVM/1und1 o.ä.) bedarf?

Ob 2 FWs für unterschiedliche Brandings über modfs machbar? Ich stelle dies nurmal als freundliche Frage bzgl. Machbarkeit hier ein.

Hintergrund: Einige User in AT CH Belgien usw. ... in typischen Annex A -Ländern halt ... wären sicherlich interessiert an einem Multiboot-System? um die DE-Laborreihe mitzunehmen? Bekanntermassen dauert es eher ewig, bis mal ein Release-Update im INTERNATIONAL-Zweig auftaucht?

LG
 
Moinsen


Das Ändern des Brandings vor dem Umschalten ist, auf Kommandoebene und/oder aus Skript, schnell erledigt.
 
@Micha0815
Original ist es eine Internationale FB 7490 (Schweiz)...das Ändern des originalen AVME ist grundsätzlich relativ einfach (kann ich gerne genauer beschreiben auf Anfrage)...Ich hab nur das provider Environment gelöscht, um problemlos AVM recovery's ausführen zu können (was vorher blockiert war)...die Box unterstützt nun richtigen Wechsel zw. Annex A und/oder Annex B. Ein Umflashen auf DE Firmware habe ich (noch) nicht getestet, da intl. 6.36 quasi der deutschen 6.50 entspricht (vom Kernel 3.10 her) und auch einwandfrei läuft (trotz Beta 1 Status), ich wollte eh nur den neueren/höheren Kernel haben...
 
Moinsen
Das Ändern des Brandings vor dem Umschalten ist, auf Kommandoebene und/oder aus Skript, schnell erledigt.

Hi, die Möglichkeiten auf Kommandoebene würden mich interessieren (ich kenne nur das über ftp im bootloader/adam2)
 
Danke @tuxedonet, den Beitrag hatte ich wohl überlesen, da dortens eher von "Zwischen-Updates" über eher mysteriöse Updateserver seitens AVM was rüberkommt ;) was dem gemeinen Fussvolk verwehrt bleibt :D

Offizielle Betas ... wo sich z.T. drum gestritten wird, wer als "Erster entdeckt" ... suche ich eigentlich via Abo eher unter

http://www.ip-phone-forum.de/forumdisplay.php?f=458

Dass dort kein eigenes Thema/Thread ... wiedermal was dazugelernt ;)

LG

Nachtrag:

Moinsen


Das Ändern des Brandings vor dem Umschalten ist, auf Kommandoebene und/oder aus Skript, schnell erledigt.

Verstehe ich das richtig? Bevor ich im laufenden System (AVM-Branding-FW mit modfs) einen Neustart auf das alternative System (AVME-Branding-FW gleichfalls ge-modfs-ed) anstosse, muss das Branding vor dem reboot/Wechsel vonHand geändert werden? Kann ein Script das so früh im Wechsel/Reboot als rc-custom o.ä. hinbekommen? Sorry, wenn ich das als blutiger Anfänger nicht hinreichend durchschaue ;)
 
Zuletzt bearbeitet:
@PeterPawn
wie im LCR-Thread empfohlen, stelle ich hier mal die Frage.
Ausgangspunkt ist eine 7490, die unter der Firmware 6.50 mit dem modfs-Starter telnetfähig gemacht und mittels modfs auf die 6.51 geupdatet wurde (das anschließende manuelle Einspielen über Telnet und Konfigurieren des LCR von Harald Becker klappte und klappt weiterhin prima).
Allerdings ist die Shell unter der 6.51 nicht mehr erreichbar (http://192.168.178.1:8010 klappt nicht mehr), so dass ich mich sehr freuen würde, wenn ich modfs wieder aktivieren könnte, ohne ein recover auf die 6.50 machen zu müssen.
Dann könnte ich nämlich unter der Shell versuchen, mit edit_rcuser den LCR (unter der 6.51) resetfest einzubinden.
Hast Du eine Idee / Tips?
 
Zuletzt bearbeitet:
Das geht - immer davon ausgegangen, daß nach wie vor der Telnet-Zugriff funktioniert, denn den kann man ja beim Update mit "modfs" direkt einrichten lassen - mit folgenden Kommandos:

1. Download der passenden Version von "modfs-Starter" von meinem Server, hier wäre für die 06.51 ja dann die SquashFS4-basierte Version die richtige.
Code:
# [COLOR="#008000"]mkdir /var/mod[/COLOR]
# [COLOR="#008000"]cd /var/mod[/COLOR]
# [COLOR="#008000"]wget http://yourfritz.de/inject_shellinabox_vr9_nand_sqfs4.tar[/COLOR]
Connecting to yourfritz.de (85.214.20.177:80)
inject_shellinabox_v 100% |****************************************************|   527k  0:00:00 ETA

2. Entpacken des tar-Archivs, weil wir nur das dort enthaltene "filesystem.image" brauchen .. hier benennen wir es der Einfachheit halber gleich noch um beim Entpacken.
Code:
# [COLOR="#008000"]tar -x -f inject_shellinabox_vr9_nand_sqfs4.tar -O ./var/tmp/filesystem.image >filesystem_custom.squashfs[/COLOR]
# # kurze Kontrolle
# [COLOR="#008000"]mkdir /var/test;mount -t squashfs filesystem_custom.squashfs /var/test[/COLOR]
# [COLOR="#008000"]find /var/test[/COLOR]
/var/test
/var/test/bin
/var/test/bin/busybox
/var/test/etc
/var/test/etc/init.d
/var/test/etc/init.d/rc.custom
/var/test/lib
/var/test/lib/libprivatekeypassword.so
/var/test/usr
/var/test/usr/bin
/var/test/usr/bin/privatekeypassword
/var/test/usr/bin/shellinaboxd
# [COLOR="#006400"]umount /var/test[/COLOR]
# # aufräumen
# [COLOR="#008000"]rm -r /var/test inject_shellinabox_vr9_nand_sqfs4.tar[/COLOR]

3. Laden des "update_yaffs2"-Skripts vom Server - das ginge auch aus dem GitHub-Repository, aber die FRITZ!Box kann da nicht direkt drauf zugreifen
Code:
# [COLOR="#008000"]wget http://yourfritz.de/update_yaffs2[/COLOR]
Connecting to yourfritz.de (85.214.20.177:80)
update_yaffs2        100% |******************| 11023   0:00:00 ETA

4. Jetzt brauchen wir das Skript eigentlich nur noch ausführen, solange in der wrapper-Partition noch keine Datei "filesystem_custom.squashfs" enthalten ist ... ansonsten müßte man noch einige weitere Vorbereitungsarbeiten erledigen, besonders dann, wenn man eine in Benutzung befindliche Datei ersetzen will - da ist es manchmal sogar einfacher, die alte mit dem Aufruf von "/wrapper/remove_custom.sh" erst einmal beim nächsten Reboot entfernen zu lassen und dann die neue in eine "blanke" Installation einzubauen.
Code:
# [COLOR="#008000"]sh update_yaffs2 filesystem_custom.squashfs[/COLOR]
# # auch hier eine kurze Kontrolle, wenn alles glatt gegangen ist, sollte es jetzt eine "filesystem_custom.squashfs" unter /wrapper geben und die /wrapper/sbin/flash_update sollte so oder so ähnlich aussehen
# [COLOR="#006400"]ls -l /wrapper[/COLOR]
drwx------    1 root     root          2048 Feb  5 00:55 bin
drwx------    1 root     root          2048 Feb  3 16:37 core
drwxr-xr-x   10 root     root         14300 Feb 13 05:34 dev
drwx------    1 root     root          2048 Feb  5 00:55 etc
-rw-r-----    1 root     root      22474752 Feb  5 00:55 filesystem_core.squashfs
[COLOR="#0000CD"]-rw-r--r--    1 root     root        532480 Feb 13 10:41 filesystem_custom.squashfs[/COLOR]
drwx------    1 root     root          2048 Feb  5 00:55 lib
drwx------    1 root     root          2048 Jan  1  1970 lost+found
drwx------    1 root     root          2048 Feb  3 16:37 proc
[COLOR="#0000CD"]-rwxr--r--    1 root     root           140 Feb 13 10:58 remove_custom.sh[/COLOR]
drwxr-xr-x    1 root     root          2048 Feb 13 10:53 saved
drwx------    1 root     root          2048 Feb  5 00:55 sbin
drwx------    1 root     root          2048 Feb  5 00:55 tmp
drwx------    1 root     root          2048 Feb  3 16:37 var
# [COLOR="#006400"]cat /wrapper/sbin/flash_update[/COLOR]
[COLOR="#800000"]#! /bin/sh
#
# version for kernel 3.10.73 - AVM firmware 06.50+ (assumption only)
#
# create a shell script to be called from a detached shell
# only /dev is writable here, it's very early after kernel was loaded
#
cat >/dev/delayed_start.sh <<'EOT'
#
# let the OS settle a bit
#
sleep 5
#
# wait until tmpfs is mounted on /var
#
while true; do
                                grep -q "^tmpfs /var tmpfs" /proc/mounts 2>/dev/null && break
        sleep 2
done
#
# check for "uninstall" request
# wait until start has finished in this case, we'll use the running "run_clock"
# as "decision helper"
#
if [ -f /wrapper/remove_custom.flag ]; then
        while true; do
                pidof run_clock >/dev/null 2>&1 && break
        done
        mount -o remount,rw /wrapper
        rm /wrapper/remove_custom.flag
        rm /wrapper/remove_custom.sh
        rm /wrapper/filesystem_custom.squashfs
        echo "exit 0" >/wrapper/sbin/flash_update
        sync
        mount -o remount,ro /wrapper
        exit 0                                                                                                                                                                                                                              ]
fi
#
# mount our additional SquashFS image to /var/custom
#
mkdir -p /var/custom
mount -t squashfs /wrapper/filesystem_custom.squashfs /var/custom
grep -q "^/dev/loop[0-9] /var/custom squashfs" /proc/mounts || exit 1
#
# wait until lan device was started
#
while true; do
        ifconfig lan 2>/dev/null | grep -q ".*UP.*RUNNING.*" && break
        sleep 2
done
#
# start the init script (etc/init.d/rc.custom) of the mounted extension
#
export CUSTOM=custom
nohup sh -x /var/custom/etc/init.d/rc.custom >/var/tmp/rc.custom.log 2>&1 &
EOT
#
# start a detached shell to execute the created script, we've to exit here
# to let the init process continue
#
nohup sh -x /dev/delayed_start.sh >/dev/delayed_start.out 2>&1 &
exit 0
[/COLOR]

Das war es dann eigentlich schon (die Arbeit macht am Ende das "update_yaffs2" für uns) und nach dem nächsten Neustart der Box sollte dann neben den Änderungen durch "modfs" auch wieder das ShellInABox unter dem Port 8010 mit erzwungener TLS-Verschlüsselung zur Verfügung stehen.

Natürlich kann man auch jedes andere eigene Image auf diesem Weg einbauen lassen, man muß sich halt ein passendes Start-Skript für alle dort enthaltenen Erweiterungen unter etc/init.d/rc.custom in sein Image packen und dann sind der eigenen Phantasie eigentlich wieder keine Grenzen gesetzt.

Wobei ich den Kontext von @handymaxe trotzdem nicht vollkommen verstehen ... man braucht SIAB, um "edit_rcuser" aufzurufen? Warum geht das nicht über eine Telnet-Session? Wenn der Dienst nicht gestartet wird, braucht es vielleicht nur den passenden Telefon-Code ... immer unter der Voraussetzung, daß man den Telnet-Daemon beim Update mit "modfs" auch hat einbauen lassen.

Hat man keinen Telnet-Zugriff auf die FRITZ!Box wegen des "normalen" Updates auf die 06.51, kann man sich immer noch helfen (Aufwand in der Ausführung ca. 10 Minuten, das Lesen und Verstehen (einmal reicht aber eben auch, dann kann man das beliebig oft wiederholen) dürfte beim ungeübten Leser etwas länger dauern als die Ausführung.

Aber ehe ich (persönlich) zum Recovery-Programm greife (mit der Konsequenz der "Vernichtung" der vorhandenen Konfiguration, was eigentlich unnötig ist, solange man das nicht ohnehin aus Gründen der Gewissenhaftigkeit ab und an mal machen will) und den steinigen Weg über die 06.50 gehe (da ist dann eben auch noch der zusätzliche Neustart nach dem Einspielen der geretteten Einstellungen in den Aufwand einzurechnen und die Kontrolle, ob alles andere richtig importiert wurde, angefangen bei den Netzwerk-Clients und auch die event. noch vorhandenen AB-Nachrichten und Faxe sind dann ohnehin erst einmal weg) ... da würde ich eher den kleinen Umweg über das Schreiben einer solchen Image-Datei aus einem per EVA in den Speicher geladenen System wählen, wie ich ihn im oben verlinkten Thread zum "update_yaffs2" versucht habe zu erklären.

Da ich das Grundgerüst eben ohnehin immer greifbar habe, ist das auch im Handumdrehen erledigt und zur Aktivierung des neuen Zusatz-Images brauchen die meisten ohnehin einen Neustart (auch wenn man es theoretisch von Hand machen könnte) und dann kann man im Rahmen dieses "ohnehin"-Neustarts auch gleich die Modifikationen ausführen lassen.

Dieses erwähnte "Grundgerüst" hat aber jeder, der die bei "update_yaffs2" beschriebenen Schritte nachvollzieht, dann auch, so daß man die ersten Schritte tatsächlich nur einmal ausführen muß. Deshalb habe ich auch extra das Update einer 06.5x-Version mittels einer älteren Version beschrieben, damit da von Beginn an klar ist, daß das zwei verschiedene Probleme sind und man keineswegs für das nächste Release von FRITZ!OS zwingend wieder von vorne beginnen muß mit dem Erstellen eines "stand-alone"-Images (solange AVM die Vorgehensweise nicht komplett ändert, was ich nicht in allzu naher Zukunft kommen sehe).
 
Zuletzt bearbeitet:
Bevor ich im laufenden System (AVM-Branding-FW mit modfs) einen Neustart auf das alternative System (AVME-Branding-FW gleichfalls ge-modfs-ed) anstosse, muss das Branding vor dem reboot/Wechsel vonHand geändert werden? Kann ein Script das so früh im Wechsel/Reboot als rc-custom o.ä. hinbekommen?
Da ich auch ab und an mal zwischen der internationalen und der deutschen Version pendele auf einigen Boxen und dann selbst immer wieder vergesse, das Branding zu ändern - was am Ende in einem Boot-Loop endet, wo man aus der Ferne dann auch gekniffen ist ... daher hatte mir zwischenzeitlich den BootManager im GUI schon entsprechend erweitert (den brauche ich ja auch für den Fernzugriff bei der Umschaltung, da nutzt die Kommandozeilenversion nicht so sehr viel), so daß der bei der Umschaltung auch automatisch das Branding passend setzt oder das zumindest setzen könnte.

Da der aber auch das GUI benutzt (logisch), waren da einige kleinere Korrekturen für den Einsatz ab 06.50 (bzw. ab dem "responsive design", wo dann die Ereignisbehandlung im JS wieder etwas anders abläuft) erforderlich ... aber nach dem "Umzug" von "modfs" in ein eigenes GitHub-Repository wird es hoffentlich in nicht allzu ferner Zukunft eine neue "modfs"-Version geben, die dann mehr auf die Boxen ab 06.5x abzielt und bei der dann das Branding auch gleich zusammen mit der Systemversion umgeschaltet wird, wenn das erforderlich oder erwünscht ist.

Wenn das soweit ist, mache ich ohnehin eine neue "modfs"-Version (0.3.2 o.s.ä.) daraus und das werde ich dann sicherlich auch hier im Thread publik machen.
 
@PeterPawn
vielen Dank für Deine umfangreichen Ausführungen.

Da habe ich wohl angesichts meiner mangelhaften Kenntnisse zu ungenau formuliert.

1. Telnet-Zugang besteht (auch nach dem modfs update auf die 6.51)
2. die shell ist nicht erreichbar
3. ich dachte, ich könnte "edit_rcuser" (und damit die resetfeste Installation des LCR) nur über die shell erreichen. Dass das auch über eine Telnet-Session (also in der Windows-Kommandozeile) geht, wusste ich nicht.
4. Zum Verständnis: wenn ich auch mit der auf die 6.51 folgenden AVM-Firmware Telnet haben/beibehalten möchte, muss das AVM-update über modfs eingespielt und das image mit modfs repacked werden. Korrekt ?
5. Deine Kommandos setzen Unix/Linux voraus. Da ich hier aber Windows XP habe, brauche ich die Shell oder eben ein Unix/Linux-System, um die Kommandos auf die Box zu bringen und damit modfs unter der 6.51 zu reaktivieren . Korrekt ?
6. Vermutlich wäre ein Recover (ich habe da noch ein 6.50-Backup mit allen Einstellungen) auf die 6.50 die beste (weil schnellere) Lösung, weil ich dann alles gleich einbinden kann, also LCR resetfest über "edit_rcuser" wie auch das Überleben von modfs nach dem update auf 6.51. Korrekt ? Wenn das so zutrifft, was muss ich dann in die Shell unter der 6.50 eingeben ?
Für den LCR ist es klar (den entsprechenden Installationsbefehl aus dem Harald-Script), aber für das Überleben von modfs nach dem update auf die 6.51 ? Wie oben von Dir dargestellt in die Shell eingeben ?
 
Zuletzt bearbeitet:
Was soll denn an "modfs" überleben?

Das ist doch nur ein Framework, mit dem Änderungen an der originalen Firmware vor dem erneuten Packen vorgenommen werden. Das einzige, was man mit viel gutem Willen noch als "modfs" in einem modifizierten System ansehen könnte, wäre der BootManager für die Umschaltung auf das andere System und vielleicht noch das "edit_rcuser"-Skript.

Aber eigentlich sind das alles einzelne (größtenteils auch unabhängige) Änderungen an der originalen Firmware und von "modfs" bleiben in so einem modifizierten System eigentlich keine Spuren zurück. Man muß halt nur - wie Du es ja offenbar auch verstanden hast - das Update auf die nächste Version gleich wieder mit "modfs" ausführen, weil dann eben gleich die benötigten Änderungen wieder in das neue System eingebaut werden können.

Das "modfs-Starter"-Thema ist da halt ein anderes ... das erfordert (bis 06.50) ja gar keine einzige Änderung (mit "modfs") an dem originalen Root-FS, weil es an einer anderen Stelle gespeichert wird und praktisch parallel zur originalen Firmware läuft. Das hat dann aber eben wieder den Nachteil, daß man es auch nach jedem Firmware-Update (egal auf welchem Weg, solange man das nicht auch noch von Hand macht) erneut in die entsprechende Partition schreiben muß, weil natürlich der normale Installationsprozess keine Rücksicht darauf nimmt, daß eine dort bereits vorhandene Erweiterung das Update überlebt.

Wenn man beim Update mit "modfs" jedenfalls die Wiederauferstehung des Telnet-Daemons (den kann man auch als Notnagel noch ganz gut gebrauchen, man sollte ihn halt nicht "regelmäßig" verwenden und da dann lieber SIAB oder SSH (dropbear) nehmen) in Auftrag gegeben hat, dann sollte bis inkl. 06.51 (weiter kann man ja noch nicht in die Zukunft schauen) auch der Telnet-Service wieder zur Verfügung stehen im aktualisierten System. Auch den kann man dann natürlich mit einem passenden Client (entweder dem eingebauten bei XP oder man nimmt PuTTY/KiTTY) benutzen ... aber das führt für meinen Geschmack jetzt schon wieder zu weit weg vom Thema - das ist für mich eben immer das Arbeiten auf der Box als Linux-System (weil nicht jeder sich eine VM mit Linux hinstellen will oder gar nur mit Linux arbeitet, auch auf dem Desktop) und dem widme ich mich bzw. auf diese Umgebung sind meine Lösungsvorschläge in der Regel ausgerichtet. Wie man dann auf diese Linux-Kommandozeile zugreift, ist eigentlich nicht (mehr) mein Thema.
 
@PeterPawn
OK, damit es für mich jetzt komplett verständlich wird:
1. Shell im Browser über modfs-Starter geht unter 6.51 deswegen nicht, weil die Box eben ab 6.51 nichts anderes als AVM-Original akzeptiert. Korrekt ?
2. für die Telnet-Funktionalität (und somit für den LCR) muss die AVM-Firmware mit modfs 'behandelt' werden (also download und repacking des AVM-Firmware-Updates mittels modfs) Korrekt ?
3. modfs läuft unter Linux (shell, vm, genuine, was auch immer) und nach dem Durchlaufen und Verändern von dem, was ich will, ist das Script eben durch und fertig. Also script und kein background-service. Korrekt ?
4. Will ich also nach dem unter 6.50 in der shell laufenden modfs-gesteuerten Update auf 6.51 (incl. Telnet/LCR-Funktionalität) erneut updaten und Telnet/LCR behalten, muss ich wie auch immer modfs update auf der Box zum Laufen kriegen (was jedenfalls ab 6.51 nicht mehr mit dem modfs-Starter klappt), also für Windows heisst das: Linux VM. Korrekt ?
Vielen 1000 Dank für Deine Geduld mit mir. Lernen klappt ohne Verstehen nicht wirklich. Und wenn ich alles verstanden habe, weiss ich, was ich tun muss bzw. ob meine Fähigkeiten dafür reichen.
 
Zuletzt bearbeitet:
@handymaxe:
Das sind nicht immer 100% richtige Antworten, wenn man da nur mit "ja" oder "nein" antworten soll.

1. ja
2. ja
3. ja - zumindest zu 95% richtig, je nachdem, wo man die "Grenze" von "modfs" zieht und für mich gehören die "modscripts" und die daraus entstehenden Dateien im laufenden System eigentlich nicht mehr zum "modfs" dazu
4. Das ist - soweit ich das verstanden habe - richtig, solange es um das "klassische" "modfs-Starter" geht, das über ein tar-Image direkt über das GUI der FRITZ!Box installiert werden konnte ... was ab 06.51 daran scheitert, daß keine unsignierte Firmware mehr für diesen Upload akzeptiert wird.

Wie man auch bei einer (mit modfs von der 06.50 aus erzeugten) 06.51 den "ShellInABox"-Service (und ich wäre Dir dankbar, wenn Du zwischen "shell" (das ist eine beliebige Kommandozeile, egal über welchen Weg) und "ShellInABox" (das ist die Kommandozeile in einem Javascript-fähigen Webbrowser) sauber unterscheiden würdest, sonst weiß kein Mensch, was Du da gerade mit "Shell" meinen könntest) wieder zum Leben erwecken kann mit sechs einfachen Kommandos auf der FRITZ!Box, habe ich ja gerade in #415 beschrieben ... da dafür ja auch das "modfs-Starter"-Image als Quelle für die SquashFS-Datei herhalten mußte, würde ich das jetzt nicht von "modfs-Starter" thematisch trennen wollen. Auf welchem Weg man jetzt die sechs Kommandos auf der FRITZ!Box ausführt, wenn man doch eine 06.51 mit aktiviertem Telnet-Service auf der Box hat ... das ist doch gar keine Frage. Warum sollte das denn nicht über jeden beliebigen Telnet-Client funktionieren? Im Extremfall geht das sogar mit dem Tablet oder Smartphone ... irgendwie verstehe ich da die Fragestellung gar nicht.

Das Image-File für "modfs-Starter" kann eben ab Version 06.51 nicht mehr per "Pseudo-Update" auf die Box gebracht werden ... aber es bleibt (nach meiner Lesart) weiterhin "modfs-Starter", weil ja auch der oben beschriebene Weg aus einer bereits zur Verfügung stehenden Shell (und hier ist das eben irgendein beliebiger Zugriff auf die Kommandozeile und nicht "ShellInABox" (SIAB), worüber ich rede) nur eine der beiden Möglichkeiten ist, wo man "update_yaffs2" einsetzen kann - das ist ja "dual use" und kann genauso gut auch in einem "stand-alone"-Image über EVA verwendet werden, um eine beliebige "custom extension" (und auch SIAB war ja nur ein (mehr oder weniger nützliches) Beispiel, was man mit solchen Erweiterungen anstellen könnte) in das System einzubauen ... ja, man kann sogar wählen, ob das in das gerade aktive oder in das inaktive System erfolgen soll.

Was Du jetzt unbedingt mit einer Linux-VM willst, verstehe ich also immer noch nicht ... mir drängt sich der Eindruck auf, daß Du #415 gar nicht oder sehr falsch verstanden hast - ich weiß aber auch beim besten Willen nicht mehr, was ich da noch anders/klarer erläutern sollte.
 
Zuletzt bearbeitet:
ich sag ja, bei mir fällt der Groschen mangels Erfahrung/Kenntnissen sehr spät, Entschuldigung.
ohje, logo, ich meinte mit shell immer SIAB.
Und dass ich, wenn ich Telnet unter Windows aufrufe, alles an Kommandos auf die Box bringen kann, was ich will, hab ich erst beim Lesen Deines letzten Posts geschnallt - peinlich für mich und ich versteh auch nicht wieso ich da so blind war. Ich hau mir grad selbst in die Fr****.

... und ...
@PeterPawn Du bist mein Held, alles per Telent-Zugang (über Windows-Kommandozeile) so gemacht wie Du geschrieben hast, nach Reboot gibt's jetzt SIAB und Zugang zur Box im Browser !!!!
Und jetzt werd ich mal den LCR resetfest machen...
also wiederholt ein ganz dickes Danke !

EDIT: erm, nach dem Aufruf "edit_rcuser" erscheint "eventadd 1 "Die Datei rc.user ...". Wie krieg ich denn da den Installationsaufruf für den LCR rein ?
 
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.