Fritz 7170 - bringe freetzng nicht mehr drauf?

[BeJoNe]

Hatte vorher freetz (classic) drauf und wollte auf freetzng wechseln.
1.Probiert über freetz-webupdate -> bleibt beim booten hängen(netzwerk down)
2.Recover eingespielt und über die originale firmware das freetzng update eingespielt -> gleicher effekt
3a.mit EVA:

[FirmwareImage]::new("C:\Temp\fritz\7170_04.88.ger_freetz-ng-18790-cdac2ce34_20211229-190033.image").extractMemberAndRemoveChecksum("./var/tmp/kernel.image", "c:\Temp\fritz\7170")

3b.mit EVA:

EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { UploadFlashFile c:\Temp\fritz\7170 mtd1 }

-> wieder hängen geblieben

Was mache ich falsch?

[fda77]

Ich hab keine Ahnung ob EVA-FTP-Client überhaupt mit der 7170 umgehen kann. Bist du sicher?
Falls die Firmware nicht bootet würde ein Log der seriellen Konsole helfen. Es kann schon sein dass diese ganz alte Box wegen irgend einer Änderung nicht mehr funktioniert

[BeJoNe]

ok, habe mit freetz classic nochmals ein image gebaut, das bootet jetzt ohne probleme ?!

[fda77]

Dann muss irgend jemadn herausfinden weshalb. Am besten jemand der so eine Box noch hat.
Das letzte freetz/ war svn revision 15014 . Heute ist svn 18790 aktuell
Du baust dann die Mitte 17000. Jenachdem obs läuft oder nicht 16000 oder 18000 usw

[BeJoNe]

das Image heisst: 7170_04.88-freetz-master-20210526-75984884e.de_*
bei make menuconfig steht oben: master-20210526-75984884e

[fda77]

Das ist die letzte freetz/ git-version

[pfichtner]

Ich habe ebenfalls Probleme mit freetzng auf älterer Hardware, deshal hänge ich mich hier mal dran.

Hier die logs der seriellen Konsole während des Bootens
W920V_7570_04.92-freetz-HEAD-20210526-75984884e.en_20210602-012900.log
W920V-Alien7570_04.92.int_freetz-ng-18799-0128f5482-ng21090_20220102-103909.log

Hier das diff aus den zwei Dateien W920V-diff.txt

Der erste Eintrag der mir auffällig erscheint ist, dass im freetz log BusyBox von init gestartet wird, was bei freet-ng nicht ausgegeben wird. Gibt es etwas was ich weiter untersuchen kann?

[fda77]

Ich glaube dass Freetz nicht gestartet wird ist nur ein Auswirkung von anderen Problemen. Da du replace Kernel verwendest würde ich das zunächst deaktivieren.
Der Freetz-start besteht aus 2 Teilen, dem Laden von Benutzern usw und am Ende dem Starten der Initscripte
https://github.com/Freetz-NG/freetz-ng/blob/master/patches/scripts/115-S20-modload.sh
https://github.com/Freetz-NG/freetz-ng/blob/master/patches/scripts/115-patch-ds_off.sh
Wobei das 1. bei der alten Box gar nicht greift sondern so gemacht wird: https://github.com/Freetz-NG/freetz-ng/blob/master/patches/devices/04_XX/7170/110-rc.S-mknod.patch
Es fehlen viele Dinge die Treiber für AVM Dinge laden. Hast du viel Entfernt?
Dass ganz am Anfang aber schon device-table tty-console und passwd anders sind finde ich komisch. Schade dass ich meine 7170 beim vorletzten Umzuh weggeworfen hab

[fda77]

Vielleicht funktioniert dies auch nicht so gut wie gedacht, ich hab da noch Probleme mit der 7390: 6e60f12
Mach das am besten rückgängig und dann ein "make distclean"

[pfichtner]

Werde es mal ohne REPLACE_KERNEL bauen.

Hast du viel Entfernt?

> grep REMOVE .config | grep -v '^#'
FREETZ_REMOVE_LEFTOVER=y
FREETZ_REMOVE_MODULE_BINS=y
FREETZ_REMOVE_AURA_USB=y
FREETZ_REMOVE_WEBDAV=y
FREETZ_REMOVE_MEDIASRV=y
FREETZ_REMOVE_AVM_VPN=y
FREETZ_REMOVE_TELNETD=y
FREETZ_REMOVE_DTRACE=y
FREETZ_REMOVE_FTPD=y
FREETZ_REMOVE_HELP=y
FREETZ_REMOVE_LIBFUSE=y
FREETZ_REMOVE_NTFS=y
FREETZ_REMOVE_SAMBA=y
FREETZ_REMOVE_SUPPORT=y
FREETZ_REMOVE_SUPPORT_EVENTSDUMP=y
FREETZ_BUSYBOX_FEATURE_KILL_REMOVED=y
FREETZ_BUSYBOX___V127_FEATURE_KILL_REMOVED=y

Dass ganz am Anfang aber schon device-table tty-console und passwd anders sind finde ich komisch.

Ja, das hat mich auch stutzig gemacht

[fda77]

https://github.com/Freetz-NG/freetz-ng/blob/master/patches/devices/04_XX/7170/120-rc.S-dev.patch
nutzt die Datei "device.table" die es nur mit freetz und nicht mit original-avm gibt. "makedevs" sollte sie benutzen.
Stattdessen kommt "Warning: unable to open an initial console." in deinem diff
Vielleicht hat es was mit der BusyBox zu tun

[pfichtner]

Nur zur Sicherheit um Mussverständnisse zu vermeiden: Das Freetz-NG Image (nicht funktionierend) wurde mit der gleichen .config erzeugt wie das Freetz-Image (funktionierend)

[fda77]

Danach hat du aber kurz menuconfig aufgerufen und gespeichert?
Im Bereich Busybox gibt es einiges in ng mehr. Bei freetz/ war glaub ich für alle Geräte nur 1 Version. In ng für neure eine neuere Busybox
Aber auch beim Laden von freetz beim Start wurde was verändert, da neuere Fritzos so einen systemd-Verschnitt haben der in freetz/ noch gar nicht unterstützt wurde.
Es wurde zwar so angepasste dass die neueren Dinge nur für neueres FOS greifen und altes so bleibt, aber dabei können schon Fehler unterlaufen
Deshlab auch zum testen replace kernel ausmachen, um das auszuschliessen

[pfichtner]

Ich baue Images für diverse Fritzboxen auf einem Jenkins-Server. Jeder Build jedes Images wird in einem frisch gestarteten Docker-Container gebaut. Die Konfigurationen für die Boxen liegen bei mir im git und werden in den Build-Docker-Container geschoben und dort ein als erstes ein make oldconfig aufgerufen.
Die zwei Builds (Freetz und Freetz-NG) sind zu total unterschiedlichen Zeiten gebaut worden (Freetz: W920V_7570_04.92-freetz-HEAD-20210526-75984884e.en_20210602-012900,
Freetz-NG: W920V-Alien7570_04.92.int_freetz-ng-18799-0128f5482-ng21090_20220102-103909).

[fda77]

Ich hab ganz überlesen dass es bei der um eine 7570, also 2er Serie geht. Eine 7390 6.8x (3er) läuft bei mir problemlos

[pfichtner]

Deshlab auch zum testen replace kernel ausmachen, um das auszuschliessen

Hier das Log ohne FREETZ_REPLACE_KERNEL, auch damit scheint die Box nicht in einen betriebsfähigen Zustand zu kommen
W920V-Alien7570_04.92.int_freetz-ng-18812-9d0bcb1eb-ng21090_20220107-203924-patch-no-replace-kernel.log

[fda77]

NG und Freetz/ haben die svn revision 15014 als letztes gemeinsam, danach wurde freetz.org zu github geschoben und ng geforkt. In Freetz kamen danach nur kleiner Dinge die alle in ng sein sollten. NG ist aktuell bei revision 18810.
Man könnte jetzt durch ausprobieren versuchen zu finden wann das Problem auftrat...
Das geht natürlich auch mit git, nur muss man dann die hashes heraussuchen, was bei revisionen wesentlich einfacher ist

Man könnte sich auch hieran orientieren: https://github.com/Freetz-NG/freetz-ng/commits/master/make/busybox
(Es muss aber gar nichts mit der Busybox zu tun haben)

[pfichtner]

Ich habe aus dem Freetz-NG repo r15014 frisch gebaut, das funktioniert. Habe dann mal eine Version zwischendrin gebaut, r16775 (21.05.2020), das funktioniert schon nicht mehr.
Statt hashes raussuchen kann man ja "einfach" git bisect nutzen. Habe eine laborähnliche Umgebung, die Fritzbox hängt an einem separaten Ethernetadapter, ihre serielle Konsole an einem FTDI und ihre Stromzufuhr ist vom Rechner an-/ausschaltbar, sprich: Ich könnte den Rechner via bisect suchen lassen welche Revision die letzte ist die noch funktioniert.

[fda77]

Von 15014 bis 18812 ist 16775 grob die Hälfte. Über git als auch svn sollte die gleiche Code heruskommen, nur die Revisionen sind einfacher zu zählen. "tools/freetz_revision" sollte (mittlerweile) fast immer das gleiche ausgeben.

[pfichtner]

bisect hat für die knapp 600 revisionen 11 Anläufe gebraucht, das ist das Ergebnis:

f6a5c84b6a549dc155fe86ff44224e3c846f253d is the first bad commit
commit f6a5c84b6a549dc155fe86ff44224e3c846f253d
Author: fda77 <[email protected]>
Date:   Mon May 4 22:19:41 2020 +0200

    docs: move device_table

 docs/wiki/60_Development/device_table.md | 153 +++++++++++++++++++++++++++++++
 tools/device_table.txt                   | 153 -------------------------------
 2 files changed, 153 insertions(+), 153 deletions(-)
 create mode 100644 docs/wiki/60_Development/device_table.md
 delete mode 100644 tools/device_table.txt
bisect run success

[pfichtner]

Habe auf meinem master/main den betreffenden commit #f6a5c84b6a549dc155fe86ff44224e3c846f253d reverted und damit für die 7570 (W920V) gebaut, jetzt startet das Image dort auch laut seriellem Konsolen Log wieder (sowohl die AVM Sachen als auch Freetz).

[pfichtner]

Siehe PR #440

[fda77]

Wow, prima! Es wahr wohl keine gute Idee die .txt Datei weg zu schieben. Sie sag für mich aus wie irgend eine doku, von denen lagen einige verstreut in allen möglichen Verzeichnissen.
Scheinbar sind die uralten Fritzbox seit 1,5 Jahren nicht mehr relevant
Wenn man https://github.com/Freetz-NG/freetz-ng/commits/master/docs/wiki/60_Development/device_table.md anschaut sollte 760226a#diff-ca08545b5f23d8589abb3a8accc448a013eade18771af7007fb6ae6e52fec32f wohl rückgängig gemacht werden. Die Konvertierung ins markdown Format war für https://freetz-ng.github.io/freetz-ng/wiki/60_Development/device_table.html
Wie wäre dann gleich auch mit "device.table" statt "device_table.txt"? Sonst benenn ich die irgend wann wieder um...
Dann vielleicht noch ein Link zur github.io-Seite mit rein

[fda77]

Läuft makedevs eigentlich auch mit der Datei im makedown-Format durch? Dann wäre es vielleicht besser nur den Pfad zu ändern.
"make help" zeigt zb den Inhalt von https://freetz-ng.github.io/freetz-ng/wiki/20_Advanced/make_targets.en.html an: https://github.com/pfichtner/freetz-ng/blob/master/Makefile#L555

[pfichtner]

makedevs läuft auch mit der markdown aus docs durch

[fda77]

Nach build/modified/filesystem.log wird die Ausgabe umgeleitet:

rootdir=build/modified/filesystem
table='docs/wiki/60_Development/device_table.md'
makedevs: line 4: unsupported file type r
makedevs: line 5: unsupported file type y
makedevs: invalid line 6: '<br>'
makedevs: line 7: unsupported file type i
makedevs: line 8: unsupported file type a
makedevs: line 9: unsupported file type i
makedevs: invalid line 11: '```'
makedevs: invalid line 13: '```'
makedevs: invalid line 14: '```'
makedevs: line 15: regular file 'sbin/foobar' does not exist: No such file or directory
makedevs: invalid line 16: '```'
makedevs: line 17: unsupported file type (
makedevs: line 18: unsupported file type (
makedevs: line 19: unsupported file type y
makedevs: line 20: unsupported file type F
makedevs: invalid line 22: '```'
makedevs: invalid line 24: '```'
makedevs: invalid line 25: '```'
makedevs: line 26: can't create node dev/hda: No such file or directory
makedevs: line 27: can't create node dev/hda1: No such file or directory
makedevs: line 27: can't create node dev/hda2: No such file or directory
makedevs: line 27: can't create node dev/hda3: No such file or directory
makedevs: line 27: can't create node dev/hda4: No such file or directory
makedevs: line 27: can't create node dev/hda5: No such file or directory
makedevs: line 27: can't create node dev/hda6: No such file or directory
makedevs: line 27: can't create node dev/hda7: No such file or directory
makedevs: line 27: can't create node dev/hda8: No such file or directory
makedevs: line 27: can't create node dev/hda9: No such file or directory
makedevs: line 27: can't create node dev/hda10: No such file or directory
makedevs: line 27: can't create node dev/hda11: No such file or directory
makedevs: line 27: can't create node dev/hda12: No such file or directory
makedevs: line 27: can't create node dev/hda13: No such file or directory
makedevs: line 27: can't create node dev/hda14: No such file or directory
makedevs: line 27: can't create node dev/hda15: No such file or directory
makedevs: invalid line 28: '```'
makedevs: line 30: unsupported file type t
makedevs: invalid line 31: '```'
makedevs: invalid line 33: '```'
makedevs: line 34: unsupported file type n
makedevs: invalid line 35: '```'
makedevs: line 36: unsupported file type A
makedevs: line 37: unsupported file type D
makedevs: line 38: unsupported file type C
makedevs: line 39: unsupported file type B
makedevs: line 40: unsupported file type F
makedevs: invalid line 41: '```'
makedevs: line 42: unsupported file type i
makedevs: line 43: regular file 'target' does not exist: No such file or directory
makedevs: invalid line 45: '<br>'
makedevs: line 46: regular file 'Have' does not exist: No such file or directory
makedevs: line 47: unsupported file type A
makedevs: invalid line 48: '<br>'
makedevs: invalid line 51: '```'
makedevs: invalid line 53: '```'
makedevs: invalid line 54: '```'
makedevs: invalid line 63: '```'
makedevs: invalid line 66: '```'
makedevs: invalid line 68: '```'
makedevs: invalid line 69: '```'
makedevs: invalid line 73: '```'
makedevs: invalid line 76: '```'
makedevs: invalid line 78: '```'
makedevs: invalid line 79: '```'
makedevs: invalid line 105: '```'
makedevs: invalid line 108: '```'
makedevs: invalid line 110: '```'
makedevs: invalid line 111: '```'
makedevs: invalid line 114: '```'
makedevs: invalid line 117: '```'
makedevs: invalid line 119: '```'
makedevs: invalid line 120: '```'
makedevs: invalid line 123: '```'
makedevs: invalid line 126: '```'
makedevs: invalid line 128: '```'
makedevs: invalid line 129: '```'
makedevs: invalid line 131: '```'
makedevs: invalid line 134: '```'
makedevs: invalid line 136: '```'
makedevs: invalid line 137: '```'
makedevs: invalid line 140: '```'
makedevs: invalid line 143: '```'
makedevs: invalid line 145: '```'
makedevs: invalid line 146: '```'
makedevs: invalid line 148: '```'
makedevs: invalid line 151: '```'
makedevs: invalid line 153: '```'
makedevs: invalid line 154: '```'
makedevs: invalid line 167: '```'
makedevs: invalid line 170: '```'
makedevs: invalid line 172: '```'
makedevs: invalid line 173: '```'
makedevs: invalid line 214: '```'
makedevs: invalid line 217: '```'
makedevs: invalid line 219: '```'
makedevs: invalid line 220: '```'
makedevs: invalid line 224: '```'
x:1

In diesem Fall gibt es errorcode 1. Wenn es die Datei gar nicht gibt 0 (okay) was ein Bug von BusyBox ist - würde in Freetz aber eh nicht geprüft

[fda77]

Sollte so funktionieren: 08b8c04

[pfichtner]

Werde es heute noch testen

[pfichtner]

Funktioniert!

[fda77]

Wenn das behoben werden sollte kann die 1. Überprüfung wieder weg: https://bugs.busybox.net/show_bug.cgi?id=14506

[pfichtner]

Die zur Fehlersuche genutzten/benötigten Dinge habe ich hier dokumentiert bzw. zur Verfügung gestellt: https://github.com/pfichtner/freetz-bisect falls jemand Interesse hat oder Dinge davon (wieder-)verwenden will.

[pfichtner]

Und am Ende eigentlich auch logisch, dass man mit überschaubarem Aufwand den Fehler findet und ja, wäre auch manuell ohne Probleme möglich gewesen (und geht auch enebso gut mit git bisect)

[fda77]

Die Laufzeit sollte O(log n) sein und damit die Umkehr der Exponentialfunktion. Trotzdem (für mich) überraschend dass es nur 11 Schritte sind, ich hätte besser vorher nachgerechnet

[pfichtner]

Genau so ist es und genauso schwer wie man als Mensch die Exponentialfunktion fassen kann, geht es einem mit der Umkehr davon.

[pfichtner]

...und wenn ich vorher gerechnet hätte, hätte ich mir überlegt ob ich es vollautomatisiere oder nicht doch lieber manuell mache 😆

[fda77]

Ah, du hast dich auch verschätzt :)
Vor allem wenn man überlegt dass evtl die letzten 5 Schritte nicht nötig sind da man evtl einfach durch lesen der 32 eingegrenzen Commits schon erahnen kann woran es liegen könnte

[pfichtner]

Jetzt wäre noch interessant, ob das eigentlich von @BeJoNe gemeldete Problem behoben ist 😆

[BeJoNe]

Mooment, ich probiere :)

[BeJoNe]

Rückmeldung: saubere Arbeit, die 7170 startet wieder und läuft.
Danke

[fda77]

Du hast wohl das alte Image verwendet

[BeJoNe]

tatsache, irgend ein altes Foto erwischt..

[pfichtner]

Jetzt sieht's gut aus. Damit lag es wohl am gleichen Problem wie bei mir (auf älteren Boxen ohne udev wurden die device nodes nicht angelegt). Damit könntest Du die Frage jetzt noch auf "beantwortet" setzen