Fritz!OS 7.50 für FB7530 / Gefreeztes Image macht Probleme

[NanoBot]

Bei mir zeigt sich mit der Firmware 7.50 das gleiche Problemwie schon mit der letzten Labor:

Die 7.50 lässt sich zunächst problemlos freetzen ( make läuft ohne Fehlermeldung durch ) und über das AVM GUI flashen. Nach dem Restart kann ich mich zwar auf der Box einloggen und bekomme die üblichen "Neue Version" Meldungen. Aber noch bevor ein DSL-Sync zustande kommt, rebootet die Box nach 1-2 Minuten Uptime von alleine, so daß ich wieder auf die 7.29 zurück schalten mußte.

Hat jemand von euch schon probiert, die neue Version zu freetzen und wenn ja, mit welchen Ergebnis ?

 

[Insti]

rebootet die Box nach 1-2 Minuten

Lass mal den Bootmanager weg.

 

[PeterPawn]

Lass mal den Bootmanager weg.

Gibt es dafür auch IRGENDEINE plausible Begründung? Woher weißt Du, daß er den überhaupt hat einbauen lassen? Welche anderen Meldungen, daß der Boot-Manager zu einem Reboot mit FRITZ!OS 07.50 führt (denn für 07.39 habe ich den im Frühjahr 2022 praktisch auf JEDER Plattform, die er derzeit unterstützt, getestet), habe ich überlesen?

@NanoBot:
Ich würde ja - anstatt jetzt Komponente für Komponente ein- oder auszubauen - einfach mal im zweiten Slot eine Firmware installieren (hier empfiehlt sich eine "stock firmware") und nach/bei einem Reboot dann nicht erneut das Freetz-Image booten, sondern diese zweite Version und mit der dann versuchen, an die Support-Daten des letzten Absturzes zu gelangen, denn dort sollte drinstehen, WARUM die Box tatsächlich neu gestartet wurde und dann kann man sich wilde Spekulationen hinsichtlich möglicher Ursachen schenken.

 

[Insti]

Gibt es dafür auch IRGENDEINE plausible Begründung?

Hallo Peter,

konnte das Gestern an meinen 7520 mit 7.50 auch sehen. Das Image mit dem Bootmanager führt nach ca. 2 Minuten zum reboot. Habe dann das Image ohne Bootmanager gebaut und das läuft. Auch die Seite zum Neustart bleibt beim Image mit Bootmanager weiß und das Laderad dreht.

 

[PeterPawn]

Und das wolltest Du mir/uns vorenthalten oder wann/wo genau hast Du den Fehler "gemeldet"?

Dann bitte ich (auch Dich) erst recht darum, mal den Grund für den Neustart in der Support-Datei korrekt zu ermitteln und - wenn möglich - auch zu prüfen, ab wann das bei der 7520/7530 so war.

Ich könnte mir noch ein Problem vorstellen, daß der Boot-Manager in irgendeiner Schleife den Speicher "frißt", weil er kein Ende findet ... oder er zu lange braucht, um den ersten Aufruf (der beim Start intern erfolgt) abzuschließen.

Wenn jemand möchte, daß der Boot-Manager auch weiterhin bei der 7520/7530 funktioniert, dann müßte er sich halt daran machen, das mal GENAUER mit den entsprechenden Aufrufen zu untersuchen - der Startpunkt wäre aber immer noch die Feststellung, ob es tatsächlich der Boot-Manager ist, der am Ende den Absturz bewirkt. Ich habe ja deutlich mehr Aufwand betrieben (angefangen bei der Unterstützung von Modellen mit FIT-Image bis zur (sicheren) Feststellung, ob bei der vorliegenden Box eine Änderung des Brandings überhaupt möglich ist und welches verwendet wird) und da kann schon mal etwas daneben gegangen sein - obwohl ich beschwören kann, daß ich im Frühjahr eigentlich alle relevanten Modelle durchgetestet hatte und dazu gehörten auch diejenigen, die den IPQ4019-Chipsatz benutzen, was dann ja für 7520/7530 zutrifft.

Da ich aber bestimmte Modelle, auf die ich selbst keinen Zugriff habe, nur simulieren konnte im Skript, wäre es durchaus denkbar, daß eine DIESER Änderungen dann doch wieder die korrekte Behandlung von IPQ4019-Geräten verhindert - ich will also nicht AUSSCHLIESSEN, daß ich mir beim Test weiterer Modelle dann doch wieder Fehler für andere eingeschleppt habe, zumal eben "echte" Regression-Tests nicht möglich sind, wenn für jeweils eine Plattform erst einmal die "Voraussetzungen" geschaffen werden müssen, wie z.B. hier: https://github.com/PeterPawn/YourFr...4b41edd9727b7009/bootmanager/bootmanager#L970

Ich bin also bei der korrekten Implementierung und bei der Suche nach Fehlern auf die Hilfe von Leuten angewiesen, die diese Geräte in ihrem Besitz haben und die dann auch noch eine modifizierte Firmware einsetzen. Schon dabei gibt es dann ja - soweit ich weiß - erhebliche Unterschiede zwischen Dir (@Insti) und anderen (zu denen auch @NanoBot zählt), denn Du setzt ja gar kein Freetz(-NG) ein ... oder hat sich das mittlerweile geändert?

 

[Insti]

Und das wolltest Du mir/uns vorenthalten oder wann/wo genau hast Du den Fehler "gemeldet"?

Wollte auch nichts sagen, da anscheinend niemand das Problem hat und ich dich nicht unnötig damit belasten möchte, da ich denke das du genug an der Backe hast.
Erst jetzt als @NanoBot das erwähnt hat, hab ich darauf geantwortet.
Außerdem ist der Bootmanager ein nice to have aber nicht ein must have für mich, solange über Telnet auch auf die Partition gewechselt werden kann.

mal den Grund für den Neustart in der Support-Datei korrekt zu ermitteln und

Entschuldige bitte meine Anfängerfrage, aber wie kann ich Supportdateien erstellen wenn die Box in einer ~2 Minuten Bootschleife hängt?

denn Du setzt ja gar kein Freetz(-NG) ein ... oder hat sich das mittlerweile geändert?

Freetz(-NG) ??? Kenne das nicht.

 

[NDiIPP]

[…] aber wie kann ich Supportdateien erstellen wenn die Box in einer ~2 Minuten Bootschleife hängt?

Steht in Beitrag #3.

 

[Insti]

@NDiIPP
Toll das du dich auch meldest. Wie sieht es bei deiner 7520/7530 aus mit 7.50 und Bootmanager?

 

[NDiIPP]

Ich nutze noch keine FW >=7.39 auf meinen Geräten. Edit: Ich warte auf >=7.51 als Stable-Release.

 

[PeterPawn]

@Insti:
Danke für Deine Rücksichtnahme (das ist durchaus ernst gemeint) ... aber dann hättest Du das ja auch in #2 schon mal "erwähnen" können und nicht nur so lakonisch zum "Weglassen" auffordern, was dann (natürlich) Nachfragen meinerseits hervorruft.

Ich habe gerade in einem anderen Thread (https://www.ip-phone-forum.de/threa...und-fw-7-50-nicht-nutzbar.314478/post-2502258) feststellen müssen, daß sich bei der BusyBox von der Version 1.35.0 zur 1.36.0 etwas beim sed-Applet verändert hat und damit nun ebenfalls etwas (anderes) beim Boot-Manager nicht funktioniert. AVM setzt aber (bei der 7590 zumindest) noch immer die BusyBox 1.29.3 ein - so daß es daran schon mal nicht liegen sollte, solange man kein Freetz-NG verwendet und selbst dann, habe ich inzwischen Änderungen vorgenommen, die DIESES Problem entschärfen sollten.

Wenn sich jemand findet, der bereit ist, mit mir auf die Suche nach dem Problem bei IPQ4019-Geräten zu gehen, kann er/sie sich ja melden ... am einfachsten macht man sich die Suche, wenn man zwar den Boot-Manager einbauen läßt, aber das Service-File so ändert (vor dem Einpacken des finalen SquashFS-Images), daß der Service nicht automatisch gestartet wird. Dazu sollte es ausreichen, die WantedBy-Zeile auszukommentieren - gleichzeitig hat man dann umgehend die Möglichkeit, per Shell-Session weiterhin auf die Suche nach dem Problem zu gehen. Die Service-Datei ist auch 1:1 in den Dateien bei GitHub vorhanden und wird nicht erst irgendwie dynamisch erzeugt bei der Installation - man kann diese Änderung also auch schon vornehmen, BEVOR man am Ende add_to_system_reboot.sh ausführen läßt.

Wer zum Modifizieren mein "modfs" verwendet, findet die Datei unter <modfs_dir>/files/bootmanager/bootmanager.service: https://github.com/PeterPawn/modfs/blob/master/files/bootmanager/bootmanager.service

 

[Master SaMMy]

freetz nutzt bb 1.36 nur noch

bump busybox · Freetz-NG/freetz-ng@2e8e2e8

Freetz-NG firmware modification for AVM devices like FRITZ!Box - bump busybox · Freetz-NG/freetz-ng@2e8e2e8

github.com

 

[PeterPawn]

Nachdem ich auch in den Commits von der 1.35.0 zur 1.36.0 nichts finde, wo anhand des Titels schon eine (relevante) Änderung beim sed zu erkennen wäre (https://git.busybox.net/busybox/log/?h=1_36_stable), ist das wohl die Nebenwirkung irgendeines anderen - und damit nicht mal eine GEZIELTE Änderung ... hier: https://git.busybox.net/busybox/commit/?h=1_36_stable&id=9b2d766e0ecb222d25a43333287835452e43f8a9 sollte es jedenfalls auch nicht sein und das ist der einzige Commit, der sich explizit auf das sed-Applet bezieht.

Aber egal ... DAFÜR habe ich wirklich nicht die Zeit, um das im Detail zu finden und es bringt am Ende ja auch nichts - einfacher war/ist die Änderung, die ich schon eingecheckt habe.

EDIT:
Da gab es mehr als eine Seite (der Link zur nächsten ist in einem unscheinbaren Grau und sieht eher nach "disabled" aus) ... und die Commits waren am Ende auch schon ein Jahr alt:

busybox - BusyBox: The Swiss Army Knife of Embedded Linux

git.busybox.net

busybox - BusyBox: The Swiss Army Knife of Embedded Linux

git.busybox.net

Es SIND also absichtliche Änderungen und wenn ich mich beim Überfliegen nicht getäuscht habe, wurde weniger die POSIX-Spezifikation, als vielmehr die GNU-Version des sed als Referenz herangezogen.

 

[NanoBot]

... Das Image mit dem Bootmanager führt nach ca. 2 Minuten zum reboot. Habe dann das Image ohne Bootmanager gebaut und das läuft. Auch die Seite zum Neustart bleibt beim Image mit Bootmanager weiß und das Laderad dreht.

Wenn ich die Diskussion richtig verfolge, dann ist mit "Bootmanager" die Erweiterung des "Neustart" Tabulators von PeterPawn auf dem AVM Oberfläche gemeint ?

Wenn ich den Bootmanager jetzt testweise weg lasse, müßte ich aber trotzdem noch die Möglichkeit haben, die Bootpartition unter der URL http://fritz.box:81/cgi-bin/system.cgi umzuschalten ? Bei meinem Versuch mit der gefreezten Firmware funktionierte die Umschaltung nur dort, während der "Neustart" Tabulator leer blieb und kringelte.

Ansonsten kann ich bei der Fehlersuche leider nur sehr begrenzt helfen, da ich meine Box immer nur spät in der Nacht neu booten oder flashen kann. Sonst gibt es Ärger mit der anderen Internetnutzerin hier im Haushalt

 

[FischersFreetz]

Auf beide deiner Fragen ein "Ja".

 

[Insti]

an die Support-Daten des letzten Absturzes zu gelangen

Falls es weiterhilft anbei die unvollständigen Support Datei, bin bis 535kb gekommen bis zum Absturz deshalb unvollständig.

 

[NanoBot]

Ich habe eben ein Image mit abgeschalteten "yf-Bootmanager" erzeugt und geflasht und kann bestätigen, daß die gefreezte 7.50 jetzt funktioniert.

 

[PeterPawn]

Teilweise hilft es, aber die Daten zum Absturz fehlen am Ende. Dabei ist es doch eigentlich relativ simpel ... in einen Slot die Firmware MIT dem Boot-Manager und in den anderen eine OHNE. Danach die Partition MIT dem Boot-Manager einmal kurz laufen lassen und BEIM ABSTURZ (der sich ja durch die LEDs einigermaßen sicher erkennen lassen sollte) direkt per linux_fs_start auf den anderen Slot (wo das System dann nicht abstürzen wird) umschalten. Die Daten zum Absturz werden noch VOR dem Reboot ins TFFS gesichert (erst bei einigen ARM-Modellen werden die dann (iirc) erst beim nächsten Start "weggeschrieben") und sollten daher auch im System aus dem anderen Slot direkt verfügbar sein.

Wobei mir schon der Blick in die Prozessliste verrät, daß hier tatsächlich etwas nicht stimmt - 13 Instanzen von bootmanager get_values kann ich mir (unter schlechten Umständen) gerade noch so vorstellen, wenn ein FIT-Image zu zerlegen und dabei zu kopieren ist - dabei setze ich dann einige rekursive Aufrufe ein, wobei eine Schachtelungstiefe von 13 da auch schon deutlich mehr ist, als zu erwarten wäre (beim "fast copy" sollten max. 6 Aufrufe von dd erfolgen und auch die nicht alle rekursiv: https://github.com/PeterPawn/YourFr...339d8373f9688847/bootmanager/bootmanager#L504). Aber diese Boxen HABEN ja nicht mal ein FIT-Image ...

Unabhängig davon bleibt mein Vorschlag bestehen, den automatischen Start von bootmanager_server durch ein geändertes File bootmanager.service zu unterbinden und stattdessen erst einmal den "worker" (also das bootmanager-Skript) manuell aufzurufen und zwar zuerst mit dem Löschen event. vorhandener Cache-Files (die sollte es aber gar nicht geben, wenn WIRKLICH noch kein Aufruf erfolgte) durch bootmanager clear_cache with_eva_config und danach mit einem BM_DEBUG_EVA=1 bootmanager debug verbose das Zusammensuchen der Daten so anzuwerfen, daß deutlich mehr protokolliert wird und man (hoffentlich) auch sieht, wo das Problem liegt.

An nachträglichen Änderungen durch AVM kann es eigentlich kaum liegen (zumindest wäre das nicht mein ERSTER Verdacht), denn bei der 7590 funktioniert es (mit der AVM-BusyBox) DEFINITIV bei mir problemlos - sogar mit zusätzlichen Funktionen, die mir weitergehende Änderungen an den Einstellungen im Urlader-Environment gestatten (https://github.com/PeterPawn/YourFritz/blob/main/bootmanager/yf_custom_environment.sh). Daher wäre mein erster Gedanke, daß hier beim Zerlegen der EVA-Konfiguration etwas anders ist, als ich es (bisher) erwartet habe.

 

[Insti]

Die Daten zum Absturz werden noch VOR dem Reboot ins TFFS gesichert (erst bei einigen ARM-Modellen werden die dann (iirc) erst beim nächsten Start "weggeschrieben") und sollten daher auch im System aus dem anderen Slot direkt verfügbar sein.

Moin,
klasse Tip! Anbei die Supportdatei.

 

[genuede]

Angefangen hat das Problem mit dem Bootmanger ziemlich am Anfang von 7.39. Vielleicht finde ich das noch auf meinem PC. Hatte aber dann im Script von @Insti alles gelöscht, was ich nicht brauche. Ich nutze modfs nur, um die Firmware der 7530 auf der 7520 zu nutzen und um das Branding auf AVM zu setzen.
Wollte auch niemanden nerven. Und wie gesagt, ich brauche den Bootmanager nicht.
Nach den Scripten auf meinem PC sollte die 7.39-96397 noch mit Bootmanager funktioniert haben, für die 7.39-96552 habe ich auf jeden Fall zwei Scripte, das neuere nur noch mit "Branding AVM" ohne weitere Modifikationen. Also seit Mai 2022.
Gerhard

 

[PeterPawn]

Ich gebe mal kurz ein Zwischenfazit zum Besten ... das Problem liegt offenbar tatsächlich im Zerlegen des Konfigurationsbereichs im Boot-Loader (das ist ja ein neues Feature, was ich eingebaut habe). Da das nicht fertig wird, meldet sich (beim alten Stand, inzwischen habe ich diese "Rückmeldung" weiter nach vorne geschoben: https://github.com/PeterPawn/YourFritz/commit/d15ce1af1fb2de5d81e71f7e339d8373f9688847, aber noch nicht an anderen Stellen, also weder bei den Tags für Freetz-NG, noch im "modfs"-Repo) auch der Supervisor nicht beim Watchdog (dem für die Initialisierung des Systems) ab und irgendwann läuft der Timer dann ab (vermutlich wird er ohnehin nur auf 120 Sekunden gesetzt), was im Ergebnis zu einer "kernel panic" führt. Also nichts wirklich Weltbewegendes ... nur ein Service, der zu lange für die Rückmeldung braucht, worauf der Supervisor davon ausgeht, daß irgendetwas "hängt" (was ja auch nicht wirklich falsch ist) und dann lieber das System neu startet.

Was mich daran irritiert: Eigentlich sollte - auch dann, wenn der Konfigurationsbereich NICHT in der Urlader-Partition liegt, was ggf. bei den IPQ4019-Geräten der Fall ist - irgendwann beim Durchsuchen des Boot-Loaders nach dem Konfigurationsbereich mal ein Ende gefunden werden, wenn es nichts weiter "zu zerlegen" gibt. Danach sollte dann umgeschaltet und die Suche nach dem Konfigurationsbereich aufgegeben werden. Warum das hier nicht klappen will, muß ich erst einmal genauer untersuchen ... dazu werde ich (nicht sofort, aber noch am Wochenende) ein paar Kommandos aufschreiben, die dann jemand auf seiner 7520 oder 7530 ausführen müßte.

Bis dahin funktioniert das dann "offiziell" für IPQ4019-Boxen nicht - tut mir leid, aber ich repariere das zeitnah wieder. Aus dem Kopf fällt mir schon mal ein, daß ein cat /proc/mtd zeigen sollte, ob es eine dedizierte Partition für die EVA-Konfiguration gibt (wie bei anderen neueren Modellen) oder nicht. Auch der Name und die Größe der Urlader-Partition sollten darin zu sehen sein ... bei einer Größe, die nicht einer Zweierpotenz entspricht, könnte es noch Probleme mit der (binären) Suche nach dem Konfigurationsbereich geben und ggf. kommt das DESHALB nicht zum Ende.