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

...Mit der Bereitstellung einer binären Datei, die für den Dauereinsatz bestimmt ist, übernimmt man auch gleichzeitig die Verantwortung, diese immer in der neuesten Version anzubieten und entsprechend zu aktualisieren, wenn in vorhergehenden Versionen (Sicherheits-)Lücken erkannt werden. ...
Das für SIAB notwendige privatekeypassword findet man hier auf Github von Peter zum selbst übersetzen. Damit hätte man zumindest die haben Miete einer "Frischzellenkur". ;)

... beim "modfs-Starter" ging es ja nur um einen "Einstieg" in die Box für die spätere Verwendung von "modfs" und (als "Wunsch" meinerseits) nicht um die dauerhafte Verwendung einer alten ShellInABox-Version. Es hat auch seine Gründe, warum ich diese Dateien in den "modfs-Starter"-Archiven nie wieder aktualisiert habe, obwohl die IIRC statisch gegen die OpenSSL-Libraries gelinkt waren und vermutlich schon länger eine "Frischzellenkur" vertragen könnten.
Die Integration von SIAB in ein Image mittels modfs (und ein damit verbundener Dauer-Einsatz) ist natürlich ein "relativ einfacher Weg", sich einen Einstieg in die Box für das nächste zukünftige Firmware Update zu ermöglichen, wenn man sich nicht gleich ein eigenes Schlüsselpaar zur Prüfung einer Signatur integrieren möchte (Die IMHO gute Idee wurde sogar in freetz integriert). Vielleicht wäre es möglich, nach dem o.g. Vorbild von "privatekeypassword" analog einen Zweig für die Erstellung von SIAB mit (If YOU Remember Correctly) statisch gelinkten OpenSSL-Libraries anzulegen? Dann könnte sich jeder Interessent mit zumindest mittelmäßgen Kenntnissen leicht eine ggf. notwendige "Frischzellenkur" kümmern? :gruebel:

Ich muss gestehen, dass ich jetzt nicht nach gesehen habe, ob es derartiges evtl. in der Feeetz Toolchain gibt. :rolleyes:
 
Ich dachte, das hätte ich in meinem Freetz-Fork schon drin ... bzw. das hätte @er13 dann sogar schon übernommen aus dem Fork.

Ich schaue es mir bei Gelegenheit noch einmal an ... es sollte (theoretisch) aber auch jetzt schon möglich sein, mit der Freetz-Toolchain das statisch gelinkte "Shell-in-a-Box" inkl. Unterstützung für das AVM-Zertifikat zu erzeugen (das ist ja das mit "privatekeypassword"-Support) und dann einfach das Binary aus dem Build-Verzeichnis von Freetz in ein eigenes Image (z.B. im Rahmen von "copy_binaries") zu kopieren, wobei es ggf. noch irgendwo ein rc-Skript für den Start braucht, wenn man es nicht wie AVM als CGI aufrufen will (was auch Nachteile haben kann, wenn man z.B. den "ctlmgr" aus so einer Sitzung neu starten will, weil mit etwas Pech (ich weiß nicht genau, wie die "Vererbung" dort aussieht) das Beenden von "ctlmgr" den CGI-Prozess auch abräumt).

Wenn das gar nicht statisch gelinkt ist, braucht man halt noch die passenden Libs und muß im Start-Skript "LD_LIBRARY_PATH" entsprechend setzen ... wenn ich mir mein Skript aus "modfs-Starter" ansehe, ist es wohl eher nicht statisch gelinkt. Welche Libs das Programm bräuchte, kriegt man mit dem "ldd" aus der Freetz-Toolchain heraus.
 
Sorry aber ich kann euch manchmal nicht ganz folgen, bin kein Softwerker. Eins nach dem anderen....
Ich habe gestern meine 3370 mit Recovery zurück auf 6.30 geflasht und mit modfs Option a bearbeitet. Davor natürlich einen USB-Stick ext3 formatiert und ein 256MB swapfile erstellt. Telnet wurde leider nicht dauerhaft eingeschaltet.
Telnet dann über das Pseudo-Image aktiviert und dann das Kommando
/usr/sbin/telnetd -l /sbin/ar7login

mit edit_rcuser eingefügt, so dass Telnet immer eingeschaltet wird.
Danach mit modfs ein Update auf die 6.51 gemacht und SIAB mittels Anleitung aus #414 eingefügt.
Anschließend das Kommando aus rc_user wieder entfernt, so dass nur noch SIAB aktiv ist.

Jetzt bin ich gerade dabei ein IN-Memory-Image von der 6.51 zu erstellen, scheiter aber daran das filesystem.image mittel unsquashfs4 zu entpacken. Muss ich daszu die Binary aus dem modfs.tgz nehmen?

Gruß
XC
 
Zuletzt bearbeitet:
Das mit dem "nicht ganz folgen" geht mir auch manchmal so ... was verstehst Du denn unter einem "in-memory"-Image (ich verstehe darunter eines, was man über den Bootloader ins RAM der Box lädt und dort startet) und warum sollte man das SquashFS-Image in diesem Falle irgendwie entpacken wollen?
 
Einfach nur aus Interesse und Spaß an der Freude oder mit einem bestimmten Ziel?

Wenn da bereits ein Update mit "modfs" auf die 06.51 gemacht wurde, was soll dann noch das "in-memory"-Image an dieser Stelle?

Ich bin irgendwie "lost in translation" ... ich habe keinen Schimmer, was da am Ende bei herauskommen soll bzw. wo jetzt das/ein Problem besteht.

Wenn irgendjemand auf einem x86-System ein Firmware-Image mit SquashFS4 im "AVM flavour" entpacken (und im Anschluß wieder einpacken) will, dann erstellt er sich entweder die passenden Tools für seinen Linux-Host selbst (Quellen sind inzwischen im Freetz-Trunk integriert) oder er könnte die Dateien aus dem "YourFritz"-Zweig des GitHub-Repositories benutzen, wobei es dafür von mir keine Funktionsgarantie gibt.
 
Einfach nur wissen wie es funktioniert. Ich habe noch ein 7490 mit OS6.80, da möchte ich auch ein Update mit modfs durchführen.
 
Ok, auch da gäbe es jetzt noch mind. eine Lücke im FRITZ!OS, um mit Kenntnis von Admin-Credentials Shell-Befehle auszuführen ... mal sehen, was ich noch so finde, für letztere hat AVM jetzt erst einmal bis zum 11.05.2017 Zeit, die in einer neuen Version (oder meinetwegen auch einem Bugfix-Release mit derselben Versionsnummer) zu beheben, bevor man sie selbst für die Ausführung von Kommandos in einer 06.80 benutzen kann - am Ende braucht es ja nur irgendeine Möglichkeit zur Ausführung eines Kommandos, um das ShellInABox-Paket über die "/sbin/flash_update" und die Ablage im "wrapper"-Zweig zu "installieren".

Ansonsten braucht es für ein solches Image auch nicht unbedingt ein "unsquashfs" ... der FS-Scanner-Code im Kernel erkennt auch ein "ext2"-Dateisystem, sofern davor dieser ominöse "Dummy-Block" steht, der die "sqsh"-Signatur enthält. Man muß sich einfach nur vor Augen halten, daß beim Starten aus dem Speicher der Box der Kernel-Code hinter dem Kernel-Image nach irgendeinem Dateisystem sucht, das er als "rootfs" einbinden kann. Findet er ein solches, mountet er es und startet das dort hinterlegte Programm "/sbin/init", wobei sich dieser Name noch durch einen entsprechenden Kernel-Parameter (init) beim Start abändern läßt. Es gibt also (abseits des einen von mir beschriebenen Weges) noch jede Menge zusätzliche Möglichkeiten, wie man so etwas angehen könnte.

Wo Du nun konkret hängengeblieben bist bei meiner "Anleitung", habe ich aber auch noch nicht verstanden ... abgesehen davon wäre die Diskussion dazu ggf. im Thread für Debatten über "modfs-Starter" (da hatte ich einen gesonderten Thread gleich selbst eingerichtet, damit es nicht wieder das Vermischen meiner Erklärungen zur Funktion mit Nachfragen gibt und hinterher niemand mehr etwas findet - auch wenn die Erklärung, wie es auch ohne "Pseudo-Image" funktioniert, wieder in diesem Diskussionsthread gelandet ist) besser untergebracht.
 
Hallo zusammen, gibt es derzeit eine Möglichkeit die 6490 Retail Version mit Firmware 6.63 Telnet zu aktivieren ? Ich habe nun schon etliche Threads zu dem Thema gelesen welche alle ca. 09. 2016 enden.
 
Ganz offensichtlich aber die falschen ... und ich gestatte mir auch (weil es hier in "meinem" Thread ist) die Frage, warum Du das brauchst.

Es geht tatsächlich und wenn man wirklich weiß, was man macht, ist das auch kein echtes Problem (weder beim Einrichten, noch beim Betrieb) ... aber nur, weil es "nice to have" wäre (und das Update älterer Provider-Boxen ist hier ja offenbar nicht die Triebfeder), muß man es noch lange nicht machen. Die Warnungen vor den durch einen Telnet-Server gerissenen Lücken stehen auch in den (richtigen) Threads jeweils daneben, wenn irgendwo beschrieben ist, wie man zu einem Shell-Zugang gelangen könnte.

Wie es um dieses "wenn man wirklich weiß, was man macht" bestellt sein mag, wenn man die betreffenden (richtigen) Informationen gar nicht erst findet, möge sich nun jeder selbst (und selbstkritisch) fragen.
 
Ich wollte einen TFTP Server nachinstallieren um meine Cisco VOIP Phones betreiben zu können. Eben um an den SSH Zugang zu kommen hätte ich mich dann vom Telnet aus weiter durchs Forum gehangelt, leider habe ich mit der Fritzbox im Allgemeinen nicht wirklich viel Erfahrung. Ich komme eher aus der Debian / OpenWrt Ecke und muss mich hier erstmal zurechtfinden.
 
Zuletzt bearbeitet:
Nimm besser einen Einplatinencomputer für den TFTP-Server ... die 6490 ist nicht wirklich "modifikationsfreundlich" und soll es eigentlich auch nicht sein, schon die DOCSIS-Spezifikation steht dem - beim derzeitigen Aufbau des FRITZ!OS - deutlich entgegen.
 
Ja das habe ich bemerkt, außerdem ist der AVM Support für die 6490 geradezu Unterirdisch, damit meine ich
1. keine Recovery Firmware
2. Keine normale Firmware auf dem AVM FTP außer Opensource
3. Random Reboots durch DHCP Server Crashes.

Und das ist nur was ich bis jetzt (3 Tage nach Kauf) bemerkt habe.

Allerdings gibt es mit Ausnahme eines USA Imports keine Alternative zu der Retail Fritzbox, und der USA Import hat keine SIP Unterstüztung
 
Hat der USA Import 1. eine Recovery Firmware
2. eine normale Firmware auf dem FTP-Server?
 
Na ja, 1. und 2. sind nun noch kein Grund für ein solches Urteil (jedenfalls in meinen Augen) ... wozu brauchst Du die denn genau? Solange Du an der Firmware nichts verändern kannst (bzw. sollst), brauchst Du auch keine Recovery-Software (oder nur in sehr, sehr seltenen Fällen, wo man dann auch problemlos auf den Austausch zurückgreifen kann).

Die Firmware-Images stehen zwar nicht direkt in den freigegebenen Verzeichnissen auf dem FTP-Server, aber sie sind problemlos zu finden und zu laden. Auch hier wäre die Frage, was Du damit willst - außer darin etwas nachsehen, dann findet man die aber auch bzw. man findet die Threads, wo dann steht, wie man die Images findet. Auch hier wieder die "Vermutung", daß es bei "Nichtfinden" ggf. sogar wieder besser so ist - gerade bei den Leuten, die mit OpenWRT-Erfahrungen dann denken: "Das kann ja nicht so viel anders sein.", ist das schnell mal ein Problem, denn FRITZ!OS ist eben kein OpenWRT.

Punkt 3 würde ich jetzt nicht als generelles Problem sehen ... abgesehen davon, daß man mit so einer "Fehlerbeschreibung" auch nur raten kann, wann und warum der DHCP-Server abstürzt, wäre das bestimmt (wenn es nicht an einer Fehlkonfiguration liegt oder zumindest an einer "eher unerwarteten bzw. ungebräuchlichen", denn ich will auch nicht ausschließen, daß da tatsächlich Fehler im FRITZ!OS sind) schon jemand anderem hier aufgefallen - so neu ist die 06.63 nun auch wieder nicht mehr und sie dürfte auf den meisten Retail-Boxen seit mind. drei Monaten im Einsatz sein.
 
@KunterBunter ich meine damit ein Modem das ich vor einem Router Platziere keine AIO Lösung wie die Fritzbox.
@PeterPawn da kann ich dir nur recht geben das FritzOS ist keine Opensource Software, weshalb der Hersteller der Box hier auch versucht seinen Kunden einen Riegel vorzuschieben durch z.b. Abschalten des Telnet. Die Recovery Software wäre für mich in meiner aktuellen Situation der erste Schritt die Box eigenständig zu "Retten" ohne direkt einen Komplettaustausch durchführen zu müssen. Da es ja aktuell so nicht weitergehen kann. Eine genauere Fehlerbeschreibung ist aufgrund von gelöschten Logfiles durch die 6490 nicht möglich. Ich kann nur sagen das die Box von mir nun 3-5x Werksresettet wurde und dennoch keine Besserung eingetreten ist. An der Box hängt aktuell nichts mehr ausser einem PC via LAN Kabel und dennoch verhält Sie sich weiterhin so das Sie Random Rebootet. Und ein Firmware Upgrade / Downgrade sollte meiner Meinung nach von AVM für zumindest Kunden der Retailvariante definitiv auf Ihren Servern angeboten werden.

Außerdem hatte ich am 25.02.17 den ersten Kontakt zum AVM Support aufgenommen eben wegen der Frage ob es möglich ist auf der 6490 einen TFTP Server aufzusetzten in Kombination mit Cisco IP Telefonen, die Standartantwort war das man mir eine Anleitung zum einrichten eines NAS Laufwerks schickte. Das nenne ich durchaus unterirdischen Support.
 
Zuletzt bearbeitet:
Firmware-Upgrade wird ja angeboten und ein Downgrade über das GUI geht inzwischen (richtigerweise) bei keinem FRITZ!Box-Modell mehr ... für die Richtung "neue Firmware" gibt es das Online-Update. Gibt es eine neue Firmware-Version, kann die Box darüber aktualisiert werden. Die Retail-Version der Firmware enthält sogar die Möglichkeit für das dateibasierte Update, wenn man in der Lage ist, das GUI in den richtigen Modus zu schalten - die Frage, woher man ein Firmware-Image bekommen kann, braucht keine 10 Minuten Recherche. Warum AVM die dateibasierte Variante überhaupt eingebaut hat in die 6490, wissen die Götter ... vielleicht als Option, damit der Support einzelne Kunden gezielt mit Firmware zum Testen einer Problemlösung versorgen kann.

Wenn es bisher für Dein Absturzproblem gar keine Protokolle gibt, stellt sich mir die Frage, woher Du dann weißt, daß der DHCP-Server für die Abstürze verantwortlich ist.

Die Frage des Telnet-Zugangs (allg. eines Shell-Zugriffs) hat auch nichts mit AVM an sich zu tun (oder irgendeiner Gängelei, dazu ist die Umsetzung beim Entfernen des Telnet-Daemons viel zu "stümperhaft", das könnte AVM garantiert auch besser) ... wenn Du die DOCSIS-Spezifikationen kennen würdest (OSSI, Chap. 9.2), würdest Du vermutlich (bzw. hoffentlich) solche Theorien gerade bei der 6490 noch einmal durchdenken.

Abgesehen davon verstehe ich nicht, was Du von einem Recovery-Programm jetzt anderes erwarten würdest (außer daß noch eine "frische Firmware" geschrieben wird), was Du über "Werkseinstellungen" nicht ebenfalls erreichst. Du wirst ja nicht ernsthaft die Theorie verfolgen, daß die Firmware nicht richtig installiert wurde (und das die Ursache der Abstürze wäre) und selbst wenn, dann würde jeder "durchschnittliche FRITZ!Box-Kenner" mit der Fähigkeit zur Internet-Recherche als erstes wohl das System in der alternativen Partition "untersuchen" ... so da eines installiert ist, weil die Box nicht tatsächlich bereits mit 06.63 "geboren" wurde (was dann einen Fehler beim Schreiben eines Updates noch einmal unwahrscheinlicher erscheinen läßt).
 
Wenn AVM also durch irgendwelche Fehlerbeseitigungen im Code von z.b. FritzOS 6.63 einen Bug erzeugt der sich evtl. nur bei bestimmten Geräten (Produktionschargen) zeigt findest du es also Korrekt dem Benutzer keine Möglichkeit zum Downgrade zu geben ? Das es über Online-Update nur die Richtung nach oben gibt sollte wohl selbstverständlich sein. Die Protokolle kommen von meinem PC der kurz vor dem Zusammenbruch der Fritzbox meldet das der DNS Server nicht mehr erreichbar ist. Es ist mir durchaus klar das ein SSH Zugang direkten Zugriff auf die Configfiles geben würde. Das ist hier allerdings nicht meine Intension. Von einem Recovery Programm hätte ich erwartet das eine evtl. angeknackste Firmware durch eine vollständige ersetzt würde. Die Box wurde vermutlich mit der 6.63 Version geboren da es kein Update durch AVM seit installation der Box gegeben hat. Allerdings was mir aufgefallen ist, das bei der Erstinstallation die noch jungfräuliche Box fast eine Stunde gebraucht hat um zu Booten.
 
Wenn eine FRITZ!Box tatsächlich abstürzt, erzeugt sie ein (Backtrace-)Protokoll im Flash-Speicher, das man nach dem nachfolgenden Neustart dann auch auslesen kann. Das erfolgt u.a. im Rahmen der Erzeugung der Support-Daten, wo dann dieses Protokoll (fein säuberlich getrennt nach dem ARM- und dem ATOM-Core) in der bereitgestellten Textdatei in aller Ruhe analysiert werden kann. Da braucht man also nicht raten ... wobei ich den Zusammenhang zwischen "DHCP-Server verursacht Absturz" und "PC meldet: DNS-Server nicht erreichbar" auch (immer noch) nicht verstehe.

Ansonsten ist es vollkommen egal, was ich korrekt finde und was nicht ... es gibt keine (offizielle) Downgrade-Möglichkeit bei der 6490 und wenn man das "nicht korrekt" findet, dann muß man sich eben selbst einen Weg suchen. Sich jetzt hinzustellen und da irgendwelche Wertungen wie "unterirdischer Support" daraus ableiten zu wollen, ändert an der Situation nämlich nicht das Geringste - wenn es tatsächlich eine Firmware geben sollte, die derartige, theoretisch durchaus denkbare, Fehler (nachweislich) verursacht, dann muß eben (bei DOCSIS wohlgemerkt) der Hersteller ran und die nächste Version an die Front werfen, die diese Probleme dann beseitigt. Wenn das jemandem nicht paßt, muß er sich eben selbst zu helfen wissen.

Ich finde es auch nicht in Ordnung, wenn nach der Korrektur von Software für Motorsteuergeräte (damit künftig auch im Regelbetrieb weniger Schadstoffe erzeugt und ausgestoßen werden, nicht nur auf dem Prüfstand) die abrufbare Leistung sinkt ... trotzdem bin ich strikt dagegen, daß jetzt jeder Autobesitzer hingehen und sich mit einem "Downgrade" dafür entscheiden kann, einfach mehr Schadstoffe bei höherer erreichbarer Leistung in Kauf zu nehmen.

Trotzdem ist es bei den DOCSIS-Boxen eben "schon immer so", daß es keine Recovery-Versionen zum freien Download gibt (das kommt also auch nicht überraschend und rechtfertigt damit das "unterirdisch" auch noch nicht automatisch) und Du wirst auch für andere eDOCSIS-Router (von anderen Herstellern) die Firmware (zumindest in der EuroDOCSIS-Variante) nur in eher seltenen Ausnahmefällen zum Download beim Hersteller finden.

Ich weise auch gerne noch einmal darauif hin (oben hat es @KunterBunter ja schon angedeutet), daß Du auch bei anderen Geräten (z.B. "zertifizierte" Set-Top-Boxen für verschlüsseltes DVB-C) keinen direkten Zugriff auf die Firmware hast. Das Breitbandkabel ist nun einmal ein "shared medium" und damit gehen höhere Anforderungen an die "Störfestigkeit" der beteiligten Geräte einher ... einer dieser Störfaktoren ist zweifellos der Besitzer eines eDOCSIS-Gerätes.

Wenn Dich das also tatsächlich stört, suche Dir einfach die richtigen Wege heraus (findest Du hier im IPPF) und lies Dich zunächst einmal richtig ein. Schon die fehlenden Kenntnisse bzgl. der Support-Daten und der speziellen Vorkehrungen zur Sicherung des Absturzprotokolls im TFFS-Treiber solltest Du zunächst einmal beseitigen, bevor Du Dich an einen Shell-Zugang und/oder den "Ersatz" des fehlenden Recovery-Programms machen willst. Durch die eigene FRITZ!Box verursachte Störungen betreffen nämlich - anders als beim DSL, wobei das beim Vectoring auch nicht mehr so ganz stimmt - nicht mehr nur Dich alleine, sondern ggf. auch andere Anschlüsse in diesem Segment und da bin ich häufig durchaus dankbar (auch AVM), wenn es nicht ganz so einfach ist, da irgendwelchen Blödsinn anzustellen (und sei es wegen mangelhafter Kenntnisse, die wenigsten wollen ja absichtlich sabotieren und so stellen sie sich i.d.R. bloß zu blöd an, wenn wirklich etwas passiert).

Ich habe bereits weiter oben betont, daß Du dann bei den von Dir gelesenen "etlichen Threads" recht merkwürdig recherchiert haben mußt, wenn Du bei einer Suche nach "fritzbox 6490 update site:ip-phone-forum.de" nicht direkt mit der Nase auf die richtigen Threads gestoßen wurdest.

Es braucht einfach keinen weiteren Thread, in dem das Thema noch einmal ausdiskutiert wird und ich bin hier nur noch einmal darauf eingegangen, weil Du Dein - nennen wir es: "eigenes Versagen" - bei der Recherche mit einer Kritik an dem fehlenden Recovery-Programm und der fehlenden Downgrade-Möglichkeit (die ja die direkte Folge des Fehlens der Recovery-Versionen ist) in direkten Zusammenhang gebracht hast und weil ich Deine Aussage bzgl. des von Dir festgestellten Problems beim DHCP-Server in der vorgebrachten Form nicht nachvollziehen konnte (und kann).

Es ist auch schwer zu interpretieren, was Du nun unter "1 h Booten" bei der Inbetriebnahme verstehst. Hat es tatsächlich eine Stunde gedauert, bis Du das erste Mal auf das GUI zugreifen konntest? Dann wäre die Box ggf. wirklich defekt, wobei mich für einen solchen Schaden, der die beschriebenen Symptome hervorruft (also sehr langsames Starten, das dann auch irgendwann wieder verschwunden ist, denn ich nehme einfach einmal an, daß Du "permanentes Schleichen" der Box bemerkt und "aufgeschrieben" hättest), schon interessieren würde, wo der seine (theoretischen) Wurzeln haben sollte.

Wenn es lediglich darum geht, wie lange die Box brauchte, bis sie die ganzen Kanäle durchforstet hatte und die Netzwerk-Verbindung zum CMTS dann verfügbar war, dann wäre zwar eine Stunde auch extrem lang, aber 15-20 Minuten sind dann schon mal drin (und es gibt Leute - auch wenn Du sicherlich nicht dazu gehörst - mit einem ganz schlechten Zeitgefühl). Die Box muß/kann dann nämlich - wie jeder andere DVB-C-Tuner auch - erst einmal jeden der denkbaren Kanäle im 8 MHz-Raster absuchen, ob sich dort ggf. ein Kanal findet, der für US oder DS benutzt wird ... und das kann dauern, wenn das Kanalraster sehr gut "belegt" ist. Deshalb merkt sie sich auch, wo sie die DS- und US-Kanäle zuletzt gefunden hatte, damit das beim nächsten Start dann einfacher wird.

Eine "angeknackste" Firmware ist schon sehr, sehr unwahrscheinlich (solange der Kunde da nicht selbst an den Partitionen "herumfummelt" und genau das soll er ja eigentlich nicht können) ... selbst nach einem (erfolgreichen) Update. Da wird jeweils noch ein MD5-Hash über die neu geschriebenen Daten in der eMMC-Partition gebildet und wenn der stimmt, dann kann eigentlich nur noch ein Hardware-Schaden (den der Kunde dann ohnehin nicht selbst beheben kann) als mögliche Ursache für so eine "angeknackste Firmware" herhalten.
 
So Leute,

ich wollte nun mal modfs auf meiner 7490 installieren. Hab aber noch etwas schweissige Haende. "Ich trau mich nicht". Hatte in den letzten Jahren schon oft genug Sachen in Sekunden kaputt gemacht und nach Stunden erst wieder auf den alten Stand bringen koennen. ;-)

Folgendes hab ich vor: Bestehende 6.51 Installation mit Freetz auf 6.80 mit Freetz updaten bzw. in die zweite Partition installieren um es erst mal zu testen.

1) Klar, erst mal Backup der FB-Einstellungen und auch der Freetz-Einstellungen. Recovery-Images hab ich schon hier (die sollen ja aelter als 6.50 sein)

2) Feststellen, welche Partition in der 7490 aktiv ist.
- (ssh läuft schon)
- Derzeit ist die "1" aktiv.
- Frage: Dass schon die "1er" aktiv ist bedeutet aber nicht, das in der "0" noch was drin ist, oder?

3) Umstellen der Partition auf die "0"
- Entweder "switch_system" oder per shell-command.
- Das man damit die Datei "environment" komplett überschreibt ist kein Problem? Es geht nichts wichtiges verloren, oder doch?
- Schaltet man auf eine Partition um, die noch leer ist, gibts dann Probleme bei z.B. einem voreiligen Reboot?

4) modfs installieren und ausfuehren.
- Installation geht soweit klar.
- In den Ausfuehrungen von Eisbaerin steht zu lesen, dass die (erste) Ausfuehrung nur geht, wenn in beiden Partitionen was drin ist. Wenn nicht, koenne man aber die aktive Partition in die leere Partition kopieren. Das hab ich nicht wirklich verstanden. Ist da modfs mit seinen Abfragen selbsterklaerend?
- Nach Abschluss dieses Schrittes sollte doch in beiden Partitionen ein exakt gleiches Image sein. Davon kann man auch booten, nach entsprechendem Umschalten der Partition.

5) Neues Firmware Image installieren
- Nun hatte vor, über das Freetz-GUI das neue Firmware-Image zu installieren, ohne auf Werkseinstellungen zurueck zu setzen (hatte bislang bis zu 6.51er problemlos geklappt).
- Danach muesste in der einen Partition noch die 6.51er sein, und in der anderen die 6.80er. Richtig?

Per "switch_system" kann ich dann doch die Partitionen umschalten und per Reboot die andere Firmware-Version aktivieren.

Mach ich das als modfs-Novize so richtig?

Kann man eigentlich ausschliessen, dass sich modfs und Freetz ins Gehege kommen? Zum Beispiel, dass sie sich gegenseitig in die rc.user oder debug.cfg reinpfuschen. Dann bring Freetz ja die ein oder andere Kleinigkeit schon, die mit modfs auf teils andere Weise dazu kommt. Z.B. das mounten eines USB-Sticks per Label, dropbear bzw. SIAB, Web-Interface per Port 81.

LG, Goggo
 

Statistik des Forums

Themen
246,347
Beiträge
2,250,586
Mitglieder
374,001
Neuestes Mitglied
curious2315
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.