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

Hello again,
I finally proceeded with the latest modfs by using the telnet pseudo-firmware update, then enabling telnet with #96*7* and finally running:
Code:
mkdir -p /var/mod;cd /var/mod;wget -qO- http://yourfritz.de/7490/modfs.tgz | gunzip -c | tar x;./modfs update
I followed the new modfs script with "y" for all the options and got the final messages:
"The new root file system has been installed into the inactive Partition.
Your device will use the new system at next restart."

At the end I rebooted into the latest modded OS but I'm not able to activate telnet by dialing #96*7*
What am I missing? Do I need to edit rc.user file before rebooting the FritzBox by adding the following command?
Code:
ln -sf /bin/busybox /usr/sbin/telnetd

What is the correct way to get permanent telnet after modfs in OS 6.83? I prefer to ask here before risking doing some mistakes and wasting too much time in trials and errors.

Last but not least: I've read on various comments about Shellinabox. Could anybody please point me to some information about installing it to the FB?
...even in german will be fine, I'll try following the english online translation.

Cheers,
V.
 
Zuletzt bearbeitet:
After activating with code #96*7* reboot and try to telnet to the box.
This seems to be the right way.
...dont ask why.
:rolleyes:
 
I'm working on a new version for ShellInABox ... something like "modfs-Starter reloaded", where the user may choose, which shell access has to be installed. It will replace the old "shellinaboxd.squashfs" version on GitHub, too.

It works only on NAND-based VR9 boxes yet, using additions to the YAFFS2 partition - because GRX5 boxes don't have the YAFFS2 partition or any other - directly writable - place, they're not supported here.

The basis will be new scripts in 'toolbox style', usable to create an own image from AVM's original firmware.

For those model, which I own and use myself, pre-built "ready-to-use" images will be added to the 'first_aid' folder again.

Meanwhile I've checked-in (into the YourFritz/bin/mips folder) new versions of binaries, which I have used (and which I will use further in the "image-builder" scripts) for these images. These binaries were built 2 weeks ago, with current versions from a Freetz trunk to make them reproducible, if someone wants to compile them himself. They're all linked statically - to make them independent from libraries in the AVM firmware - and prepared during the build process to run from an additional file system structure mounted on /var/custom. To use any of those files, someone needs only to prepare the right structure on /var/custom (it could even be a "bind-mounted" structure from elsewhere, e.g. from /wrapper/foo/bar) and to expand (and export) the "PATH" variable, to take the additional directories into account while searching for executables.

And one more hint for the "telnetd" start ... if the daemon was successfully activated once, this setting will be store in "fx_conf" and it's unnecessary to activate it once again (or after each reboot). If the daemon gets deactivated (#96*8* - and this will still be confirmed with a message on a phone with a usable display - a running "telnetd" gets killed on deactivation), it's still possible to change the flag in "fx_conf" as often as wanted - but the daemon will not be started again. Only after the next reboot, the current state of this "telnetd flag" decides, whether the daemon will be started automatically or not. If it's deactivated at this time, it may be activated by #96*7* and it gets started - but as I wrote, only once. The position of this "telnetd flag" in "fx_conf" is known ... there are older posts (from myself, this may help searching them) regarding this theme.
 
Zuletzt bearbeitet:
Hallo,

Ich habe seit 2 Tagen krampfhaft versucht das Dualboot auf meiner Fritzbox 7490 einzurichten, nu bin ich mit meinem Latein am Ende.
Ich habe eine andere 7490 schon erfolgreich mit modfs bearbeitet...alles super.
Diese eine 7490 macht mich wahnsinnig ... egal wie ich es mache , es haut einfach nicht hin.
Ich habe auf die 06.50 mit recover image gedowngraded ... anschliessend mit shellinabox versucht z.b. die 06.83 mit modfs auf die zweite Partition der 7490 zu bringen...nichts zu machen... ich kann aber auch nicht mit der shellinabox von z.b. Partition 0 (echo linux_fs_start 1 > /proc/sys/urlader/environment) auf die Partition 1 umswitchen.
Es geht nur per FTP (adam2) aber die Box Bootet einfach nicht wenn mit modfs ein image eingespielt wird.
Nur die Power LED blinkt langsam vor sich hin.
Ich habe aber auch (vorher) vier oder fuenf mal ueber das WebID , ausgangspunkt 113.06.83 , eine neuere Laborfirmware versucht zu flashen , erst das sechste mal hats dann funktioniert.
Ich habe die Box mit 113.06.83 bekommen.
Langsam glaube ich das irgend etwas an der Box veraendert wurde so das es nicht mehr funktioniert mit modfs.
Oder die 7490 ist defekt , modfs hat auch diverse Fehler angezeigt,z.b. Dateisystem kann nicht erstellt werden oder die Box hat mich aus der Shell geworfen und ich durfte von vorne anfangen..... dazwischen hat die Box einfach Neugestartet.
Es sind aber 2 Partitionen vorhanden , da sind einmal die 06.50 drauf und einmal irgendwas was modfs erstellt hat.
Habe auch andere firmware konstellationen schon versucht...nada... nuescht geht.
Ich habe schon gefuehlte 100 Aktionen durch... keine ahnung was ich noch probieren koennte.
Ich kann mir nicht helfen aber irgendwie kommt es mir so vor als ob der Speicher vom NAS der 7490 einen Defekt hat.
Ich konnte auch die Dateien aus dem NAS der 7490 nicht mehr loeschen nachdem das modfs mal wieder mit Fehlermeldung abgebrochen hat.
Die 7490 kommt mir auch sehr Traege vor... viel langsamer als die andere 7490 die ich vorher hatte.
Achso...die Box ist zwar traege ... funktioniert aber soweit ich das beurteilen kann..falls ich nicht noch irgendwas defektes finde.

Vieleicht weis ja von euch einer noch einen Rat..ich waehre dankbar dafuer...

m.f.g.joto
 
Als ersten Tip wirdwohl Nachgefragt werden wegen Ringbuff ... kommen? Schaue erstmal nach, wie jung die Box (Serial) und welches Branding. Versuche auf beide Partitionen eine alte FW zu installieren z.B. die 6.50 unter demselben Branding und dann erst eine via MODFS. Mit dem aktuellen github ??? Nimm besser eine ältere Version und als FW was kleiner 6.80. Irgendwie sich damit hochgehangelt geht ... neu aufgesetzt macht Probs?
LG und ich bin eher kleiner unbedarfter User

EDIT: Ich vergass, dass ich stets via ./modfs update "firmware-file-auf-ftp-speicher" vorgehe
 
Zuletzt bearbeitet:
Es geht nur per FTP (adam2) aber die Box Bootet einfach nicht wenn mit modfs ein image eingespielt wird.

wie Micha0815 schreibt, es fehlt der die Protokolldatei "showshringbuf modfs"
bitte als Anhang beifügen.
 
Hi,
Es ist eine original AVM rote Box.
Baujahr xxxxxxx...noch nicht so alt wie es scheint.
Ich habe immer ueber das Nas der Box versucht upzudaten,image lag im NAS der Box.
Das mit der Protokolldatei "showshringbuf modfs" muss ich mal schauen wie das funzt..bin nicht so der Profi..bin ganz am anfang.
m.f.g.joto"
 

Anhänge

  • modfs.txt
    36.7 KB · Aufrufe: 6
Zuletzt bearbeitet:
Ich würde erst einmal sicherstellen, daß die Box mit aktueller AVM-Firmware in beiden Partitionen sauber arbeitet ... also zunächst mal ein Recovery auf die 06.83 und dann aus dieser Version heraus (Werkseinstellungen sind dann ja automatisch geladen nach Recovery und bleiben auch erst einmal so) ein Update auf irgendeine spätere (Labor-)Version (mit Datei-Upload) ausführen.

Erst wenn das beides sauber durchläuft und in den Support-Daten der späteren Version beim Starten nicht ungewöhnliche Einträge für den NAND-Flash auftauchen, dann macht es Sinn, da weiter zu probieren. Liegt tatsächlich ein Schaden im NAND-Speicher vor, findet das System den auch beim Start und protokolliert ihn.

So vom Lesen her habe ich eher das Gefühl, daß da die Box unter "memory stress" gerät ... zumindest klingen spontane Reboots eher danach als nach etwas anderem. Ob hier ein USB-Stick benutzt wird, kann ich nicht erkennen ... zumindest wäre das Fehlerbild plausibel, wenn Speicher fehlt. Auch als temporäres Verzeichnis ist halt zusätzlicher Speicher außerhalb des NAND-Flashs nicht zu verachten ... mal abgesehen von der höheren Geschwindigkeit, weil der NAND-Flash schon von sehr langsamen Sticks ausgestochen wird.

Andererseits ist natürlich "modfs zeigt einige Fehler an" auch herrlich unkonkret ... darauf kann es theoretisch eben auch "einige Antworten" geben, weil das "einige Ursachen" haben könnte - insofern ist halt dem Wunsch auf Einsicht in die Protokoll-Datei auch nur wenig hinzuzufügen.

Wenn dann beide Partitionen eben eine AVM-Version ohne Shell-Zugang enthalten, ist das auch kein echter Beinbruch - es geht erst einmal nur darum, ob die Box technisch einwandfrei ist oder nicht. Spätestens beim Tauschversuch bei AVM (die hat ja nun noch jede Menge Garantie, diese Box) brauchst Du dann ohnehin originale Firmware in beiden Partitionen.

Wenn die Technik sicher o.B. ist, dann kann man darüber nachdenken, wie man da - ohne Downgrade auf 06.50 oder früher - zu seinem Shell-Zugang kommt ... ggf. veröffentliche ich dann mal den Stand von "modfs-Starter reloaded" als Beta (ist ein wenig eine Frage des Timings - eigentlich würde ich gerne die Release-Version von AVM noch abwarten, damit ich da ggf. noch Anpassungen vornehmen kann; auch wenn ich eher nicht an "last minute"-Änderungen seitens AVM glaube).
 
Hallo,
Das mit 08.83 und ein Labor update habe ich auch schon gemacht so das in beiden Partitionen eine Firmware lag,das musste ich aber 4-5 mal machen bis das es auf der Box war.
Die Box hat auch einige male gebootet aber es war immer die 06.83 drauf bis auf einmal ging es dann.
Mir lommt es auch so vor als wenn die Box sich manchmal quaelt... die brauch halt manchmal lange.

m.f.g.joto
 
Hallo,
habe grad nochmal in der 06.50 mit shellinabox ueber modfs auf die 06.60 versucht zu updaten und beim "Packen des neuen roots-Dateiystems" ...weg war die Box Neustart und alles war umsont.
Hat wieder in die 06.50 gebootet.
Wollte auch noch einmal "showshringbuf modfs" erstellen , aber das duerfte nach dem abbruch und Neuboot der Box wohl geschenkt sein...

m.f.g.joto
 
Also das sieht nun noch mehr nach einem Speicherproblem aus (das Packen braucht am meisten Hauptspeicher) ... wie man das mit einer Swap-Partition umgeht, steht hier irgendwo im Thread.
 
Hi,
Was heisst das nun genau?
Ist der Speicher der Box defekt?
Ich hatte hier eine andere Box , fast die gleiche version und selbes alter , da funktionierte alles ohne Probleme.
Ich verstehe das nicht wirklich.

m.f.g. joto
 
Nein, wenn es das von mir vermutete Problem ist, dann fehlt dem System nur Hauptspeicher beim Packen und da die Box von AVM so eingestellt wird, daß sie bei zu wenig Hauptspeicher einfach neu startet, kommt es zu den beobachteten Ergebnissen. Stellt man nun Swap-Space zur Verfügung, werden gerade nicht genutzte Speicherseiten dorthin ausgelagert.

Ich kann von hier aus auch nicht sehen, was diese Box nun von einer anderen unterscheidet ... aber schon der aktive Prozess der Suche nach einem DSL-Signal (nur als Beispiel, ich vermute mal, die Box hängt gar nicht am DSL-Kabel) könnte dafür sorgen, daß da eben mehr Prozesse aktiv sind als in der anderen und damit weniger Speicher zur Verfügung steht. Solange die Box noch nicht weiß, an was für einem Anschluß sie eigentlich betrieben wird, probiert sie halt fröhlich die verschiedenen Betriebsarten beim DSL durch - nur so verhindert AVM die Frage nach dem "Anschlußtyp" beim DSL. Aber das ist nur eine mögliche Erklärung für unterschiedlichen Speicherverbrauch ...

Wie ich bereits geschrieben habe ... einfach mal Swap-Space zur Verfügung stellen (steht schon ewig auch in #1, ist nur mittlerweile noch schwerer zu finden, weil Xenforo halt die BBCode-Tags nicht mehr richtig umsetzt) und probieren, ob das Packen damit dann durchläuft. Selbst wenn nicht, stürzt die Box dann nicht wegen Speichermangel direkt wieder ab und man hat zumindest das Protokoll von "modfs", in dem man mal nach den weiter vorne von Dir beschriebenen Fehlern suchen kann.
 
Hallo,
So nun habe ich Sauber mit recovery auf 06.83 danach auf die neuste Labor , danach habe ich auf 06.50 recovery und shellinabox , habe mir einen Swap mit 1024 und ext3 part Usb stick gemacht Usb auf 2.0 gestellt in der 7490 und ueber modfs auf 06.60 geupdatet.
Nach dem Reboot kommt die 7490 nicht mehr hoch , nur die POWER/DSL Led blinkt.

Werde die 7490 warscheinlich wieder nur per FTP und "quote SETENV linux_fs_start 1" wieder auf die 06.50 "linux_fs_start 1" bringen koennen.

Was ich aber schon sehr merkwuerdig finde Ich kann die 7490 mit 06.50 per shellinabox NICHT mit z.b. "echo linux_fs_start 0 > /proc/sys/urlader/environment" auf die andere Partition ( 0 ) umswitchen.
Wenn ich danach mit "cat /proc/sys/urlader/environment | grep linux" abfrage hat sich nichts geaendert,es bleibt bei "linux_fs_start 1".

Irgendetwas verhindert schon unter 06.50 mit shellinabox das switchen auf die andere Partition.

Ich habe im Anhang das log vom letzten versuch..

Langsam glaube ich die Box hat einen Defekt...

m.f.g.joto
 

Anhänge

  • modfs04.09.17_15uhr.txt
    37.1 KB · Aufrufe: 7
Hallo,
So nun das selbe Spiel mit der 06.50 (mit shellinabox) in der einen Partition und 06.50 PUR in der anderen Partition.
Im Anhang auch davon ein log und ein Bild nach dem Booten... da kommt nur das login und dann das was auf dem hoch geladenen Bild zu sehen ist.
Achja beim versuch VPN "Anzeige der VPN-Verbindungen auf der Startseite, inkl. Schnell-Link zur VPN-Konfiguration" gab es auch eine Fehlermeldung.
Auch hat hier das umswitchen auf die andere Partition mit shellinabox DIREKT nach dem modfs update NICHT Funktioniert... wird einfach nicht angenommen per shellinabox.

m.f.g.joto
 

Anhänge

  • modfs04.09.17_16uhr20.txt
    36.7 KB · Aufrufe: 6
  • 2_nach_06.50_modfs_beide_Partitionen_gleich.jpg
    2_nach_06.50_modfs_beide_Partitionen_gleich.jpg
    24.1 KB · Aufrufe: 16
Was passiert denn, wenn Du - von der laufenden Version in "1" aus - auf eine andere Version über das GUI aktualisierst ... dabei schaltet ja dann das AVM-Update selbst auf genau diesem Weg auf "0" um. Startet dann hinterher die gerade installierte Version?

Wenn nicht, könnte es (rein theoretisch) ein Rechteproblem beim (Schreib-)Zugriff auf das "procfs" sein ... allerdings sollte eine originale Firmware (ob mit oder ohne ShellInABox, dürfte dabei keine Rolle spielen bzw. dann funktioniert das AVM-Update mit seiner Umschaltung (s.o.) weiterhin) ohnehin immer als "root" arbeiten.

Die fehlende Uhrzeit könnte ggf. ein Problem sein (müßte ich auch erst nachsehen), weil ich an manchen Stellen in Shell-Code schon mal vor dem rekursiven Löschen mit "rm" auf eine gewisse Länge des Pfadnamens teste, damit nicht versehentlich falsch aufgelöste Variablen(-namen) zum unbeabsichtigten, rekursiven Löschen an ungewollten Stellen führt. Das kann auch dazu führen, daß ich einen Namen für ein Temp-Verzeichnis nicht akzeptiere ... allerdings sieht das Protokoll auch nicht danach aus.

Jedoch ist die Länge der Liste für am Ende des Skripts mit "cleanup" zu löschende Dateien deutlich zu groß, für einen "normalen" Verlauf von "modfs". Da dürften noch vier bis sechs Einträge vorhanden sein - egal, ob man abgebrochen hat beim Packen oder das auch noch erfolgreich durchlief bis zur Installation (dann bleiben schon mal zwei Dateien mehr aufzuräumen).

Wenn Du erst wieder auf die andere Einstellung von "linux_fs_start" gehen mußt, damit die Box mit der vorhergehenden Version nach dem "modfs" wieder startet, dann muß da ja eigentlich irgendetwas umgeschaltet werden vom "modfs". Das kann man auch einfach durch einen zweiten Aufruf kontrollieren ... "modfs" verweigert dann den Dienst, wenn die "linux_fs_start"-Variable nicht auf das aktuell laufende System zeigt - welches das ist, wird vorher ermittelt. Mit "modfs undo" kann man dann so eine bereits erfolgte Umschaltung auch wieder rückgängig machen, solange man noch nicht neu gestartet hat.

Irgendwie haben die beiden Probleme (einmal "linux_fs_start" und einmal das Nichtstarten der mit "modfs" erzeugten Version) auch nichts direkt miteinander zu tun und sie sind mit einem (einzelnen) Defekt der Box auch schwer erklärbar ... die Environment-Variable wird ja bei der 7490 im TFFS gespeichert (also im SPI-Flash) und das System im NAND-Flash. Außerdem kann der NAND-Flash eigentlich auch nicht defekt sein, wenn Du tatsächlich zwei verschiedene (AVM-)Versionen installieren und jeweils auch erfolgreich starten/benutzen konntest.

Die Box ist auch so alt, daß die - manchmal berichteten, aber m.W. nicht verbrieften - Probleme beim Setzen von Environment-Variablen für das Branding nicht vorhanden sein können ... außerdem wäre das für "linux_fs_start" auch ziemlicher Blödsinn, wenn das von irgendwoher "restauriert" würde (außer halt auf den Standardwert "0", wenn der Eintrag ganz fehlt).

Ansonsten grenze mal einfach Deine Versuche des Schreibens ins Environment auch ordentlich mit "quotes" ab ... der Code beim Schreiben im TFFS-Treiber ist da etwas empfindlich.

EDIT: Weil gerade noch das mit dem weiteren Beitrag dazukam ... entscheide Dich für eine Variante des "gui_bootmanager"-Patches - daß ich da auf die Intelligenz der "modfs"-Benutzer vertraue, habe ich hier irgendwo ausdrücklich festgehalten, als ich danach gefragt wurde, warum die beide gleichzeitig angeboten werden. Wenn es keine negativen Rückmeldungen zur 0.4 gibt, kann ich die 0.3 ja gerne deaktivieren ... aber die meisten regelmäßigen "modfs"-Benutzer haben sicherlich ohnehin eine eigene Auswahl über die "custom_modscripts" und werden eher nicht jedesmal (bei jeder neuen Labor-Version) den Fragen-Marathon aufs Neue in Angriff nehmen.
 
Zuletzt bearbeitet:
Das ist ganz einfach ... wie in "Das Leben des Brian": Jeder nur einen Bootmanager ...

EDIT: Ich denke mal, die lange Liste der Dateien ist dann doch auf das "händische" Beantworten der Fragen nach den verschiedenen "modscripts" zurückzuführen ... da fehlt wohl irgendwo ein Löschen, wenn die Beschreibungen dort zusammengesucht werden (wobei das komischerweise wohl nur dann fehlt, wenn die Auswahl auf "manuell" steht).
 
Zuletzt bearbeitet:
Hi,
Ueber FTP adam2 kann ich ja umschalten..... aber siehe dir bitte einmal das hoch geladene Bild an , das sieht so aus als wenn da nur die Haelfte des Updates mit modfs geschrieben worden waehre oder besser nur ein teil.
Beim ersten Start konnte ich bei der anmeldung sogar mein Passwort eingeben obwohl es doch eigendlich nach modfs update eine Neuinstallation sein muesste mit dem ueblichen Neusetzen eines Passwortes u.s.w..
Irgendwie kommt es mir so vor als wenn nur ein Teil geschrieben wuerde.
Ausserdem hatte ich bei der recovery auf 0.6.50 und anschliessend das shellinabox auch Probleme , erst wollte die Box nicht und es hat ,wieder einmal erst, nach dem zweiten mal funktioniert.
Ausserdem braucht die Box viel laenger beim Packen wie die andere Box die ich hier zu erst hatte.
Komisch ... komisch...

m.f.g.joto
 
Dann schau doch einfach mal in die Support-Daten bzw. bei einer neueren Firmware auch in "/proc/avm/nandstat", wenn Du Telnet-Zugriff hast. Da werden die Fehler für den NAND-Speicher ja protokolliert (einmal beim Start in den Kernel-Messages und in der Pseudodatei im "procfs" laufend als Summe - ich weiß aber nicht mehr genau, mit welcher Version die eingeführt wurde) ... es kann ja durchaus sein, daß Dein NAND-Flash dann doch Probleme macht, zumal auch das Entpacken ja dahin ausgeführt wird bei Dir.

Da gibt es einfach zu viel freien Speicher, hier hilft es schon, irgendeine Dummy-Datei ausreichender Größe anzulegen (natürlich ohne Inhalte, sonst hat man gleich den nächsten Schreibzugriff auf den betroffenen Flash-Speicher) und dann fragt "modfs" auch nach, auf welchem Volume es seinen temporären Speicher einrichten soll, wenn der Platz im YAFFS2 nicht reicht (bzw. es nimmt dann das einzige andere, wenn es nur eines gibt).

Ach so ... nochmal: Das Kommando zum Umschalten lautet richtig:
Code:
echo "linux_fs_start 0" >/proc/sys/urlader/environment
... der Code im Treiber ist da etwas "schwierig", weil er sich bei leerem Wert zwischen Löschen (das entspricht dem UNSETENV aus EVA) und eben einem leeren Wert (wie bei "ptest") entscheiden muß. Zwar findet man das bei AVM auch desöfteren ohne die Quotes, ich habe aber selbst schon Probleme gehabt, daß es ohne die Quotes einfach nicht richtig klappen wollte. Ich würde es zumindest mal versuchen ... zumal AVM da am Treiber auch immer mal wieder geändert hat (auch wenn ich nicht verglichen habe, ob diese Stelle nun ebenfalls betroffen war oder nicht).

Ein "modfs update" löscht auch keine Einstellungen ... schon gar kein Kennwort. Wenn Du also zuvor "modfs" aufrufen konntest und Dich dazu anmelden mußtest, dann ist das vollkommen normal, wenn beim nächsten Start das Kennwort weiterhin aktiv ist.
 
Zuletzt bearbeitet:
Hallo,
So umschalten geht ... war mein Fehler hatte nicht auf die Unterstriche geachtet.
Ne ich hatte doch geschrieben das ich mit modfs eine saubere 06.50 von der 06.50 mit shellinabox gemacht habe und nach dem neustart kam dann die anmeldemaske dann das Passwort und dann kam diese Seite , siehe hoch geladenes Bild(anhang).
Habe mit adam2 wieder auf die 06.50 mit shell geswitcht .
Das mit der abfrage ueber die shell /proc/avm/nandstat b.z.w. abfrage der nandfehler habe ich noch nie gemacht...bin kein Profi... wo steht das denn in den Supportdaten b.z.w. wonach muss ich da suchen?

m.f.g.joto
 
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.