[Problem] Fritzbox 7362SL keine Funktion mit 6.50 Fw

Hallo Gismotro,

ich habe ähnliche Erfahrungen wie Du mit FW 6.50 und Freetz für Fritz!Box 7362SL gemacht. Config ist bei mir zwar ziemlich voll (ich nahm ein altes funktionsfähigen Config von Freetz für FW 6.20). Das Bauen der Image ging mit Freetz-Linux bis auf einen kleinen Fehler mit "gettext" sauber durch (konnte gepatcht werden). Das Flashen selbst ging aber weder über die Freetz- (Firmware: 131.06.20 rev29220) noch über die Fritz!Box Web-Oberfläche aus mehr. Das Image wurde in beiden Fällen hochgeladen (keine Fehlermeldungen im Freetz-Update Fenster), die Box wurde auch neu gestartet, aber das Flashen kam doch nicht zustande. Ich kriege dabei keine Fehlermeldungen, und das System bleibt beim alten Stand (6.20). Ob der Flash-Speicher knapp ist, oder die Post-Installation nicht klappt, kann ich leider nicht sagen.
Ich denke, wir müssen noch etwas gedulden, bis Freetz für FritzOS 6.50 aud der 7362SL auch von anderen getestet wird.
Gruß,
Laci

Es wird doch sicherlich möglich sein, einfach mal eine Telnet-Session (und zwar "die Erste", in der auch die Ausgaben auf /dev/console sichtbar sind) mitlaufen zu lassen und die Ausgaben von /var/install (das ist ja - weitgehend - die originale Version von AVM, ob da die modsed-Änderungen bzgl. ext2-Image wirksam werden, weiß ich selbst gar nicht - die 7362SL interessiert mich (mangels Gerät) nicht persönlich) bei der Aktualisierung der Partitionen protokollieren zu lassen.

Die (zumindest meine) hellseherischen Fähigkeiten sind in aller Regel stark unterentwickelt - da muß man dann zu solchen ungewöhnlichen Mitteln greifen, um doch noch irgendeine Erklärung für diese Probleme zu finden.

EDIT: Wenn jemand "Freetz-geschädigt" ist (da wird m.W. kein "getcons" in der /etc/profile gemacht), dann kann man das notwendige Kommando ja auch von Hand in der Shell-Session eintippen - solange es für kein anderes Pseudo-Terminal aktiv ist, kann man das dann auch in einer zweiten, dritten (usw. in arithmetisch aufsteigender Folge) Session noch ausführen.

Du "sollst" das (Console-)Protokoll des Flash-Vorgangs liefern ... da der noch von einer lauffähigen Version aus erfolgen sollte, dürfte das kein größeres Problem sein.

Wir reden aber schon von einer 7362SL, oder? Warum kannst Du die nicht einfach per Bootloader-FTP wieder auf das andere System umschalten?

Du mußt nichts weiter machen, als eine Shell-Session zur FRITZ!Box aufzubauen (keine Rudi-Shell oder ähnliche Faxen) und dann das Image über das Freetz-Interface flashen lassen. Dabei erhältst Du als erstes ein Protokoll des Aufrufs von /var/install (EDIT: noch in der Freetz-Oberfläche) und dann gibst Du im Telnet-Fenster (oder meinetwegen auch SSH, entscheidend ist, daß der Daemon "durchläuft" und nicht als allererstes gekillt wird) nach dem Entfernen von "telnetd" aus der Liste der zu stoppenden Daemons ("vi /var/post_install" zum Editieren, bei der Gelegenheit kannst Du dann auch noch den Inhalt der /var/post_install hier irgendwo anhängen - bitte in passenden Tags oder wirklich als Anhang) den Aufruf von "/var/post_install" ein und hebst die Ausgabe in dieser Sitzung ebenfalls auf.

Anders als bei NOR-Modellen wird ja nicht mit dem Laden des Flash-Treibers bereits der Neustart der Box absolut unumgänglich ... die post_install wird ganz normal abgearbeitet, dabei werden alle möglichen Dienste beendet, das System in der inaktiven Partition ausgetauscht und "linux_fs_start" neu gesetzt. Das kann man theoretisch (wenn man "linux_fs_start" wieder auf den originalen Wert zurücksetzen würde) sogar beliebig oft wiederholen ... es geht darum, ob die /var/post_install von der /var/install richtig geändert wird und dann die /var/post_install alle notwendigen Kommandos (in erster Linie "update_kernel" und das Mounten bzw. Kopieren des Inhalts für das ext2-Image) richtig ausführt. Wenn Du vor dem Neustart der Box (dann am besten durch "Steckerziehen") noch die Variable "linux_fs_start" auf den ursprünglichen Wert zurückänderst, brauchst Du auch nicht schon wieder das Recovery-Programm bemühen.

Ich habe mich allerdings auch noch nicht der Mühe unterzogen und überhaupt in die /var/install für die 7362SL hineingesehen ... wenn AVM da etwas Grundlegendes geändert haben sollte (am besten mit der aus einem 7490-Image vergleichen), könnte Freetz da auch auf Granit beißen. Da "modfs" sich überhaupt nicht um den Inhalt der /var/install kümmert (das wird ja alles "zu Fuß" gemacht), fällt mir so etwas grundsätzlich nicht auf, bis man gezielt nachforscht.

Ja und nein ... immerhin sieht man an der post_install (ich schrieb ja eigentlich nicht von den Skriptdateien selbst, sondern vom Protokoll von deren Aufruf) wenigstens, daß da von /var/install etwas hineingeschrieben wurde.

Die Option zum Mounten mit Offset ist ja von er13 erst nachgerüstet worden ... was sagt denn der Aufruf von "mount --help" (oder so ähnlich) bei der Busybox in dem System, von dem aus das neue geschrieben werden soll?

Ansonsten sieht das auf den ersten Blick erst einmal richtig aus ... aber mein Gehirn ist auch kein Shell-Parser und diffizile Syntax-Fehler würden eher nicht auffallen - ich dachte sogar schon, mit der fehlenden Einrückung für die Kommandos vor einem "fi" die Ursache gesehen zu haben, das war aber ein Irrtum.

Also ... Ausgabe der "usage"-Seite von "mount" und Ausgabe der Abarbeitung der /var/post_install - dann kann man weitersehen.

Ich könnte mir noch vorstellen, daß durch ungenügendes Abräumen von Diensten vor dem Aufruf von post_install und durch das Fehlen der Möglichkeit, das ext2-Image auch ohne "dd" zu mounten (egal ob über das "mount" von er13 oder über "losetup", das Prinzip ist hier das Entscheidende) der Platz im tmpfs bei den kleineren Modellen (die haben ja nur 128 MB RAM) noch enger wird und dann - je nachdem, wie groß das von Freetz erstellte Image am Ende ist - der Platz im tmpfs für das "dd" einfach fehlt. Gerade dann wäre der Weg über das Mounten eines ext2-Images am Offset 256 unabdingbar ... also würde ggf. schon das Erstellen eines "Starter-Images" für Freetz (das praktisch keine Pakete enthält) als Basis für das "richtige Update" u.U. helfen.

Aber auch das ist reines Schlußfolgern ... die Ausgabe von post_install sollte das ziemlich schnell aufklären können und dann braucht man nicht raten.

Hallo PeterPawn,

ich habe das Update von der telnet Konsole aus wiederholt. /var/install sowie /var/post_install wurden dabei ausgeführt. Ich kann im Console-Log nichts ungewöhnliches erkennen. Vielleicht sagt es einem Experten mehr.
Symptome:
1. install u. post_install läuft ohne Fehlermeldung durch,
2. Box startet sich automatisch neu
3. FW bleibt auf dem alten Stand (6.20)

Gruß, Laci

Vielleicht sagt es jemand anderem tatsächlich mehr (um "Klassifizierungen" zu vermeiden) ... aber dazu müßten andere ggf. auch einmal sehen, was da im Log stand/steht?

Ich würde mich sogar auf den Standpunkt stellen, daß es nahezu unmöglich ist, daß beide Skript-Dateien ohne Fehler ausgeführt werden (die /var/install schreibt ja die passende /var/post_install) und im Anschluß (die letzte Aktion bei fehlerfreiem Verlauf ist dann die Umschaltung auf das neu geschriebene System) startet weiterhin das alte System. Irgendetwas muß dazwischen einfach schief gegangen sein.

Wenn man das in der Konsole selbst nicht genau sehen kann, ruft man post_install mit der Kommandozeile "sh -x /var/post_install" auf - dann wird jedes Kommando aus der Datei protokolliert.

BTW ... wenn ich das beim zweiten Mal noch anders verstanden habe und da tatsächlich die /var/post_install von Hand aufgerufen wurde, dann gäbe es keinen regulären Grund, warum die Box neu starten sollte ... das kann dann fast nur "memory pressure" sein, was da dank der Einstellungen im sysfs zu "kernel panic" führt.

Macht es bitte nicht komplizierter als nötig ... als Schritt-für-Schritt-Vorschlag sähe das so aus:

1. Image über die Freetz-Oberfläche auf die Box bringen, dabei entsteht nach meiner Erinnerung ein Protokoll der Abarbeitung der /var/install, weil diese von Freetz aufgerufen wird.
2. An die Stelle des GUI-Buttons "Zum Flashen jetzt neu starten" (oder so ähnlich, bitte nicht wörtlich nehmen) tritt dann eine Telnet-Session.
3. Editieren der Datei /var/post_install und die Zeile löschen, die sich auf den "telnetd" bezieht (sonst wird der vor dem Flashen noch gekillt und wir wollen ja etwas sehen). Diese Zeile ist sehr leicht zu finden ... das dürfte gar kein Problem werden.
4. In der Shell jetzt "sh -x /var/post_install" aufrufen.
5. Beide Protokolle (einmal vom Upload über das Freetz-GUI und einmal den Aufruf von post_install) hier einstellen.

Dauer: ca. 10 Minuten, wenn man das Image bereits hat und solange sich beim Neustart nichts ändert, ist auch die "Nachbereitung" ja eher unaufwändig.

Das ist mit ziemlicher Sicherheit nur irgendein kleineres Problem beim Entpacken des Images - wenn die Box tatsächlich ohne weitere Nachrichten in der Console neu startet, weil der Hauptspeicher nicht ausreicht, ist das auch schnell umgangen ... aber man sollte eben erst einmal sicher wissen, daß es auch tatsächlich daran liegt.

Wie man "memory pressure" dann entgegenwirken könnte (es gibt zig verschiedene Möglichkeiten), schreibe ich erst, wenn wir sicher sein können, daß das auch die Ursache ist - ansonsten wäre es doch verschenkter Aufwand.

Trotzdem noch einmal die (m.E. irgendwo auch in deisem Thread schon stehende) Anmerkung: Wenn man erst einmal ein minimales Starter-Image mit Freetz flasht und das enthält dann die notwendigen Kommandos zum Mounten mit Offset ohne Verwendung von "dd", dann könnte auch das schon ausreichend sein - das war doch bei der 7490 am Beginn auch nicht anders (denkt mal an das "sync" zurück), daß da nur die Busybox nicht den Erwartungen von Freetz bzw. AVM entsprach, weil entweder Applets fehlten (aus Freetz-Sicht) oder es noch erheblichere Unterschiede gab (aus AVM-Sicht).

@gismotro:
Punkt 3 hast Du ja offenbar eben gerade nicht (zumindest nicht richtig bzw. in vollem beschriebenen Umfang) ausgeführt, wenn da von post_install am Beginn
ausgeführt wird. Ich hatte ja genau versucht zu beschreiben, daß man diese Zeile zuerst entfernen muß, weil sonst der Telnet-Daemon als zweites abgeschossen wird. In Deiner post_install (siehe die von Dir angehangenen Dateien) gibt es nun genau eine einzige Zeile (nämlich die Nummer 6), die überhaupt den Begriff "telnetd" enthält und die muß eben gelöscht werden. Dann muß man das Ergebnis natürlich auch noch abspeichern und darf auch nicht auf die Idee kommen, noch einmal mit der /var/install zu beginnen, denn die schreibt ja dann die /var/post_install auch wieder neu und dann ist da auch wieder das Beenden des Telnet-Daemons dabei.

Irgendwie verstehe ich gerade die Welt nicht so richtig ... :gruebel:

PS: Das Recovery-Programm verrät einem auch immer nur, mit welcher Firmware-Version die Box das letzte Mal so weit gestartet wurde, daß es bis zur Abarbeitung eines bestimmten Skripts im Rahmen des Init-Prozesses gereicht hat ... m.W. wird dort lediglich der Inhalt von "firmware_info" angezeigt und die wird bei jedem Neustart der Box vom gerade startenden System (aber eben erst dann, wenn da wenigstens Kernel und Dateisystem schon laufen) neu geschrieben. Das ist also max. ein "Anhaltspunkt" dafür, daß der neu zu schreibende Kernel und/oder das Dateisystem nicht funktioniert, was das Recovery-Programm da zum besten gibt.