[Frage] 7490 - MTD1 sichern, wie? ADAM2 "get mtd1" schlägt fehl. Telnet?

RAMler

Mitglied
Mitglied seit
22 Mrz 2010
Beiträge
784
Punkte für Reaktionen
0
Punkte
18
Nabend :)

Weiß hier vielleicht jemand wie ich mtd1 von einer 7490 sichern kann? RuKernelTool unterstützt scheinbar keine 7490 und der händische Versuch die Kiste in ADAM2 zu halten und

- quote MEDIA FLSH
- get mtd1

schlägt leider fehl. Gibt es eine Möglichkeit es einfach über Telnet auf einen angeschlossenen USB Stick zu schreiben?

Gibt es hierzu eine Lösung, die ich hier leider nicht finden konnte?

Danke im Voraus! :)

EDIT:

Ok, mtdblock0 ist das kernel.image
meme
cat /dev/mtdblock0 > /var/flash/media/ftp/blablameinusbstick/7490/kernel.image

Kann ich das image irgendwie überprüfen und - eigentlich viel wichtiger - wie könnte ich es, wenn mal wieder benötigt, zurückspielen? :confused:

Könnte man das über Telnet wieder in /dev/mtdblock0 schreiben oder brickt das ggf. die Kiste?

Was hat es mit dem reserved_kernel auf sich, der leer ist?
 
Zuletzt bearbeitet:
Schön aufpassen ... die Sicht von EVA (ADAM2) auf die Partitionen im NAND-Flash (und im Serial-Flash) ist eine vollkommen andere, als die eines laufenden Systems.

Ansonsten habe ich im Modifikationen-Unterforum vor langer Zeit (müßte irgendwann Aug. 2014 gewesen sein) etwas zu "dual-boot" (da hast Du dann die "reserved"-Partitionen) und dem Recovery-Vorgang bei der 7490 geschrieben. Sowohl "modfs" als auch die Umschaltung zwischen den beiden Systemen (bootmanager) basieren ja darauf. In "modfs" wird auch die (jeweils inaktive) Kernel- und Filesystem-Partition geschrieben.

Schreiben läßt sich der Inhalt einer Partition in einem laufenden System (das kann man über den Bootloader in den RAM laden und dort starten) mit einem AVM-Tool "update_kernel" (wie das aussehen könnte, findest Du in der Datei /wrapper/sbin/flash_update einer laufenden 7490) ... auch wenn ich nicht so richtig verstehe, warum Du den sichern willst (es ist definitiv nicht der Bootloader), denn genau den Inhalt dieser Partition findest Du in jedem Firmwareupdate-Image - bei den NAND-Flash-Modellen sogar noch schön nach Kernel und Filesystem getrennt.

Die Alternative des Auslesens/Schreibens über nanddump/flash_eraseall/nandwrite ginge theoretisch auch, wenn man eine passende Busybox hat ... aber das AVM-Tool funktioniert ganz hervorragend und ist eben automatisch im System schon vorhanden.
 
Danke für deine Hilfe.

Ich wollte einfach die Firmware sichern, da es sich um eine Providerbox handelt und ich diesmal nicht den gleichen Fehler wie damals machen wollte, nämlich ohne provider fw dump dazustehen.

$ cat /proc/mtd

dev: size erasesize name
mtd0: 00400000 00020000 "kernel"
mtd1: 03000000 00020000 "filesystem"
mtd2: 00400000 00020000 "reserved-kernel"
mtd3: 03000000 00020000 "reserved-filesystem"
mtd4: 00200000 00020000 "config"
mtd5: 01600000 00020000 "nand-filesystem"
mtd6: 00020000 00001000 "urlader"
mtd7: 00010000 00001000 "tffs (1)"
mtd8: 00010000 00001000 "tffs (2)"

Dachte daher, dass mtd0 die Firmware sei.

Beim Rückspielen im Betrieb scheitere ich mal wieder an meinen mangelnden Linux Kenntnissen. Kann ich das nicht einfach mit einem cat /vat/media/ftp/usbblub/kernel.image > /dev/mtdblock0 schreiben? Vermute mal nein. :D

EDIT:
Frage am Rande.
Wenn ich "nur" die AVM FW update, zerlegt mir das trotzdem in /var/flash die "provideradditive.tar" des providers?

EDIT2:
Lese gerade deine alten Posts (für interessierte *klick*) und ganz ehrlich, da(für) fehlt mir enorm viel Grundwissen - leider. :(


---
Das ich auch nie meine Finger ruhighalten kann. -_- Dadurch, dass der DECT Part so schlecht war, wollte ich ein FW Update machen (ohne debranding), also nur flashen, was über das Menü geht wenn man einen anderen Internetanbieter auswählt. Ich machte zuerst ein downgrade (in der Hoffnung, dass er sich die neuere FW vom ACS holt und ich dann gerade mein gewünschtes Backup habe :-X)

Die provideradditive.tar ist nach wie vor in der FW, auch wird der ACS in die tr069.cfg eingetragen. Es finden sich auch die ACS Einwahldaten in der ar7.cfg ... aber die Box bekommt vom Provider keine Daten mehr. :(

Sie wählt sich einfach mit den ACS Logindaten ins Netz ein (was ich natürlich dann nicht nutzen kann), wird aber nicht mehr provisioniert.

Wieso kann ich Depp auch nicht mal ein paar Tage meine Finger still halten ... -_- Eine Idee Peter?
 
Zuletzt bearbeitet:
Kann ich das nicht einfach mit einem cat /vat/media/ftp/usbblub/kernel.image > /dev/mtdblock0 schreiben? Vermute mal nein.
Richtig. So ein NAND-Flash muß eben erst vorher gelöscht werden, bevor da "neue Daten" abgelegt werden können.

Als Lektüre zum Grundverständnis von Flash-Speicher unter Linux kann man z.B.

http://www.linux-magazin.de/Ausgaben/2012/07/Flashspeicher

empfehlen. Dort steht dann auch, warum das direkte Schreiben in /dev/mtdblock0 (obwohl möglich) keine gute Idee ist.

Wieso kann ich Depp auch nicht mal ein paar Tage meine Finger still halten ... -_- Eine Idee Peter?
Ich habe noch nicht einmal richtig verstanden, was Du da wirklich gemacht hast.

Eine ordentliche Angabe, was Du da als Provider eingestellt hast bzw. welcher das ist, damit man mal recherchieren kann, ob da DHCP oder PPPoE zum Einsatz kommen sollte, wäre der erste Schritt.

Ansonsten ist so eine "provider-additive.tar" nur eine von der Box selbst zusammengepackte Sammlung verschiedener Einstellungsdateien, die unter dem Pfad "/var/flash/provider_additive" liegen und vom ctlmgr zu der Datei /var/flash/provideradditive.tar zusammengefaßt werden. Die Existenz/das Fehlen dieser Datei sagt noch noch so sehr viel aus ... es gibt auch mehrere Weg, diese Dateien unter /var/flash/provider_additive zu erzeugen, vom USB-Stick bis zur "Vorprogrammierung" der Box beim Provider. Man müßte also auch hier wieder wissen, welcher Provider das überhaupt ist, wenn man recherchieren will, auf welchem Weg dort die Boxen angepaßt werden. Bei einem "normalen" Downgrade sollten bereits auf der Box befindliche Dateien im Flash eigentlich nicht beeinträchtigt werden ... aber ein "normales Downgrade" dürfte bei einer Box mit "provider additive" im Environment auch gar nicht funktionieren. Daraus würde ich jetzt erst einmal schließen, daß Du da schon etwas verschlungenere Wege gegangen sein mußt ... die wirst Du schon offenlegen müssen, sonst kann Dir vermutlich niemand helfen.

Bei der 7490 kommt dann noch hinzu, daß die zwei unterschiedliche "Einstellungsspeicher" hat ... da, wo NOR-Boxen den Inhalt von /var/flash im tmpfs (also im RAM) bei jedem Start neu aufbauen, haben diese Boxen eine yaffs2-Partition, die diese Verzeichnisstruktur auch über einen Neustart hinaus bewahrt. Dort werden dann wieder die Nodes für den Zugriff auf das Serial-Flash (als Minor-IDs des TFFS-Devices) angelegt. Wenn also jemand einfach eine neue Datei nach /var/flash schreibt, ist diese nach einem Neustart bei der 7490 nicht einfach wieder weg, wie bei anderen Modellen, sie bleibt erhalten.

Da ich selbst noch keine Box mit "provideradditive.tar" in der Hand hatte, weiß ich nicht einmal genau, ob die tatsächlich diese "provideraddtive.tar" irgendwo permanent erzeugt oder ob die nicht nur "on the fly" gepackt wird, um sie beim Sichern der Einstellungen zu archivieren. Die Zeilen
Code:
/var/flash
provideradditive.tar
/var/tmp
tar cf %s provider_additive
in der libcfgimpexp.so lassen mich letzteres vermuten ... /var/flash als aktuelles Verzeichnis, wo das "tar"-Kommando mit dem zusammengesetzten Pfad aus "/var/tmp" und "provideradditive.tar" ausgeführt wird und die dort entstandene Datei dann in der Export-Datei landet. Man sieht ja in den Köpfen der Dateien im "Textformat" auch, daß die ebenfalls direkt für den Export als Kopie in /var/tmp erzeugt werden - bei der provideradditive.tar wäre es eben ein etwas komplexeres Kommando zur Erzeugung.

Auf der anderen Seite wird auch im ctlmgr (vermutlich im Rahmen der Konfiguration der Box, wie es bei der "providers-049.tar" für D auch passiert) eine Datei /var/flash/provideradditive.tar verwendet, dort finden sich dann die Zeilen
Code:
/var/flash/provideradditive.tar
cat %s | tar xf -
, was relativ gut zu einem Zugriff auf TFFS-Nodes (nur "character oriented I/O", daher das "cat" vor dem "untar") passen würde und die Existenz eines passenden Nodes (der hätte die Minor-ID 30) voraussetzen würde. So eine Datei (bzw. einen Node mit entsprechendem Inhalt) würde dann eben der Provider mit einer "Vorbereitung" der Box erzeugen. Das ginge ähnlich wie Recovery ... nur mit einem speziellen Programm, was kein neues System flasht, sondern nur diesen Eintrag im TFFS erzeugt, der auch für alle Boxen gleich wäre - u.U. also auch schon bei der Produktion eingespielt werden könnte und nicht erst beim Provider selbst. Alternativ wäre auch ein Start einer Box mit einem passenden USB-Stick noch beim Provider denkbar, wo dann über "tr069starter" einfach aus den Daten auf dem Stick eine solche "Datei" erzeugt wird; bei einigen Providern gab es (zumindest früher) sogar die Möglichkeit, diesen USB-Stick erst beim Kunden anzuschließen und damit die "provideradditive.tar" erst dort zu erzeugen.

Soviel dazu, was ich mir da so zusammenreime ... alles unbestätigt und mehr aus den Beobachtungen anderer und einigen Fundstellen in der AVM-Firmware abgeleitet, als aus eigenem Erleben geschlossen.

Wenn meine Vermutung nur annähernd zutrifft, sollte es bei Dir im TFFS einen Node mit Minor-ID 30 und entsprechendem Inhalt geben, der die providerspezifischen Einstellungen beinhaltet. Die könnte man sich dann zumindest mal ansehen und sie mit dem vergleichen, was Deine Box jetzt macht. Mit

Code:
mkconfgfile /var/tmp/chk_provadd.tar 30
cat /var/tmp/chk_provadd.tar >/var/media/ftp/provadd.tar

sollte man diese Datei (so dort etwas enthalten ist) an einen Ort kopieren können, wo man mit dem NAS der Box darauf zugreifen kann (Wurzelverzeichnis des NAS).

Wenn Du etwas am Urlader-Environment verändert haben solltest, um ein Recovery mit AVM-Programmen auszuführen (die weigern sich eigentlich, wenn da entsprechende Einstellungen drin sind), müßten wir das auch wissen. Ich habe nur eine ungefähre Vorstellung, was Du mit ""ich machte zuerst ein downgrade" meinst ... mit (originalen) AVM-Programmen kann ich mir das nicht so richtig vorstellen und wenn Dein Provider eine spezielle Version dafür bereitstellt, dann könnte man dort ja mal hineinsehen.

Ein Update auf eine niedrigere Versionsnummer per AVM-GUI (als Downgrade), sollte den Inhalt des TFFS mit Minor-ID < 100 unangetastet lassen und dort auch nichts verändern. Da müßte also nach dem Wiederherstellen der ursprünglichen Firmware-Version und dem Einspielen des Backups der Einstellungen wieder alles wie vorher sein und der Provider muß die Box dann ja gar nicht neu provisionieren.
 
Zuletzt bearbeitet:
Vielen Dank Peter!

Ich bin leider noch nicht dazu gekommen alles zu lesen, habe aktuell etliche Baustellen parallel. Nehme ich gerade mal nach. :)
Provisionierung geht mit der aktuellen PHONE Labor. Mein Provider ist Inexio und soll wohl auch in die FW eingepflegt werden, also wird in Zukunft der "additive" wohl wegfallen.

Mit Versionen vor der PHONE Labor kann ich mich zwar am ACS anmelden, die Provisionierung schlägt aber fehlt.

Sammlung verschiedener Einstellungsdateien, die unter dem Pfad "/var/flash/provider_additive" liegen
Pfad gibt es nicht. Aber vielleicht steht der Provider in der "PHONE Labor" nun schon unter /etc/default.Fritz_Box_7xxx/avm/providers-049.tar drin und es geht dadurch. Jap, genau das ist der Fall - in der FW wurde Inexio schon eingepflegt! :D

Also war damals mein einziges Problem das ich den Ordner /var/flash/provider_additive nicht sicherte? (Beim "rückbasteln" einer Box) - Oh Mann ... -_-
Wenn dort die gleichen Files wie in der .tar liegen, kann ich die auch einfach in den Ordner entpacken?

aber ein "normales Downgrade" dürfte bei einer Box mit "provider additive" im Environment auch gar nicht funktionieren. Daraus würde ich jetzt erst einmal schließen, daß Du da schon etwas verschlungenere Wege gegangen sein mußt ... die wirst Du schon offenlegen müssen, sonst kann Dir vermutlich niemand helfen.
Jain - der Provider ist so "fair", dass man nur einen anderen ISP in der Liste nehmen muss, damit die FW LUA Pages sichtbar werden. Alternativ kann man diese natürlich auch per Hand in der ar7 wieder einblenden - musste ich aber nicht mal.

Wenn also jemand einfach eine neue Datei nach /var/flash schreibt, ist diese nach einem Neustart bei der 7490 nicht einfach wieder weg, wie bei anderen Modellen, sie bleibt erhalten.
Danke für die Info! Evt. war mein downgrade (Werkseinstellungen) der Grund, wieso es dann den Ordner provider_additive wegfegte?

u.U. also auch schon bei der Produktion eingespielt werden könnte und nicht erst beim Provider selbst.
Wird es, die AVM OVPs sind mit "Inexio Edition" versehen.

mkconfigfile /var/tmp/chk_provadd.tar 30 cat /var/tmp/chk_provadd.tar > /var/InternerSpeicher/bla.tar
leer, aber vielleicht jetzt mit der PHONE FW auch schon wieder hinfällig? Der Provider steht ja nun "regulär" in der /etc/default.Fritz_Box_7xxx/avm/providers-049.tar.

Wenn Du etwas am Urlader-Environment verändert haben solltest, um ein Recovery mit AVM-Programmen auszuführen (die weigern sich eigentlich, wenn da entsprechende Einstellungen drin sind), müßten wir das auch wissen.
Ich habe die Box im Zuge einer Fehlersuche bezüglich DSLAM/Linecard Inkompatibilität erhalten und halte da ganz brav die Finger still, da ich den Provider ungern aussperren möchte (Kulanz und Service extrem gut!).

und wenn Dein Provider eine spezielle Version dafür bereitstellt, dann könnte man dort ja mal hineinsehen.
Wollten mir die FW für meine 7390 auch auf Nachfrage nicht rausgeben und kamen nicht mehr auf meine BOX, weil ich diese komplett debrandet hatte. Also quote UNSETENV provider und recover drüber. kernel.image der 7490 (6.20) habe ich gestern aber angelegt.

Deshalb ärgerte ich mich mit der aus Kulanz gestellten 7490 auch erst über mich selbst, dass ich direkt ein downgrade machte und damit die Provisionierung abschoss. Wieso verstehe ich ehrlich gesagt immer noch nicht wirklich.
Aber halb so wild, da der Provider ja in naher Zukunft nun eh in der "AVM FW" drin ist und auch ohne Provisionierung der TR069 Zugriff des Technikers heute noch einwandfrei funktionierte.

Ein Update auf eine niedrigere Versionsnummer per AVM-GUI (als Downgrade), sollte den Inhalt des TFFS mit Minor-ID < 100 unangetastet lassen und dort auch nichts verändern. Da müßte also nach dem Wiederherstellen der ursprünglichen Firmware-Version und dem Einspielen des Backups der Einstellungen wieder alles wie vorher sein und der Provider muß die Box dann ja gar nicht neu provisionieren.
Bei einem downgrad werden ja die Werkseinstellungen gelanden und die Box holte sich danach die Zugangsdaten nicht mehr vom ACS. Ich war wirklich mit 01.01.1970 auf dem ACS "eingewählt", Verbindung bestand und die Kiste zeigte mir IPv4/IPv6 an. Zugangsdaten/Benutzerdaten wurden mir aber keine mehr zugewiesen und ins Netz gings natürlich auch nicht.
In der tr069.cfg wurde auch kein neueres Zugriffs Datum gesetzt.

Woran das nun genau liegt, ehrlich gesagt keine Ahnung. Environment unangetastet, provideradditive.tar nach wie vor da und die darin enthaltenen Infos wurden auch in ar7.cfg, so wie tr069.cfg geschrieben.
Der ACS wollte trotzdem nicht. Vor dem gleichen Problem stand ich damals mal, als ich die 7390 wieder in Werkszustand friemeln wollte. :-/
 
Zuletzt bearbeitet:
SNIP

Auf der anderen Seite wird auch im ctlmgr (vermutlich im Rahmen der Konfiguration der Box, wie es bei der "providers-049.tar" für D auch passiert) eine Datei /var/flash/provideradditive.tar verwendet, dort finden sich dann die Zeilen
Code:
/var/flash/provideradditive.tar
cat %s | tar xf -
, was relativ gut zu einem Zugriff auf TFFS-Nodes (nur "character oriented I/O", daher das "cat" vor dem "untar") passen würde und die Existenz eines passenden Nodes (der hätte die Minor-ID 30) voraussetzen würde.

SNIP

Wenn meine Vermutung nur annähernd zutrifft, sollte es bei Dir im TFFS einen Node mit Minor-ID 30 und entsprechendem Inhalt geben, der die providerspezifischen Einstellungen beinhaltet. Die könnte man sich dann zumindest mal ansehen und sie mit dem vergleichen, was Deine Box jetzt macht. Mit

Code:
mkconfgfile /var/tmp/chk_provadd.tar [COLOR=#ee82ee]30[/COLOR]
cat /var/tmp/chk_provadd.tar >/var/media/ftp/provadd.tar
SNIP

@PeterPawn: meines Wissens wird seitens AVM für den Char-Node /var/flash/provideradditive.tar die Minor-ID 29 DEC genutzt wird.
Kann es sein, dass hier ein Tippfehler vorliegt ?
 
Ja, war ein uralter Tipp- und Ablesefehler meinerseits (ich war beim Ablesen in den AVM-Quellen in der Zeile verrutscht bzw. habe direkt vor der ID 31 (ar7.cfg.diff) die nächste ID eingetragen) - ist aber schon sehr sehr lange korrigiert und irgendwo gibt es sogar einen Beitrag, wo ich das anspreche - eben genau die Tatsache, daß ich mich früher auch mal vertan hatte, das aber schon lange (auch im GitHub-Repo an den richtigen Stellen) korrigiert ist.

Die ID für diese "provideradditive.tar" ist die 29(d) oder 0x1D - zu finden in der "tffs.h" in den Kernel-Quellen.
 
Hallo zusammen!
Ich hole diesen älteren Thread hier nochmal hoch, weil ich ein ähnliches Problem wie RAMler habe. Ich hatte zuerst eine 7390 von Sunrise (CH), habe VDSL. Offiziell ist seitens Sunrise 6.23 die neueste Version. Da ich eine halbwegs aktuelle Version haben wollte, hatte ich die 7390 auf die offizielle internationale (a_ch) AVM 6.83 upgedatet. Seitdem hatte ich aber sehr häufige Verbindungsabbrüche, vielleicht der Grund warum Sunrise immer noch bei 6.23 steht... Wobei es viele Sunrise user gibt, die in diversen Foren darüber berichten, dass sie erfolgreich mit der 6.83 unterwegs sind. o_O

Ich konnte dann auf eine 7490 umsteigen, die auch mit der 6.23 kam. Bevor ich hier wieder den gleichen Mist baue, wollte ich sicher gehen, dass ich den Ursprungszustand der Box wieder herstellen kann. Da nirgendwo ein Image der 6.23 zu finden ist, wollte ich mir selber eines erstellen (dumpen).

Irgendwie ist diese Info aber sehr schwer ausfindig zu machen, vor allem über das Zurückspielen eines solchen selbst erstellten Images findet man sehr wenig. Am liebsten hätte ich natürlich am Ende eine image Datei in der Form, wie sie auch offiziell von AVM bereitgestellt wird, so dass ich diese über das Webinterface hochladen kann oder ggfs. beim Downgrade per ruKernelTool.
Dieses Image und die über das Webinterface gesicherte config sollten mir es dann ermöglichen, zu jedem Zeitpunkt wieder auf den jetzigen funktionierenden Zustand zurückzukehren.

Ich bin also über jeden Tipp dankbar, wie ich ein solches Image erstellen kann und am besten auch noch gefahrlos verifizieren kann, dass es auch wirklich funktioniert. Vielleicht bin ich auch einfach zu blöd und finde diese offensichtliche Funktion in den gängigen Tools nicht? Linux-Kenntnisse sind auf jeden Fall vorhanden, bin also eher ein FritzBox-Noob, sonst ist da schon etwas Wissen vorhanden :D
 
Suche einfach nach Informationen zu:

- FRITZ!Box 7490 und Aufbau des NAND-Flashs ... in diesem Zusammenhang kommt man dann irgendwo auch bei "linux_fs_start" und seiner Bedeutung an

- NAND-Boxen und der Start aus dem RAM anstelle des Flash-Speichers ... da kann man (fast problemlos) eine Kopie der Kernel- und Dateisystem-Partitionen auf dem NAND-Flash ablegen und dann - bei laufendem FRITZ!OS - über die NAS-Funktionen sichern und das alles sogar, ohne irgendeine andere Firmware auf der Box tatsächlich zu installieren

- da die 06.23 sogar noch unsignierte Images akzeptieren müßte (das wäre schon ein sehr weiter Schritt von der 06.23 zur 06.51 bei der deutschen Version, wo dann die Signaturpflicht eingeführt wurde), gibt es sogar für die 06.23 einen komplett beschriebenen Weg, wie man zu einer Shell-Session auf diesem Modell gelangen kann und sogar die dazu notwendige Image-Datei liegt noch an der beschriebenen Stelle auf dem Server (habe ich gerade noch einmal geprüft)

Vergiss einfach 90% der "Erfahrungen", die Du mit der 7390 und der Installation einer anderen Firmware gemacht hast ... das paßt nicht mehr zur 7490. Warum? Siehe die Suchhinweise oben.

Es ist also tatsächlich komplett beschrieben, wie man zu einer Shell-Session in einer 7490 mit 06.23 gelangen kann und irgendwo steht garantiert auch, welche Partitionen man dann in so einer Session sichern muß und womit man das jeweils machen kann.

Ich würde mich also nicht an diesem Thread als "bestes Suchergebnis" festklammern ... zeige mal etwas Phantasie beim Recherchieren.
 
Danke schon mal für die Stichworte Peter, damit gestaltet sich die Suche schon erheblich leichter ;)
Also ich versuche mal mein Verständnis hier wiederzugeben mit der Hoffnung auf Korrektur, wenn etwas nicht stimmt. Leider ist die freetz Seite down, die Google Resultate lassen aber auf eine ansonsten wertvolle Wissensquelle schließen. Mittlerweile sind ein paar Sachen klarer geworden, allerdings dachte ich zu Beginn dass mein Fall ein ziemlicher Standardfall wäre, so dass z.B. das ruKernelTool eine entsprechende Funktion anbietet. Schließlich müsste das doch fast jeder hier machen wollen, bevor er anfängt wild an seiner Box herumzubasteln?

NAND-Flash und linux_fs_start:
Die Kernel-Partition (mtd0) liegt nicht mehr wie bei älteren Boxen im EEPROM, sonder im großzügigen NAND-Speicher. Zudem handelt es sich um ein Dual-Boot-System. D.h. geht ein Update schief, kann man auf die 2. Partition wechseln und wieder booten. Die Auswahl der aktiven Partition geht über die linux_fs_start Variable (Werte: 0 oder 1).

Start aus dem RAM:
Wenn ich das richtig verstehe steckt die Info hierzu in folgendem Post: https://www.ip-phone-forum.de/threa...04-vom-01-07-2015.279737/page-13#post-2102066
Das Ziel und der Weg sind mir hier aber noch nicht ganz klar geworden. Ich kann den Kernel und das Filesystem komplett in den RAM laden und dann quasi davon starten. Somit ist die ursprüngliche Kernel- und Dateisystem-Partition auf dem NAND nicht in Benutzung und ich könnte ein komplettes Abbild (image) davon erstellen, was dann mein angestrebtes Recovery-Image wäre? Wenn dem so wäre sind mir die einzelnen Schritte bis dahin allerdings immer noch ein Rätsel, ich bin da erst noch am Durchsteigen...

Unsignierte Images / Shell Zugang in 6.23:
Telnet müsste sich in der 6.23 noch ganz einfach per Telefoncode aktivieren lassen oder bin ich da falsch informiert?
Die 6.23 akzeptiert noch unsignierte Images. Soweit so gut, aber für einen späteren Downgrade (z.B. von 6.90) müsste ich dann in dem Fall mein selbst erstelltes Recovery Image signieren? Oder kann das nur AVM?

Ich habe es mit etwas Phantasie versucht und bin auf das Script von dir gestossen: https://www.ip-phone-forum.de/threads/6490-serial-port.283851/#post-2147376
Das sollte ja eigentlich genau das machen was ich will, oder sehe ich das falsch? Woanders schreibst du aber dass man in dem Fall mit tar das Dateisystem einfach komplett packen soll und cat/dd hier nicht der richtige Weg ist?

Update: Mit deinem modfs Tool könnte ich ja theoretisch auch direkt gefahrlos ein Update ausprobieren, wenn ich das richtig verstanden habe. Irgendwie wäre mir aber trotzdem ein gutes altes Recovery Image, welches den Ursprungszustand wiederherstellt lieb :)
 
Zuletzt bearbeitet:
allerdings dachte ich zu Beginn dass mein Fall ein ziemlicher Standardfall wäre, so dass z.B. das ruKernelTool eine entsprechende Funktion anbietet.
Das ruKernelTool ist schon etwas in die Jahre geraten und bietet für den Typ von Fritzboxen mit NAND-Flash, so wie du sie hast, gar keine Unterstützung an.
 
Der Aufbau der Partitionen bei einer 6490 ist noch einmal komplett anders, das dort gefundene Skript taugt also für eine 7490 ebenfalls nicht. Aber da das komplette System halt in den Partitionen "kernel"/"filesystem" bzw. "reserved-kernel"/"reserved-filesystem" enthalten ist, kann man diese tatsächlich einfach mittels "cat" aus dem character-Device für die MTD-Partition kopieren (bei der 7490 ist i.d.R. auch genug Platz in der "nand-filesystem"-Partition, um die vier anderen zu speichern).

Wenn in der 06.23 tatsächlich noch der Start des Telnet-Service direkt gelingt (die ist halt nicht frei verfügbar, daher schlecht zu testen und in der 06.30 ist er definitiv stillgelegt), dann ist das ja nun erst recht kein Kunststück ... wenn man den Aufbau der Partitionen erkundet hat. Irgendwann wird auch freetz.org wieder funktionieren ... ansonsten hilft ggf. die Wayback-Machine, weil sich am Aufbau der Partitionen einer 7490 schon eine ganze Weile nichts mehr geändert hat.

Da es sich bei der 06.23 noch um einen 2.6.32-Kernel handelt und ab 06.5x dann ein 3.10.73-Kernel verwendet wird (mit anderem SquashFS-Format), lege ich definitiv nicht meine Hand dafür ins Feuer, daß ein Update mittels "modfs" auch heute noch reibungslos funktoniert. Das ging zwar mal mit der älteren Version ... da es aber seit 06.5x (bzw. sogar seit der Labor-Reihe davor) nur noch selten Geräte mit 2.6.32-Kernel gibt, ist das seit mehr als zwei Jahren nicht mehr getestet.

Ich würde hier eher hingehen und ganz normal ein Update mit der AVM-Firmware machen ... wer hinterher keinen Shell-Zugriff braucht, muß auch kein Update mit einer passenden Firmware machen.

Auch über den "Rückweg" zu einer früheren Version bei der 7490 (auch per EVA und dann interessiert sich kein Mensch (und keine Firmware) dafür, ob da irgendetwas korrekt signiert ist oder nicht) ist inzwischen so viel geschrieben worden, daß man auch das finden sollte ... zum Thema "Starten aus dem RAM und wozu sollte das gut sein" empfehle ich (voreingenommen logischerweise) diesen Thread: https://www.ip-phone-forum.de/threa...l-recovery-a-la-avm-oder-besser-nicht.294386/ - vielleicht braucht man den noch mal im Kontext einer aktuellen AVM-Firmware (ohne Shell-Zugriff) auf der 7490 von sunrise.ch, wenn man weitere Änderungen ausführen will nach einem Update mit originaler AVM-Firmware.
 
Danke Peter!
Also telnet ließ sich tatsächlich über das Telefon aktivieren und ich ich habe mittels dd mal die interessanten Partitionen (kernel, filesystem, reserved-kernel, reserver-filesystem, urlader) gesichert.
Sollte ich neben der über das Webinterface gesicherten Config jetzt noch etwas sichern oder sollte das genügen? Wenn ich es richtig verstehe, könnte ich diese images jetzt jederzeit über EVA (FTP) wieder zurückspielen und sollte dann wieder auf der 6.23 sein, richtig?Sorry für die vielen Anfängerfragen, möchte nur vermeiden dass ich später doch irgendwas vergessen habe an dieser Stelle...
 
TFFS-Image würde ich auch noch sichern ... nur falls sunrise.ch da eine "provider_additive"-Konfiguration verwendet.

PS: Falls Du auf die Idee gekommen bist, den YAFF2-Inhalt auch mit "dd" zu sichern, dann solltest Du noch einmal über den Unterschied zwischen NOR- und NAND-Flash (und worum es sich bei OOB-Daten für die Fehlerkorrektur bei NAND-Flash handelt) nachdenken.

Bei den NAND-Boxen steht eben in den "(reserved-)?filesystem"-Partitionen ein YAFFS2-Dateisystem, dessen Inhalt man eher mittels "cp -a" sichern sollte (oder meinetwegen auch mit "tar" o.ä.). Eine "dd"-Sicherung von einer Dateisystem-Partition dürfte bei einer 7490 nur wenig helfen.
 
Zuletzt bearbeitet:
OK. Ich habe jetzt mal mit dd Images von allen genannten Partitionen gemacht.
Die reserved Partitionen müsste ich also zuvor mounten und dann mit "cp -a" auf Dateiebene sichern? Leider habe ich dazu kein Beispiel hier gefunden, oder bin ich auf dem Holzweg und ich sollte dein tbackup script benutzen?
Eine provider_additives.tar finde ich unter /var/flash nicht, sunrise.ch gibt auch an, dass ihr Anschluss "theoretisch" auch mit eigenen FritzBoxen funktionieren sollte.
So sieht das momentan bei mir aus:
Code:
# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00400000 00020000 "kernel"
mtd1: 03000000 00020000 "filesystem"
mtd2: 00400000 00020000 "reserved-kernel"
mtd3: 03000000 00020000 "reserved-filesystem"
mtd4: 00200000 00020000 "config"
mtd5: 19600000 00020000 "nand-filesystem"
mtd6: 00040000 00001000 "urlader"
mtd7: 00060000 00001000 "tffs (1)"
mtd8: 00060000 00001000 "tffs (2)"

Code:
# ls -lah /var/media/ftp/FRITZ/backup/
drwxrwxrwx    1 boxusr11 root        2.0K Oct 11 12:21 .
drwxrwxrwx    1 root     root        2.0K Oct 11 10:46 ..
-rw-r--r--    1 root     root        2.0M Oct 11 12:21 config.image
-rw-r--r--    1 root     root       48.0M Oct 10 17:08 filesystem.image
-rw-r--r--    1 root     root        4.0M Oct 10 17:07 kernel.image
-rw-r--r--    1 root     root       48.0M Oct 11 10:59 reserved-filesystem.image
-rw-r--r--    1 root     root        4.0M Oct 11 10:48 reserved-kernel.image
-rw-r--r--    1 root     root      384.0K Oct 11 12:14 tffs1.image
-rw-r--r--    1 root     root      384.0K Oct 11 12:15 tffs2.image
-rwxrwxrwx    1 boxusr11 root        2.9K Oct 10 17:18 tr069.cfg
-rw-r--r--    1 root     root      256.0K Oct 10 17:03 urlader.image

Ist die Zuordnung so richtig, wie /proc/mtd sie mir angibt? Also z.B. /dev/mtdblock1 = filesystem.image?
Vielen Dank für deine Hilfe! :)
 
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.

IPPF im Überblick

Neueste Beiträge