Keine Ahnung, wie und wohin das gewesen sein soll ... selbst unter meinen (hier bekannten) E-Mail-Adressen habe ich nichts empfangen.
Aber das wäre ohnehin der falsche Weg - wie weiter oben schon geschrieben, will ich mit meinen Hinweisen keine "Verpflichtung" eingehen und das wäre ein Protokoll, was mir irgendwie anders zugeht (und damit auch nur mir), als über das IPPF und diesen Thread hier, offensichtlich durchaus ... und zwar eben eine "ungewollte".
Was man für den ersten Schritt bräuchte (das ist ja "ein Prozess"), hatte ich in #13 ja noch einmal "aufgezählt".
EDIT:
Es ist vollkommen Wumpe, mit welcher FRITZ!OS-Version die "panic
.log" (so hieß die halt früher, als sie noch nicht über das "procfs" ausgelesen wurde, sondern über einen TFFS-Node - was vermutlich auch heute noch gehen würde und dann sogar mehrfaches Lesen erlauben sollte) erstellt wurde ... entscheidend ist, daß sie das Protokoll vom Absturz unter 07.2x enthält und das tut sie, solange es danach keinen weiteren Absturz (bzw. keine weitere "kernel panic") gab.
EDIT2:
Zwischendrin wurde der Inhalt der "panic" auch mal als
/proc/avm_panic_sd bereitgestellt ... daher auch der Hinweis weiter vorne in diesem Thread (in irgendeinem Beitrag weiter oben), daß man da in der
/bin/supportdata nachsehen muß/sollte, wie das in einer bestimmten Version auszulesen ist, wenn man es von Hand machen wollte.
EDIT3:
Auch wenn da offenbar nichts mehr kommt (ist ja auch schon spät), habe ich mir das noch einmal angesehen, wie
@cuma das mit dem Start über den "supervisor" umgesetzt hat.
Ich würde hier - in einem ersten Versuch - den Start der "rc.mod" erst einmal vom Start des Services entkoppeln. Im Moment ist es ja so, daß da ein zusätzlicher Service
rcmod.service eingerichtet wird (
https://github.com/Freetz-NG/freetz-ng/blob/master/patches/scripts/115-systemd-services.sh) und dem "supervisor" vermittelt wird (über den "[Install]"-Abschnitt), daß für das Erreichen des (angestrebten) Zustands "multi-user.target" auch dieser Service zu starten wäre. Das würde ich als Erstes aufweichen ... einfach durch Entfernen dieses Zusammenhangs.
Danach wird aber vermutlich dieser Service nicht mehr automatisch gestartet ... und man muß sich einen Weg suchen, das dann eben an einer anderen Stelle nachholen zu lassen, denn meine Annahme, daß mittlerweile der "supervisor" auch entscheidet, wann der Systemstart "durch" ist und der Watchdog deaktiviert werden kann, dürfte zutreffen - wie ich mittlerweile anhand der vom "supervisor" importierten Funktionen aus der "libwdt.so" geprüft habe.
Entscheidend dürfte auch hier sein, daß man sich an einen existierenden Service hängt und auch wenn inzwischen "debug.service" schon früher abgearbeitet wird (der startet dann die
/etc/boot.d/core/tail), so wäre eben diese Datei immer noch ein passabler Ort für den Start des "Freetz-Mod" - nur eben asynchron zum Rest des Systemstarts und das sollte eigentlich möglich sein, wenn man - aus der erwähnten
/etc/boot.d/core/tail heraus - das einfach über ein
svctl start rcmod in der letzten Zeile veranlaßt.
Vielleicht muß man dann noch andere Dinge in der "rc.mod" ändern, wenn es weitere Abhängigkeiten von AVM-Services geben sollte, die bei der ehemaligen, sequentiellen Start-Methode bereits aktiv waren und nunmehr - der "supervisor" startet die Dienste ja parallel, wie es aussieht, oder zumindest unabhängig innerhalb des jeweiligen Targets - erst später verfügbar werden. Welche Abhängigkeiten zwischen den definierten Services bestehen, kann man sich übrigens über ein
supervisor -p /lib/systemd/system anzeigen lassen. Wird das mit dem Warten zu kompliziert (den Status der Services kann man sich wieder mit
svctl status ausgeben lassen), muß man sich eben ein späteres Skript suchen, aus dem heraus man den eigenen Service starten kann - aber in jedem Falle sollte dieser Start asynchron zum "supervisor" arbeiten und das macht er derzeit nicht, wenn da aus dem Service-File heraus die "99-zzz-rcmod" aufgerufen wird, die dann ihrerseits die "rc.mod" über das "dot command" (in "bash" gibt's das auch noch als "source", aber der Punkt ist POSIX-kompatibel) einschließt.
Ich habe jedenfalls in "modfs" den Start der "rc.user" (das ist ja ein ähnliches Problem) über ein "nohup" vom "supervisor" entkoppelt (
https://github.com/PeterPawn/modfs/blob/master/modscripts/mod_rc_tail_sh#L50), so daß der recht schnell die Info erhält: "Der Service wurde gestartet." (aka "ExecStart" wurde beendet).
Schaut man sich die AVM-Services an, gibt es dort eben keinen Dienst, der mit einer Shell-Datei als Basis "durchläuft" ... alles das, was dort als "Dauerläufer" registriert ist, ist auch ein "echter Daemon", der seinerseits selbst dafür sorgt, daß er sich vom "controlling terminal" abkoppelt (detached), indem er einen zweiten Thread im Hintergrund startet, der nicht an diesem Terminal hängt. Genau das macht aber ein Shell-Skript üblicherweise nicht ... und auch das "nohup"-Applet der BusyBox bewirkt ja nur das Abkoppeln des darüber gestarteten Programms vom Eltern-Prozess - die Shell-Instanz, die das "nohup" aufgerufen hat, hängt weiter in der Prozesskette und sollte/muß sich alsbald sauber beenden/zurückmelden beim "supervisor".
Daher müßte das auch mit einem "svctl" funktionieren ... das sollte auch nur den "supervisor" zum Start des Dienstes veranlassen und danach (wenn die Parameter nicht kompletter Quatsch waren, auch mit einem Exit-Code von 0) geht es dann weiter in dem Shell-Skript, wo das "svctl" aufgerufen wurde.
Das ist - mit Blick auf Freetz(-NG) - jetzt erst mal ins Unreine gedacht ... ggf. müßte man da noch etwas drauf herumdenken - aber einen Versuch kann man ja trotzdem starten, denn wenn da tatsächlich (ohne den Patch für den Watchdog) kein "Initialisierung beendet" gemeldet wird vom "supervisor", muß das ja seinen Grund haben und da ich das in "modfs" ja genauso gelöst habe (mit der Definition und dem Start des Services "rcuser.service") und damit der "supervisor" das offenbar trotzdem richtig umsetzt, kann es eigentlich nur irgendwo in der Start-Methode für die "rc.mod" seine Ursache haben.
Denn nach dem, was man in dem Gist sieht, ist die Initialisierung der AVM-Komponenten eigentlich schon lange durch - der Start der WLAN-Komponenten erfolgt asynchron und in den letzten 50 Sekunden vor dem Watchdog, die von dem Protokoll nur abgedeckt werden, ist von anderen Komponenten gar nichts mehr zu sehen - üblicherweise ein sicheres Zeichen, daß das bis Sekunde 85 (ab Kernel-Boot, der Watchdog startet später erst, wenn das Root-FS gemountet ist und "sysinit" loslegt) alles schon erledigt wurde.
Und noch mal zu dem Protokoll - das muß man auch erst mal finden ... dieses nachträgliche Editieren ist zwar "gefordert" von den Forenregeln, aber auch eine Unsitte in so einem Dialog mit eher kurzen "Antwortzeiten", weil kein Mensch nach einer weiteren Antwort erst noch einmal die Beiträge davor durchsucht, ob sich da - obendrein während er selbst schon beim Schreiben war - noch irgendetwas geändert hat. Wenn man so etwas macht, sollte man es im weiteren Verlauf wenigstens noch einmal erwähnen ... ich habe das in #8 eher durch Zufall gefunden bzw. weil ich überlegt habe, was Du mit "Dir geschickt" meinen könntest. Auf die Idee, daß damit ein Gist gemeint sein könnte, wäre ich aber auch im Traum nicht gekommen.
EDIT4:
Witzig ... der JS-Code hat mir jetzt erst "mitgeteilt", daß da vor 46 Minuten ein weiterer Beitrag verfaßt wurde - damit kann ich aber jetzt "meine Methode" (das alles in einem neuen Beitrag noch einmal zu schreiben und dafür den vorhergehenden löschen) auch vergessen, weil das die Abfolge der Beiträge durcheinander bringt.
Aber was soll's ... ich schmeiße den ersten Beitrag dann jetzt doch weg - mit etwas Pech faßt ein Moderator dann Deine beiden zusammen, weil sie hintereinander stehen.
github.com
Der bisherige Workaround scheint ja zu sein den AVM-Watchdog zu deaktivieren.
