Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
OK, ich dachte, es wäre ein bekannter Fehler, deswegen habe ich die Infos kurz gehalten. In dem Beitrag oben habe ich die komplette Ausgabe von showshringbuf modfs angehängt und die alten Infos gelöscht. Danke Dir, dass Du mal reinguckst!
Ok, das ist ein Anwendungsfall (das existierende System noch einmal installieren und dafür aber eine füher gespeicherte, lokale SquashFS-Kopie zu verwenden), den ich kaum noch auf dem Schirm hatte und wo es wohl auf verschlungenen Wegen noch dazu kommt, daß als Arbeitsverzeichnis automatisch (will sagen, ohne Nachfrage) das "tmpfs" gewählt wird.
Ich würde es noch einmal versuchen, dabei aber eine neue Version von AVM laden lassen ... den Teil habe ich etwas ausführlicher getestet und dabei sollte dann das Entpacken auch auf den USB-Stick erfolgen (schon weil das mehr Platz braucht) und nicht in den (ohnehin raren) Speicher. Zwar wird bei der Wiederverwendung des SquashFS-Images weniger Platz benötigt (weil weder Kernel noch Wrapper neu geschrieben werden), aber beim Einpacken kommen sich dann der Speicherbedarf des Programms und der freie Platz im "tmpfs" (der ja dynamisch ist) wohl doch ins Gehege.
Das wäre jedenfalls die erste Diagnose ... wenn's mit Neuladen des Images von AVM auch nicht klappt, schaue ich noch mal drauf - hier liegt der freie Platz im "tmpfs" (mit ~105 MB) immerhin ganz knapp über dem, was ich früher mal bei der 06.3x ermittelt (104 MB) und seitdem nicht mehr angepaßt hatte.
Wenn das andere auch nicht funktioniert (also der "frische Download"), kann man auch durch die zusätzliche Angabe von "MODFS_WORKING_DIR=/var/media/ftp/Storage-00" (das ist schon auf den konkreten Mountpoint hier angepaßt und für andere also nicht zum Nachahmen empfohlen) beim Aufruf (vor dem "modfs" angeben in der Zeile) einfach dafür sorgen, daß garantiert auf den USB-Speicher entpackt wird.
Ich bin da ohnehin gerade am Ändern und will diese "alten" Funktionen mit dem gespeicherten Image nicht unbedingt auf Dauer halten (weil die jeweils nur für eine konkrete Box sinnvoll sind - auf einer anderen steht das Image wieder ganz woanders bzw. bei zwei USB-Volumes (oder mehr) könnte jedes so ein SquashFS-Image als Vorlage enthalten) - daher will ich da jetzt nicht noch mehr Aufwand hineinstecken; es ist eben doch ein eher seltenes Vorgehen, daß man dieselbe Version erneut installiert.
Sorry für die später Antwort. Den von Dir beschriebenen Weg hatte ich auch bereits ausprobiert...mit dem gleichen Ergebnis. Nach Deiner Antwort habe ich nun jedoch noch zusätzlich gesagt, dass er das Image für die spätere Verwendung NICHT auf dem USB-Stick zwischenspeichern soll und damit ging es. Vielleicht war es ein Zufall oder ich habe vorher einen Fehler gemacht. Kann ich nicht beurteilen, weil ich den Code nicht kenne/100% verstehe.
Ich bin auf jeden Fall sehr glücklich, da meine rc.user-Schwierigkeiten mit der jetzigen Software komplette behoben scheinen.
Vielen Dank für Deine Unterstützung und Deine ganze Arbeit!
habe meine 7490 auch auf 7.01 geupdatet. Seitdem stürzt die Box aber manchmal ab. Kann ich irgendwie sehen warum? Kann ich die modfs Version update oder nur die Firmware?
Der von mir bereitgestellte "dropbear" akzeptiert ausschließlich Authentifizierung mit Keys und verwendet das FRITZ!Box-Zertifikat für seinen eigenen Key ... die "public keys" der Berechtigten muß man halt erst mal auf der Box so speichern, daß da nicht einfach ein Fremder einen weiteren Eintrag in "authorized_keys" hinzufügt und damit vollen Zugriff erlangt.
Das einfachste ist das Anlegen eines "home directory" für den "root"-User im "tmpfs" und das Entpacken eines zuvor validierten TAR-Files mit diesen Keys (und allem anderen, was man gerne im Home-Directory auf der Box hätte) in dieses Verzeichnis.
Das sind aber alles Vorgänge, die man auf jeder Box selbst ausführen muß und wo ich meinerseits keine "Vorarbeit" leisten kann, indem ich etwas Fertiges bereitstelle ... jedenfalls sehe ich nicht so richtig, wie das aussehen sollte.
Als sichere Variante für den "Einstieg" bietet sich ja immer noch SIAB an und für die anderen Möglichkeiten stelle ich zwar ein paar Binärdateien zur Verfügung (aber irgendwie auch eher "außerhalb" von "modfs"), aber keine fertigen "modscripts" ... einfach weil das nicht nur mit einem "patch" oder "sed" geregelt ist, so einen Dienst dem System hinzuzufügen.
Enthalten sind die Änderungen der bisherigen 0.5.1 und die notwendigen Änderungen, damit
die Versionsnummern mit "Vornull" auch dann richtig behandelt werden, wenn Ziffern nicht ins Oktalsystem passen
die neue Speicherung von Versionsnummern bei AVM in der aktuellen Labor-Reihe berücksichtigt wird
Was geht im Moment nicht?
LED-Anzeige patchen - da muß ich erst mal schauen, wie das bei AVM jetzt aussieht und ob die nun komplett wegfallen kann (weil AVM nicht nur an/aus, sondern auch "verzögert aus" anbietet) oder ob sie geändert werden muß
die Seite "system/reboot.lua" wurde komplett umgekrempelt ... neben der korrekten Behandlung der Versionsinformationen krankt der Boot-Manager im Moment also auch noch an der Integration in das AVM-GUI ... sprich: Auf den muß man im Moment auch noch verzichten, wenn es um die neue Labor-Reihe geht
Also ich habe meine 7490 schon länger mit modfs und 7.01 laufen, ohne Probleme. Zum Thema Dropbear, den habe ich mir gleich mit in die Firmware mit eingearbeitet, mit einem Standardkennwort, welches geändert dann im NAS gespeichert wird. Beim Factoryreset der Box, bleibt Dropbear mit dem Standardkennwort aktiv, da der NAS ja formatiert wird. Telnet und SSH sind aber auf meiner Einsatzbox deaktiviert, kann sie erst bei Bedarf aktivieren. Auf meiner Testbox (7490 7.01) sind beide immer aktiv, auch nach Werkseinstellungen. An meiner dritten Box (gebraucht, 6.83 und Provideradditive), und jetzt bräuchte ich Peters Hilfe dafür, habe ich noch keinerlei Shell Zugang. Aus dieser Box möchte ich die Provideradditive rauskopieren. Mit den erweiterten Supportdateien hat es nicht geklappt. Jetzt wollte ich in die ungenutzte Partition die 6.50 per ADAM2 direkt flashen, um dann SIAB drauf zu laden und die /var/flash/provideradditive.tar auf den NAS zu cut(ten). Leider schaffe ich es auch nach drei Tagen nicht mit eva-to-memory eine originale AVM FW da reinzupacken und die kompletten ADAM2 Befehle (auch wenn es ja übers RAM geflasht wird) zu finden. Gibt es da ne detaillierte Anleitung?
Ich würde gern mal die provideradditive.tar genauer anschauen, evtl. auf ner anderen Box testen, ob man die wieder laden kann, usw.... und evtl. ne eigene konfig basteln, je nachdem was alles an Infos da drin steckt.
Was heißt das genau? Wurden die nicht erstellt oder läßt sich darin kein TFFS-Node mit der Minor-ID 29 finden? Wenn letzteres der Fall ist, könnte das auch problemlos daran liegen, daß da tatsächlich keine Daten drinstehen und nur der "Schutzeintrag" im Environment (Variable "provider") noch vorhanden ist - warum auch immer das so gekommen sein mag.
Das Einfachste wäre es, die Box auf Werkseinstellungen zu setzen (dabei bliebe Node 29 ja erhalten) und dann aus dieser "frischen" Box die Support-Daten (erweitert) zu speichern ... ist dort im TFFS-Dump dann kein Node 29 enthalten, gibt es auch keine "provider_additive.tar" mehr in dieser Box und man sollte die Schutzvariable ebenfalls löschen.
Danke für die schnelle Antwort. Die provider additive sind vorhanden. Nach Werkseinstellung ist ein DSL Provider eingerichtet, der in der normalen FW nicht vorhanden ist. Erweiterte Supportdaten erstellt er, mein Problem ist aber das ich kein System habe, wo deine YourFritz scripte laufen. Eingeschränktes Windows System, da Geschäftsrechner und auf meinem Linux Server (CentOS) fehlt ein Binary wo ich nicht nachladen kann. Von der anderen Box aus ging es ebefalls nicht. Mir fehlt einfach aktuell ein Rechner dafür.
Das kann man aber auch in irgendeiner VM erledigen oder in einem ähnlichen System ... notfalls sogar auf einem RasPi.
Ich sehe jedenfalls nicht, was ich da helfen sollte ... ein weiterer Weg, der genau zu den vorhandenen Möglichkeiten paßt, kann zwar erdacht und beschrieben werden (wenn man die Einschränkungen exakt kennt), aber ich würde das natürlich nicht umsetzen. Da ist der Weg, sich einfach ein passendes System zu beschaffen, dann doch der logischere.
Zumal man ja einfach die Daten aus der Support-Datei ausschneiden und "von Hand" zumindest mal in die Binärform bringen kann ... danach kann man dann sogar mit einem Hex-Editor nach den Daten suchen und der sollte wohl (und sei es dreist als "viewer" - also read-only) auf irgendeinem System zur Verfügung stehen.
Alternativ vielleicht eine 6.98er Inhaus-Version installieren (Telnet oder SIAB bereits vorhanden). Von da aus könnte man auch ohne geeigneten Rechner oder Zugriff auf den Bootloader das Provider-Additive per Konsole sichern, anschließend die Schutzvariable im Environment löschen und zu guter Letzt modfs darauf nutzen für ein Update auf eine modifizierte 7.01. Oder übersehe ich da was?
Wenn nur der Shell-Zugang das Problem ist, kann man ja auch problemlos zum "implant_siab"-Image greifen ... für die 7490 ist das bereits vorgefertigt.
Ich überblicke "die Aufgabenstellung" irgendwie auch nicht richtig bzw. vermutlich nicht komplett - denn die einfache Installation des Shell-Zugangs über SIAB ändert natürlich ebenfalls noch nichts an einer ggf. vorhandenen "provider_additive.tar". Ja, nicht einmal ein Zurücksetzen auf Werkseinstellungen würde den SIAB-Zugang deaktivieren .. .im Gegensatz zum Update oder zur Verwendung des Recovery-Programms (was hier ja wegen der Schutzvariablen wieder ausfällt).
Ja genau, es geht nur um einen Shell Zugang. Werde es mal mit einer Inhaus Versio probieren. An die hab ich nicht dran gedacht, ansonsten die andere SIAB Variante. Danke trotzdem.
erstmal vielen Dank für das Modfs... Damit kann ich weiterhin das bisschen Perl-Hausautomationsskript stromsparend auf der Fritzbox betreiben und spare mir nen extra RaspPI.
Was mir beim Schritt zu 7.01 aufgefallen ist, da Telnet immer weiter beschnitten wurde:
Ich würde Telnet gerne mittels der DTrace-Tastenkombi an- und ausschalten, hab es sogar geschafft das Skript rauszukopieren und ausführbar zu machen. Leider scheitert es dann an was ganz einfachen:
Du frägst auf den "-dect" Parameter ab. Das ist aber bei mir aus (und kann auch nur für kurze Zeit eingeschaltet werden, da kein DECT Telefon, sondern nur Analog).
Wenn ich die Dect-Einrichtung starte und dann die Tasten-Kombi mache gehts.
Ich weiß nicht, was der Hintergrund für die "-dect" Abfrage ist, aber wenn es kein sonderlich tiefer war, wäre meine Anregung nicht darauf zu prüfen...
Dieser Parameter ist (nach meinen Tests) der Unterschied gewesen zwischen der Aktivierung von "dtrace" über den Telefon-Code (was ich zweckentfremden wollte) und über das GUI (auf der Seite mit dem Paketmitschnitt).
Ich habe mir bisher keine großen Gedanken darüber gemacht ... aber ich sehe ein, daß es ohne aktivierte DECT-Basis schwer sein könnte, den Parameter in die Zeile zu bekommen - und die läßt sich ohne angemeldetes Gerät gar nicht so einfach aktivieren.
Ich denke da bei Gelegenheit noch einmal drüber nach ... wobei die Möglichkeit der Aktivierung über die "dtrace"-Tastencodes nach meiner Ansicht deutlich schlechter "angenommen" wurde, als die Aktivierung des "inhouse mode" nur für den "telefon"-Daemon (und dann gehen die alten Tastencodes ja wieder).
Ja - sowas hatte ich schon befürchtet.
Wie gesagt, es geht, wenn man den Paarungs-Assistenten anschaltet. Dann läuft dect eine Weile.
Das mit dem Inhouse-Mode hab ich hier bislang überlesen, ... wirklich einladend wirkt er aber auch nicht auf mich. Ich hab noch nicht ganz nachvollzogen (sprich hier nachgelesen) was der genau macht, aber es wirkt auf mich ein wenig wie die Büchse der Pandora, die alles mögliche bewirkt / bewirken kann. Da wäre mir im Zweifel ein laufender Telnet Dämon lieber.
