[Problem] Fritzbox 7362SL keine Funktion mit 6.50 Fw

[PeterPawn]

Jo, schande über mich!

Das hast Du falsch verstanden ... weder "neu sein" noch etwas nicht wissen ist schändlich, ich bemängele es nur, wenn man die erkannten Wissenslücken nicht füllen will und lieber so lange hin und her probiert, bis es dann mal - mehr oder weniger zufällig - funktioniert. Soll man das dann bei der nächsten Gelegenheit wiederholen, geht es dann nämlich von vorne los ... bis einem wieder der Zufall zu Hilfe kommt. Daher bringt es (meiner Meinung nach) durchaus etwas, wenn man es gleich richtig macht und dann auch versteht, warum das nun auf einmal doch funktioniert - dann macht man es bei nächsten Mal eben gleich richtig und spart dort die Zeit wieder ein, die man beim ersten Mal investiert hat.

Das gilt auch für die Freetz-Toolchain ... wenn Du Dir helfen läßt (dazu gehört auch die eigene Suche nach vielleicht schon besprochenen Lösungen für genau dasselbe Problem), sollte das auch keine große Hürde sein. Wobei eben im Moment aus Prinzip die Pakete nicht funktionieren, die ein Ersetzen des Linux-Kernels erfordern ... das gilt wohl für alle Modelle mit 06.5x auf der Basis eines 3.10-Kernels.

OT/@er13:
Ob Du vielleicht noch einmal hingeht und das Ersetzen des Kernels als "developer only" markierst, bis der erste eigene Kernel auf einer VR9-Box erfolgreich getestet wurde, weiß ich nicht ... ich würde erst einmal dafür plädieren (ich bin mir sicher, Du liest auch diesen Thread), weil dann die Gefahr nicht mehr besteht, daß sich jemand versehentlich einen nicht funktionsfähigen Kernel erstellt (auch solche Tickets gab es in letzter Zeit ja, wo einfach nicht klar war, daß der NFS-Support auch das "replace kernel" auslöst).

Die im anderen Thread berichtete Anfrage an AVM bzgl. korrigierter Quelltext-Pakete wurde jetzt abschließend dahingehend beantwortet, daß die Quellen überarbeitet wurden und nur die Nachricht an mich versehentlich nicht erfolgte, weil der Support seinerseits von der Entwickler-Abteilung nicht benachrichtigt wurde.

Ich kann es noch nicht so richtig glauben, daß die jetzt komplett sind (es sind die vom 01.06. und auch Du hattest ja im anderen Thread den neuen Stand mit dem älteren verglichen und außer ein paar geänderten Pfaden gab es keine Unterschiede) ... aber ehe ich jetzt etwas Falsches behaupte, will ich erst noch einmal ganz von vorne (und mit paralleler "Dokumentation" der Schritte in einem extra dafür eingerichteten Thread) mit dem "make" für die buildroot-Umgebung auf der Basis der AVM-Pakete beginnen. Vielleicht bewirkt die Änderung des Pfades ja genau das notwendige Wunder ... ich habe zwar mit "grep" über alles gesucht nach den fehlenden Teilen, aber vielleicht ist ja auch mein "Suchbegriff" der falsche gewesen. Lieber noch ein paar Mal die eigenen Fehler in Betracht ziehen und ausschließen, ehe man jetzt aufschreit, daß es immer noch nicht behoben sei. Ich unterstelle AVM erst einmal, daß man dort den Inhalt der "Fehlermeldung" verstanden hatte und das nun veröffentlichte Paket dann auch selbst auf Funktionsfähigkeit geprüft hat ... also liegt es bis zum Beweis des Gegenteils erst einmal daran, daß ich mich zu blöd anstelle.

 

[Micha_Btz]

Morgen,

habe mich mit dem Thema lange nicht mehr beschäftigt, daher die Frage, kann ich mittlerweile eine freetz FW 6.50 über die Orginale FW 6.50
flashen oder muss ich immer noch den Umweg über den Downgrade auf Orginal FW 6.3x machen?

Und gibt es eine Möglichkeit das Recovery so anzupassen, dass gleich eine eigene Firmware geflasht werden kann?

danke Micha

 

[PeterPawn]

Die Antwort wäre "ja" und "nein" ... häufig mit dem Kofferwort "Jein" beschrieben.

Es gibt eine Möglichkeit, das System direkt über den Bootloader zu aktualisieren, wenn das zu schreibende Image denselben Aufbau verwendet wie ein AVM-Image (bezogen auf das hier diskutierte Modell). Der Pferdefuß an dieser Art des Updates ist es aber, daß die dort hinterlegte Skript-Datei /sbin/flash_update das aktuell ausgewählte System überschreibt. Das hat den Nachteil (wenn man es nicht absichtlich so handhaben will, es gäbe unter Umständen auch gute Gründe dafür), daß das bisher definitiv lauffähige System überschrieben wird ... im schlechtesten Falle mit einem nicht funktionierenden.

Vielleicht könnte man ja mal darüber nachdenken, beim Packen der Firmware eine weitere Option einzuführen, bei der sowohl die /sbin/flash_update im Wrapper-FS so angepaßt wird, daß das inaktive System beschrieben und nach dem erfolgreichen Update dann auf diese Version umgeschaltet wird (ich schätze mal, das sind so ca. 5-6 Änderungen in Shell-Statements) und die als zweites gleich eine Datei erzeugt, die aus dem Kernel und dem Dateisystem besteht und direkt in den Speicher der Box geladen und gestartet werden kann.

Ich weiß nicht, ob es irgendwo bereits andere Skript-Dateien für den Start so eines Images gibt, ich hätte das im YourFritz-Repo sowohl für "ash" oder "bash" (i.V.m. "nc") als auch für PowerShell vorrätig - notfalls müßte man an Parametern etwas feilen.

Diese Option könnte dann natürlich auch gleich das Problem des "initialen Flashens" einer eigenen Firmware quasi "abschließend" klären ... solange AVM am Bootloader nichts ändert, ist auf diesem Weg immer (bei NAND-Modellen zumindest, theoretisch auch bei NOR, aber da muß man das selbst "entwickeln") das Schreiben eines eigenen Systems möglich.

- - - Aktualisiert - - -

Ich habe mal auf die Schnelle (ungetestet!) einen Vorschlag zusammengebaut, wie man das "flash_update" von AVM so ändern könnte, daß man es für ein Freetz-Update verwenden kann.

--- flash_update.org	2016-07-05 14:43:35.000000000 +0200
+++ flash_update	2016-07-14 11:47:21.076391531 +0200
@@ -93,13 +93,20 @@
 mkdir -p ${tmp_dir_mntfs}
 cd ${tmp_dir}
 
+reserved="reserved-"
+if ! [ -e /wrapper/.inactive ]; then
+    reserved=""
+fi
+kernelname="${reserved}kernel"
+filesystemname="${reserved}filesystem"
+
 kernel_ram_mtdnr=`echo $kernel_ram | sed 's/:.*//' | sed 's/^mtd//'` 
 rootfs_ram_mtdnr=`echo $rootfs_ram | sed 's/:.*//' | sed 's/^mtd//'` 
-kernel_nand_mtdnr=`cat /proc/mtd  | grep '^mtd.*\"kernel\"' | sed 's/:.*//' | sed 's/^mtd//'` 
-rootfs_nand_mtdnr=`cat /proc/mtd  | grep '^mtd.*\"filesystem\"' | sed 's/:.*//' | sed 's/^mtd//'` 
+kernel_nand_mtdnr=`cat /proc/mtd  | grep "^mtd.*\"$kernelname\"" | sed 's/:.*//' | sed 's/^mtd//'` 
+rootfs_nand_mtdnr=`cat /proc/mtd  | grep "^mtd.*\"$filesystemname\"" | sed 's/:.*//' | sed 's/^mtd//'` 
 
-kernel_nand_mtd=`cat /proc/mtd  | grep '^mtd.*\"kernel\"'` 
-rootfs_nand_mtd=`cat /proc/mtd  | grep '^mtd.*\"filesystem\"'` 
+kernel_nand_mtd=`cat /proc/mtd  | grep "^mtd.*\"$kernelname\""` 
+rootfs_nand_mtd=`cat /proc/mtd  | grep "^mtd.*\"$filesystemname\""` 
 
 cat /dev/mtd${kernel_ram_mtdnr} > kernel.image
 
@@ -143,6 +150,7 @@
             print_error_logfile
             exit 3
         fi
+		[ -e ${tmp_dir_mntfs}/.inactive ] && rm ${tmp_dir_mntfs}/.inactive 2>/dev/null
     else
         print_message "[Fehler] Konnte Filesystem-Partition ${rootfs_nand_mtdnr} nicht mounten."
         print_error_logfile
@@ -203,6 +211,15 @@
     echo "firmware_info ${fw_info_new}" >$CONFIG_ENVIRONMENT_PATH/environment
 fi
 
+if [ -e /wrapper/.inactive ]; then
+    sysindex=`grep linux_fs_start $CONFIG_ENVIRONMENT_PATH/environment`
+    [ -z $sysindex ] && sysindex="0"
+	if [ "$sysindex" -eq "0" -o "$sysindex" -eq "1" ]; then
+		newindex=$(( (sysindex + 1) % 2 ))
+		echo "linux_fs_start $newindex" >$CONFIG_ENVIRONMENT_PATH/environment
+	fi
+fi
+
 sync
 print_message "FINISHED -> Reboot now.."
 print_message "============================================================================"

Die Idee ist es, in das Wrapper-FS eine Datei ".inactive" zusätzlich einzubauen (reine Existenz reicht) und dann wird nicht das aktive System überschrieben, sondern eben das inaktive. Im Anschluß wird dann diese Datei aus dem neuen Wrapper-FS gelöscht - vorher löschen ist schlecht, weil das FS auch r/o sein könnte und sie beim Kopieren auszuschließen, ist wesentlich mehr Aufwand, als sie im Anschluß wieder zu löschen.

Ansonsten wird die Datei (im RAM-FS steht sie ja weiterhin) noch als Flag verwendet, daß die Index-Variable "linux_fs_start" umgeschaltet werden soll - ich habe mich bei allen Änderungen mehr an die AVM-"Syntax" angelehnt (geht beim "grep" los, wo eben nicht auf den Zeilenbeginn getestet wird und eine Zeile mit "ptest" im Wert der Variablen alles durcheinander bringen kann) als der eigenen Kreativität freien Lauf zu lassen und ich wollte gleichzeitig mit so wenigen Änderungen wie nötig eine Version schaffen, die beiden Zwecken dienen kann.

Das Schöne an der AVM-Version ist es, daß der LED-Treiber benutzt wird ... das geht nur, wenn man AVM-Komponenten im Dateisystem hat und deshalb verzichte ich selbst normalerweise auf diesen ganzen Zusatz und auch das Schreiben von "firmware_info" braucht es nicht wirklich in diesem Kontext. Dafür ist die Änderung (wenn alles stimmt, wie gesagt: es ist ungetestet) dann so weit neutral beim Fehlen der ".inactive"-Datei, daß man sie theoretisch auch ständig ausführen könnte in Freetz beim Zusammenstellen des Wrapper-FS.

Dann braucht es wirklich nur noch eine Datei, in welcher der Kernel und das ext2-Dateisystem mit dem SquashFS-Dummy-Header direkt hintereinander stehen (an einer 256-Byte-Boundary für das FS) und diese kann man dann über den Bootloader direkt in den Speicher laden und starten lassen.

- - - Aktualisiert - - -

Da stimmt wieder was mit Tabulatoren und Leerzeichen nicht ... es geht um die Skizze des Prinzips, nicht um Schönheit bei den Einrückungen.

 

[Micha_Btz]

danke für die ausführliche Antwort. ich habe gestern auf https://github.com/Freetz/freetz umgestellt (hatte noch den alten von oli direkt benutzt)
und das bauen gelingt erstmal fehlerfrei. Nur ein Upload ist so noch nicht möglich, werde den patch mal testen die nächsten tage.

Micha

 

[Micha_Btz]

sorry, hat ne ganze weile gedauert, bis ich mal dazu kam.

ich habe den patch auf ./build/modified/filesystem_core/sbin/flash_update
angewendet und danach das Image neu gebaut, in der Hoffnung das es so mit eingebaut und verwendet wird.
leider klappt es so nicht, die Signaturprüfung schlägt fehl. ich muss mal versuchen mir auf der box anzusachen was während des laufes passiert.

 

[PeterPawn]

Irgendwie hast Du ja dann in #66 auch mittendrin mit dem Lesen aufgehört?

Ich habe ja deutlich geschrieben, daß dieser Patch nur dann Sinn macht, wenn man sich anstelle der "image"-Datei ein eigenes System (aus dem Kernel und dem Dateisystem hintereinander) baut und dieses über den Bootloader startet (steht dort unter dem Stichwort "als zweites"). Das ist nun mal etwas vollkommen anderes als das Update über die Box ... da findet dann auch keine Signaturprüfung statt, ergo kann da auch keine Signaturprüfung fehlschlagen.

Ich bin mir wegen dieser Aktion nicht einmal mehr so ganz sicher, ob Du die Notwendigkeit einer Datei ".inactive" im äußeren Dateisystem dann tatsächlich zur Kenntnis genommen hast und ob diese in Deinem "Image" existiert.

Die zweite Stelle, wo ich etwas skeptisch wäre, ist die einmalige Änderung der Datei "/sbin/flash_update" in "filesystem_core" unterhalb von "modified" ... das würde ich entweder am Original machen oder zumindest bei jedem Zusammenpacken eines Images und mich nicht darauf verlassen, daß dieses äußere Dateisystem in "modified" schon nicht überschrieben wird.