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

Da war wohl die Dateisystem-Partition des alternativen Systems bereits irgendwo gemountet. Das erfolgt (eigentlich absichtlich, aber man kann darüber diskutieren) im "read/write"-Modus, weil bei gelöschtem yaffs2-Dateisystem dann die Verwaltungsstrukturen automatisch initialisiert werden. Jedenfalls erfordert dieses R/W-Mounten dann exklusiven Zugriff auf die Partition - zweimal R/O-Mounten müßte hingegen (theoretisch) funktionieren.

Das BootManager-Skript sollte aber auch direkt nach der Ausführung von "modfs" noch funktionieren, weil dort das aktive System nicht anhand des Wertes von "linux_fs_start" ermittelt wird, sondern sich aus den Namen der Partitionen ableitet. Selbst wenn also durch die Ausführung von "modfs" das System bereits auf die im Moment inaktiven Partitionen umgeschaltet wurde für den nächsten Start, sollte "altfs" immer noch die Partition des alternativen Sets sein und die dürfte (wenn sie nicht jemand anderes mountet) nicht eingehangen sein.

Die Dateisystem-Partition des gerade laufenden Systems muß nicht gemountet werden, um die Version und die Datumsangaben für dieses System zu ermitteln, die ist unter "/wrapper" bereits verfügbar. Für das alternative Dateisystem gilt das nicht und so wird diese Dateisystempartition irgendwo temporär gemountet (eben read/write) und dann werden dort die Daten ausgelesen.

Solange man nicht weiß, welche Version in der anderen Partition liegen sollte, kann man die Frage nicht eindeutig mit "ja" oder "nein" beantworten. Unter Umständen (wenn da kein anderes "mount" existiert) ist der Inhalt der (yaffs2-)Partition zerstört ... das ist ja hier nur das erste "mount"-Kommando und das sollte sowohl unter einem 2.6er-Kernel als auch unter einem 3.10er funktionieren, erst beim Mounten des SquashFS-Images mit dem eigentlichen Root-Dateisystem ergeben sich Probleme wegen der unterschiedlichen SquashFS-Versionen.

Wenn sich das reproduzieren läßt, solltest Du einfach anstelle des Neustarts mal ein "cat /proc/mounts" ausführen lassen ... dann kann man die Ausgabe analysieren und feststellen, ob da die Partition bereits eingehangen wurde und wo das ist. Aus dem Ort läßt sich dann vielleicht darauf schließen, wer dafür verantwortlich ist.

Was man anhand dieser Ausgabe sieht, ist daß die fragliche Partition nicht bereits gemountet ist. Damit steigt die Wahrscheinlichkeit, daß sie ein defektes Dateisystem enthält. Wenn das ohnehin "unbekannt" ist, könnte man einfach mal die betreffende Partition im Flash löschen und dann wird sie beim nächsten Mount-Versuch automatisch neu formatiert, aber da ist ein Update mit "modfs" wahrscheinlich sogar die bessere Lösung. Sollte es ein Hardware-Problem mit der betreffenden Flash-Partition geben, kannst Du jederzeit wieder über den Bootloader auf das jetzt laufende System umschalten.

Man könnte sicherlich die Fehlermeldung auch unterdrücken, dann bleibt nur das "unknown" bei der Anzeige des alternativen Systems übrig ... würde ich eher nicht machen, so hat man wenigstens einen Anhaltspunkt, welches Kommando eigentlich den Fehler verursacht hat.

Nachdem der Thread mit der vereinfachten Anleitung ja nun geschlossen wurde, möchte ich noch einmal das Thema "Dokumentation" hervorkramen (wenn es denn gebraucht werden sollte, mich selbst betrifft das eigentlich irgendwie nicht so richtig, ich komme auch gut ohne aus).

Mein Vorschlag wäre es, daß ich im modfs-Repository in GitHub einen passenden Bereich erstelle und sich jemand, der sich dazu berufen fühlt, einen GitHub-Account einrichtet, dem ich dann für diese Dokumentation die notwendigen Schreibrechte einräume.

"jemand" kann auch mehr als "Eine(r)" sein ... ich würde mich aber (mit Ansage) nicht an der inhaltlichen oder gestalterischen Erstellung von Dokumentationen beteiligen und trotzdem müßte ein Autor es aushalten, wenn ich (technische oder orthografische) Probleme aufzeige (gerne auch per E-Mail, damit sich niemand bloßgestellt fühlt, wenn er/sie sich schon die Arbeit (für andere) macht) und deren Korrektur erbitte.

Als reines Wiki, wo jeder schreiben darf, ist das wohl eher keine richtig gute Idee, hier im Forum funktioniert es offenkundig auch nicht und da fällt mir auf Anhieb nicht so vieles als Alternative ein. Zumal sich GitHub (auch mit den verschiedenen Dokumentationsmöglichkeiten) dafür ja sehr gut eignen würde ... ob man am Ende vom Betreiber von GitHub oder des IPPF abhängig ist, spielt auch keine wirkliche Rolle - da hat das Repo sogar wieder den Vorteil, daß man es problemlos duplizieren und eine eigene Kopie vorhalten kann.

Aber mein Ehrgeiz bei der Dokumentation hält sich (auch wenn ich viel schreibe) dann in Grenzen und offenbar hilft es auch nicht allen, wenn man meine alten Texte mit C&P einfach hintereinander schneidet ... wenn es also einer Dokumentation "aus Nutzersicht" bedarf, dann sollte die auch "ein Nutzer" (oder mehrere) verfassen. Als Einstieg mag man ja den Inhalt des inzwischen geschlossenen Threads nehmen ... aber wenn das jetzt immer mehr veralten sollte, verliert es genauso an Wert, wie meine ersten langen Beiträge zur "Urform" von "modfs" - auch die stimmen natürlich schon eine Weile nicht mehr.

Findet sich niemand, bleibt es eben so wie es ist ... wie gesagt, ich komme auch damit klar.

Kurzform: nein.

Längere Erklärung: vielleicht - nach heftigen Anpassungen, das geht schon beim Schreiben von SquashFS-Images los, das läuft bei der 6490 vollkommen anders.

In Planung: deutliches "nein".

Gründe: siehe anderer Thread - für die 6490 (solange die jemand bei seinem KNB mit dem eCM nutzen will) braucht es das m.E. auch nicht, das kann jeder (hier gehört ein "gefälligst" hin) "von Hand" machen.

Bedenkenswert: Wenn man definitiv sicherstellen könnte, daß bei der Verwendung von "modfs" das eCM danach nicht mehr funktioniert (und das meint nicht falsch, sondern gar nicht mehr), würde ich ggf. darüber nachdenken (auch wg. EPG und für Versuche mit Smartcards, denn die Firmware enthält sogar Teile von Intel für deren Unterstützung), aber ich sehe nicht, wie das gehen sollte.

Optionen: Sollte sich jemand anderes zu "modfs for 6490" berufen fühlen, kann ich es auch nicht verhindern - habe ich unter GPL gestellt, kann/darf/soll jeder selbst ändern.

Bei Verwendung des AVM-Recovery-Programms wird die aktive Partition überschrieben. Das würde ich also nicht in dem Moment aufrufen, wo die verbliebene Partition mit dem Telnet-Zugang aktiv ist, dann sind beide Partitionen ohne Telnet (oder andere Änderungen).

Mich plagt hier die Frage, warum Du nicht einfach sowohl "linux_fs_start" als auch "firmware_version" per FTP von Hand so einstellst, daß die verbliebene Partition mit einer geänderten Firmware (ich habe es so verstanden, daß nur eine Partition die "falsche" Firmware enthält) gestartet wird? Dann kann man von dort aus erneut das Modifizieren für die (dann inaktive) Partition angehen, die versehentlich direklt mit dem AVM-Update aktualisiert wurde.

Zum Rest: Mich interessiert hier nur das Ergebnis, aber auch ich fand natürlich den zwischenzeitlich eingetretenen Zustand nicht so schön und habe Deine Reaktion an der Stelle auch weder verstanden noch gebilligt - nur damit es nicht den Eindruck erweckt, ich würde hier nicht "Farbe bekennen" wollen. Das ist aber für mich gegessen und soll kein Thema mehr sein ... ich war auch nur indirekt beteiligt.

Ich habe jedoch den Eindruck, daß @eisbaerin entweder in einem sehr langen Urlaub ist oder die Lust verloren hat oder einen "Anpfiff" an anderer Stelle sich so zu Herzen genommen hat, daß das IPPF dort auch vom Tisch ist (was angesichts vieler dann verwaister "Übersichten" auch nicht so ideal wäre).

Wenn es also ein Interesse an einer "Benutzer-Dokumentation" für "modfs" geben sollte (die nächste "Änderungswelle" kommt bestimmt (auch von AVM) und spätestens bis Weihnachten habe ich die 7580 auch in "modfs" integriert), dann muß man das in Angriff nehmen. Es gab einmal einen weiteren "Bereitwilligen" für eine solche Dokumentation, das war m.E. @andiling. Auch von ihm liest man in letzter Zeit wenig ... da wird wohl auch die Zeit knapp oder das Interesse verloren gegangen sein.

Auch wenn ich das IPPF bisher für die Veröffentlichung und Beschreibungen genutzt habe (Beschreibung hier, Code auf meinem eigenen Server), ist das ja nun Anfang Januar 2016 alles zu GitHub umgezogen und da dort auch die Möglichkeit der Dokumentation besteht (das ist ja weit mehr als nur eine Versionsverwaltung für Programm-Code), gehört es m.E. ohnehin dort hin - da ist es dann auch vor Löschungen (und die müssen nicht einmal absichtlich erfolgen, die vBulletin-Software kommt immer wieder mit Lücken "in die Nachrichten", wobei die Angreifer mehr und mehr dazu übergehen, die Daten abzugreifen und den Forenbetrieb eher nicht mehr zu stören - die Update-Pläne des IPPF nach der Pleite am Beginn des Jahres sind vermutlich auch wieder still beerdigt worden) und anderen Problemen schon dadurch relativ sicher, als man dort problemlos "externe Kopien" (extern zu GitHub, denn auch deren Server sind nicht unfehlbar) erzeugen und jederzeit neu synchronisieren kann.

Ansonsten gilt genau das von mir Geschriebene ... ich habe nicht die Absicht, mich aktiv am Inhalt (oder der Form) zu beteiligen, würde aber "das Recht" (und die Pflicht) sehen, falsche Informationen "anzuprangern" (auch "nicht-öffentlich", wenn es sensible Gemüter geben sollte - die Wahl des Verbes war ja bewußt "krass") und Korrekturen "zu fordern".

Es bringt ja auch nichts, wenn eine solche Dokumentation zwar verständlicher für Benutzer ist als meine Texte, dann aber "haarscharf" an den tatsächlichen Gegebenheiten vorbeischrammt. Da, wo das Leser A nicht stört, steht Leser B dann vor einem (weiteren) Verständnisproblem, wenn die Beschreibung nicht zum Verhalten (oder zum Code, wenn er den kontrolliert) paßt.

Ich bin also der Meinung, daß eine solche Anleitung ohne Feedback meinerseits (und natürlich auch der Zielgruppe, für die sie eigentlich geschrieben wurde) nicht funktionieren wird - es gibt aber auch Leute, die bei "Maulen" meinerseits dann zu der Feststellung gelangen könnten: "Dann schreib' das doch selbst." und um da spätere Mißverständnisse gar nicht erst aufkommen zu lassen, habe ich das von Beginn an klarstellen wollen.

Ich will es nicht selbst schreiben - ich habe auch mit Änderungen/Refactoring beim "modfs" genug zu tun, denn auch für mich kommt das nächste AVM-Release garantiert und wer weiß, was man sich dafür wieder einfallen läßt in Moabit (gibt vermutlich sogar Leute, die einen Umzug von der 85 95 (EDIT: vertippt) in die 12a für notwendig erachten, wenn AVM ihnen mal wieder voll in die Parade fährt, obwohl sie ja niemand zwingt, AVM-Geräte zu kaufen und zu benutzen, das ist immer noch freiwillig - erst recht seit dem 01.08. dieses Jahres und daß die Firmware insgesamt sicherer geworden ist, ist hoffentlich unumstritten).

Als Klarstellung für den unbekannten und still leidenden Leser, wenn die Diskussion jetzt wieder in diesen Thread getragen wird:

#1, EDIT vom 06.11.2015, Satz 2

Bei mir funktioniert das auf einer ext3-Partition auch problemlos.