AVM-Watchdog - kann man den guten gewissen deaktivieren?

Nein, auch das nicht (ich kann schlecht zitieren, ohne das als "full quote" zu machen).

Denn das Packen übernimmt ja bereits das "make" und wenn man sich den gesamten Satz ansieht (ich hatte wohl Dein Zitat nicht weit genug in beide Richtungen erweitert, weil ich davon ausging, daß Du das am originalen Ort (das war sogar verlinkt) noch einmal nachlesen könntest):
Eine Datei (nämlich die 115-systemd-services.sh) geändert, neues "make" und das resultierende Image (oder auch nur die "build/modified/firmware/var/tmp/filesystem.image", wenn man es von Hand machen will und verstanden hat, wie das geht) auf die Box gebracht - danach Neustart.
, dann steht da: "das resultierende Image" (was sich natürlich auf das "make" bezieht und die dabei entstehende Datei in "images") ODER auch nur die ".../filesystem.image" (das ist ja das SquashFS-Image, was am Ende auf der Box in der passenden Partition landen wird - bei GRX-Boxen sogar 1:1 dieses Image, weshalb man auch nur das mittels "update_kernel" in der Box installieren müßte). Das kann man eigentlich kaum mißverstehen.
 
Baue dabei mal irgendwo in der Initialisierung (am besten in der "rc.custom", die wird ziemlich spät in der "rc.mod" aufgerufen) das hier ein:
Code:
cat /dev/debug > /var/media/ftp/$(date +%s)_dev_debug.txt
Damit wird der bis dahin geschriebene Inhalt der Debug-Datei von AVM (das wird über "/dev/debug" gepuffert) in NAS-Speicher gesichert und kann auch vom anderen System aus gelesen werden. Auf demselben Weg kann man auch die Freetz-Protokolle sichern oder auch das Syslog - da ist auch dieses Mal noch genug Zeit am Ende, wo praktisch nichts passiert. In dieser Zeit (vor dem Neustart) kann man sich dann noch so einiges an Protokollen (die üblicherweise nur volatil gespeichert werden) so sichern, daß man von der anderen Partition darauf zugreifen kann.

Wobei hier irgendwie (auch im letzten Log schon) das WLAN fehlt (oder es ist nur nicht zu sehen) - was auch nicht unbedingt ein Problem sein muß (es hilft sogar ein wenig, wenn das deaktiviert wäre, weil dann die Protokolldaten deutlich weniger werden).

Blöd wäre nur, wenn jetzt der Neustart davon herrührt, daß eben das WLAN nicht vernünftig gestartet werden kann - was auch an einer (nicht erneut durchgeführten) Konvertierung der Einstellungen beim Update auf die 07.21 liegen könnte. Die wird ja nicht wirklich BEIM Update durchgeführt, sondern erst im Anschluß und wenn da irgendeine neue Versionsnummer behauptet, die Konvertierung wäre schon erfolgt, obwohl die 07.12 noch einmal Änderungen vorgenommen hat, als sie lief, kann das zu Problemen führen.

Das könnte man natürlich mit dem Start einer originalen 07.21 überprüfen ... kommt die mit den aktuellen WLAN-Einstellungen klar, sind die sicherlich auch für das Freetz-Image zu verkraften - dieser Teil wird ja gar nicht angefaßt in Freetz.

EDIT: Die "rc.custom" kannst Du natürlich von der 07.12 aus auch editieren - das "Einbauen" bezog sich auf den Ablauf, nicht unbedingt auf das Image.
 
Zuletzt bearbeitet:
Das ist eine Datei in den Freetz-Einstellungen ... dort kann man aktivieren, daß eigene Kommandos im Rahmen der Initialisierung von Freetz abgearbeitet werden. Du hast doch in der 07.12-Partition auch ein Freetz-Image, oder?
 
Das ist eine Datei in den Freetz-Einstellungen ... dort kann man aktivieren, daß eigene Kommandos im Rahmen der Initialisierung von Freetz abgearbeitet werden. Du hast doch in der 07.12-Partition auch ein Freetz-Image, oder?
Ah okay ja, wie war nochmal der Befehl in der Rudishell um die Bootpartition zu wechseln? habe das in der Freetz Version nicht drin...

ORIGINAL ist die *unveränderte* avm firmware. Die wird nur 1x entpackt und beim nächten make wieder benutzt. Man könnte also avm-Dateien in ORIGINAL ändern, und beim nächsten MAKE wären die dann im MODIFIED aus dem ein IMAGE gepackt wird.
Zurücksetzen: "rm -rf build/", das wird beim nächsten MAKE neu entpackt
In MODIFIED wird alles bei MAKE verworfen


watchdog auf 5min setzen
Code:
make für 7590 7.2 ausführen
sed -i 's/ 120/ 300/'  build/original/filesystem/etc/boot.d/core/watchdog
make

flashen

rm -rf build/

Also er ist damit schonmal weiter gekommen (z.B. sogar Internet Verbindung, glaube aber dass ihn dann etwas anderes abgeschossen hat.)
Hatte nicht den Eindruck, dass er 5 Minuten überlebt hat...
Ah ja, gibt ne crash.log statt panic

Habe derweil fleißig Syslogs manuell kopiert XD
Code:
freetz-ng-17399M-3562a7b26
Freetz @7590-Ort – Syslog

Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.520077][1]vrx518 0002:01:00.0: Section TXOUT_PDRING ie_len 1
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.520088][1]vrx518 0002:01:00.0: Sec TXOUT_PDRING desc base 0x00100b28, des_num: 32
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.520097][1]vrx518 0002:01:00.0: Section RXIN ie_len 1
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.520106][1]vrx518 0002:01:00.0: Sec RXIN desc base 0x00100c28, des_num: 32
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.520121][1]vrx518 0002:01:00.0: Section RXIN_PDRING ie_len 1
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.520145][1]vrx518 0002:01:00.0: Sec RXIN_PDRING desc base 0x00101028, des_num: 32
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.520167][1]vrx518 0002:01:00.0: Section RXOUT ie_len 1
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.520189][1]vrx518 0002:01:00.0: Sec RXOUT desc base 0x00101128, des_num: 32
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.520200][1]vrx518 0002:01:00.0: Section RXOUT_PDRING ie_len 1
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.520212][1]vrx518 0002:01:00.0: Sec RXOUT_PDRING desc base 0x00101528, des_num: 256
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.520223][1]vrx518 0002:01:00.0: Section DMA ie_len 10
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.520236][1]vrx518 0002:01:00.0: dma channel 0 desc base 0x00100000
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.520247][1]vrx518 0002:01:00.0: dma channel 1 desc base 0x00100008
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.520258][1]vrx518 0002:01:00.0: dma channel 2 desc base 0x00100010
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.520269][1]vrx518 0002:01:00.0: dma channel 3 desc base 0x00100018
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.520281][1]vrx518 0002:01:00.0: dma channel 4 desc base 0x00100030
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.520291][1]vrx518 0002:01:00.0: dma channel 5 desc base 0x00100038
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.520304][1]vrx518 0002:01:00.0: dma channel 6 desc base 0x00100020
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.520315][1]vrx518 0002:01:00.0: dma channel 7 desc base 0x00100028
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.520326][1]vrx518 0002:01:00.0: dma channel 8 desc base 0x00100040
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.520337][1]vrx518 0002:01:00.0: dma channel 9 desc base 0x00100048
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.520348][1]vrx518 0002:01:00.0: Section FW_INIT ie_len 1
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.520360][1]vrx518 0002:01:00.0: init st size: 32, addr: 0x100060
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.520371][1]vrx518 0002:01:00.0: Section ACA FW ie_len 5
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.520388][1]vrx518 0002:01:00.0: aca txin fw offset 0x0 size 20 loc 0x50800 fw base c1ced19c
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.520403][1]vrx518 0002:01:00.0: aca txout fw offset 0x14 size 4 loc 0x50900 fw base c1ced1b0
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.520417][1]vrx518 0002:01:00.0: aca rxin fw offset 0x18 size 4 loc 0x50a00 fw base c1ced1b4
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.520440][1]vrx518 0002:01:00.0: aca rxout fw offset 0x1c size 24 loc 0x50b00 fw base c1ced1b8
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.520464][1]vrx518 0002:01:00.0: aca Genrisc fw offset 0x34 size 2256 loc 0x58000 fw base c1ced1d0
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.520769][1]vrx518 0002:01:00.0: aca dma init done
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.520785][1]vrx518 0002:01:00.0: aca basic config done
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.521535][1]vrx518 0002:01:00.0: aca_hif_param_init
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.521553][1]vrx518 0002:01:00.0: aca txin init done
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.521561][1]vrx518 0002:01:00.0: aca txout init done
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.521571][1]vrx518 0002:01:00.0: aca rxout init done
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.521581][1]vrx518 0002:01:00.0: aca rxin init done
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.521593][1]vrx518 0002:01:00.0: init_addr: 100060
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.521605][1]vrx518 0002:01:00.0: aca_hif_param_init_done
Jan  1 01:01:28 7590-Ort kern.debug kernel: [   89.521614][1]vrx518 0002:01:00.0: aca mdm init done
Jan  1 01:01:28 7590-Ort kern.info kernel: [   89.521622][1]vrx518 0002:01:00.0: aca init done
Jan  1 01:01:28 7590-Ort kern.info kernel: [   89.521663][1]Flushing the TMU queues - cbm_pid=4, tmu_port=4.
Jan  1 01:01:28 7590-Ort kern.info kernel: [   89.521708][1][cbm] { dp_q_enable : 4145 } q_buff_num: 8
Jan  1 01:01:28 7590-Ort kern.info kernel: [   89.521768][1][cbm] { dp_q_enable : 4186 }enable 1 remap -1
Jan  1 01:01:28 7590-Ort kern.info kernel: [   89.522141][1][cbm] { dp_q_enable : 4186 }enable 1 remap -1
Jan  1 01:01:28 7590-Ort kern.info kernel: [   89.522348][1][cbm] { dp_q_enable : 4186 }enable 1 remap -1
Jan  1 01:01:28 7590-Ort kern.info kernel: [   89.522503][1][cbm] { dp_q_enable : 4186 }enable 1 remap -1
Jan  1 01:01:28 7590-Ort kern.info kernel: [   89.522662][1][cbm] { dp_q_enable : 4186 }enable 1 remap -1
Jan  1 01:01:28 7590-Ort kern.info kernel: [   89.522848][1][cbm] { dp_q_enable : 4186 }enable 1 remap -1
Jan  1 01:01:28 7590-Ort kern.info kernel: [   89.523032][1][cbm] { dp_q_enable : 4186 }enable 1 remap -1
Jan  1 01:01:28 7590-Ort kern.info kernel: [   89.523215][1][cbm] { dp_q_enable : 4186 }enable 1 remap -1
Jan  1 01:01:28 7590-Ort kern.info kernel: [   89.523405][1]Resetting CBM port - port_id=8, cbm_port_id=4.
Jan  1 01:01:28 7590-Ort kern.info kernel: [   89.523513][1][cbm] { dp_enable : 3659 }ep=8 tmu_port=4 queue=32 sid=16
Jan  1 01:01:28 7590-Ort kern.info kernel: [   89.523544][1][cbm] { dp_enable : 3700 }enable queue 32
Jan  1 01:01:28 7590-Ort kern.info kernel: [   89.523550][1][cbm] { dp_enable : 3701 }flag 1 refcnt 1024
Jan  1 01:01:28 7590-Ort kern.info kernel: [   89.523556][1][cbm] { dp_enable : 3700 }enable queue 62
Jan  1 01:01:28 7590-Ort kern.info kernel: [   89.523560][1][cbm] { dp_enable : 3701 }flag 1 refcnt 0
Jan  1 01:01:28 7590-Ort kern.info kernel: [   89.523566][1][cbm] { dp_enable : 3700 }enable queue 63
Jan  1 01:01:28 7590-Ort kern.info kernel: [   89.523570][1][cbm] { dp_enable : 3701 }flag 1 refcnt 0
Jan  1 01:01:28 7590-Ort kern.info kernel: [   89.523575][1][cbm] { dp_enable : 3700 }enable queue 64
Jan  1 01:01:28 7590-Ort kern.info kernel: [   89.523580][1][cbm] { dp_enable : 3701 }flag 1 refcnt 0
Jan  1 01:01:28 7590-Ort kern.info kernel: [   89.523585][1][cbm] { dp_enable : 3700 }enable queue 65
Jan  1 01:01:28 7590-Ort kern.info kernel: [   89.523590][1][cbm] { dp_enable : 3701 }flag 1 refcnt 0
Jan  1 01:01:28 7590-Ort kern.info kernel: [   89.523595][1][cbm] { dp_enable : 3700 }enable queue 66
Jan  1 01:01:28 7590-Ort kern.info kernel: [   89.523600][1][cbm] { dp_enable : 3701 }flag 1 refcnt 0
Jan  1 01:01:28 7590-Ort kern.info kernel: [   89.523605][1][cbm] { dp_enable : 3700 }enable queue 67
Jan  1 01:01:28 7590-Ort kern.info kernel: [   89.523610][1][cbm] { dp_enable : 3701 }flag 1 refcnt 0
Jan  1 01:01:28 7590-Ort kern.info kernel: [   89.523615][1][cbm] { dp_enable : 3700 }enable queue 68
Jan  1 01:01:28 7590-Ort kern.info kernel: [   89.523619][1][cbm] { dp_enable : 3701 }flag 1 refcnt 0
Jan  1 01:01:28 7590-Ort kern.info kernel: [   89.523650][1]vrx518_tc:ptm_tc_load: PTM TC is successfully loaded
Jan  1 01:01:29 7590-Ort kern.debug kernel: [   90.011853][1]vrx518_tc:ptm_erb_addr_get: idx: 0, data addr: 0xbc230000,  desc_addr: 0xbc360000
Jan  1 01:01:52 7590-Ort kern.info kernel: [  113.088452][0]guest: port 1(guest_st1) entered blocking state
Jan  1 01:01:52 7590-Ort kern.info kernel: [  113.088499][0]guest: port 1(guest_st1) entered disabled state
Jan  1 01:01:52 7590-Ort kern.info kernel: [  113.089404][0]device guest_st1 entered promiscuous mode
Jan  1 01:01:52 7590-Ort kern.notice kernel: [  113.089480][0]audit: type=1700 audit(112.544:12): dev=guest_st1 prom=256 old_prom=0 auid=4294967295 uid=0 gid=0 ses=4294967295
Jan  1 01:01:52 7590-Ort kern.info kernel: [  113.090022][0]guest: port 1(guest_st1) entered blocking state
Jan  1 01:01:52 7590-Ort kern.info kernel: [  113.090046][0]guest: port 1(guest_st1) entered forwarding state
Jan  1 01:01:52 7590-Ort kern.info kernel: [  113.090875][0]IPv6: ADDRCONF(NETDEV_CHANGE): guest: link becomes ready
Jan  1 00:01:52 7590-Ort user.err multid[2232]: setup_mc_mdb: netlink_mdb_add_group failed
Jan  1 01:02:01 7590-Ort kern.info kernel: [  121.739250][3]/proc/tffs: info request: success
Jan  1 01:02:22 7590-Ort kern.warn kernel: [  143.073090][1][1]system-load  33% loadavg 2.88 1.30 0.49 - task runtime:4% max:kworker/1:2 0%  pgstat: sum=177519 free=69232 slab=5004 alloc=4342/s fault=5782/s ai_user:6.50/s 0x559845f0 multid (sleep 9)
Jan  1 01:02:28 7590-Ort kern.warn kernel: [  149.037340][3][3]system-load  30% loadavg 2.89 1.33 0.51 - task runtime:13% max:kworker/3:1 10%  pgstat: sum=177414 free=69143 slab=5016 alloc=5092/s fault=6246/s (sleep 2)
Jan  1 01:02:30 7590-Ort kern.info kernel: [  150.559529][1]vrx518_tc:ptm_showtime_enter: Line[0]: show time enter!!
Jan  1 00:02:31 7590-Ort user.err dsld[2386]: Sync!!!!!!; media=VDSL
Jan  1 01:02:34 7590-Ort kern.info kernel: [  155.230659][2]kdsld: internet: set_snd_ipaddr: XXX
Jan  1 01:02:34 7590-Ort kern.err kernel: [  155.230717][2]internet: dp_ipmasq_invalidate_masqentries: start: 0 mappings, 0 entries.
Jan  1 01:02:34 7590-Ort kern.err kernel: [  155.230899][2]internet: dp_ipmasq_invalidate_masqentries: end: 0 mappings, 0 entries.
Jan  1 01:02:34 7590-Ort kern.info kernel: [  155.234156][2]kdsld: IPv6: internet: link local fe80::464e:6dff:fe17:a2e7 remote fe80::42a6:77ff:fe38:2365
Jan  1 01:02:34 7590-Ort kern.info kernel: [  155.239279][2]kdsld: IPv6: internet: gu XXX remote ::
Jan  1 01:02:34 7590-Ort kern.info kernel: [  155.434455][2]kdsld: IPv6: internet: gu  XXX remote ::
Jan  1 01:02:35 7590-Ort user.notice ONLINECHANGED[5066]: [onlineipv6] waiting
Jan  1 01:02:35 7590-Ort user.notice ONLINECHANGED[5051]: [online] approved
Jan  1 01:02:35 7590-Ort user.notice ONLINECHANGED[5051]: [online] executing /etc/onlinechanged/00-get_ip
Jan  1 01:02:35 7590-Ort user.notice ONLINECHANGED[5051]: [online] executing /tmp/flash/onlinechanged/onlinechanged-cgi
Jan  1 01:02:35 7590-Ort user.notice ONLINECHANGED[5051]: [online] executing /etc/onlinechanged/webdav_net
Jan  1 01:02:35 7590-Ort user.notice ONLINECHANGED[5051]: [online]  * webdav_net online status_onlinev4
Nov 12 17:27:12 7590-Ort user.notice ONLINECHANGED[5051]: [online]  * 6
Nov 12 17:27:12 7590-Ort user.notice ONLINECHANGED[5051]: [online] finished
Nov 12 17:27:12 7590-Ort user.notice ONLINECHANGED[5066]: [onlineipv6] approved
Nov 12 17:27:12 7590-Ort user.notice ONLINECHANGED[5066]: [onlineipv6] executing /etc/onlinechanged/00-get_ip
Nov 12 17:27:12 7590-Ort user.notice ONLINECHANGED[5066]: [onlineipv6] executing /tmp/flash/onlinechanged/onlinechanged-cgi
Nov 12 17:27:12 7590-Ort user.notice ONLINECHANGED[5066]: [onlineipv6] executing /etc/onlinechanged/webdav_net
Nov 12 17:27:12 7590-Ort user.notice ONLINECHANGED[5066]: [onlineipv6]  * webdav_net onlineipv6 status_onlinev4v6
Nov 12 17:27:13 7590-Ort kern.warn kernel: [  157.868537][2][2]system-load  26% loadavg 2.92 1.39 0.54 - task runtime:10% max:ctlmgr 1%  softirqs:2.21% (NET_RX 43%) pgstat: sum=176459 free=68274 slab=5077 alloc=6809/s fault=8572/s ai_sys:2.00/s 0x887c4b70 find_option+0x1
Nov 12 16:27:13 7590-Ort user.err telefon[2626]: set initial telefon time from linux time to 17:27:13 12.11 2020!
Nov 12 17:27:13 7590-Ort user.notice ONLINECHANGED[5066]: [onlineipv6]  * 6
Nov 12 17:27:13 7590-Ort user.notice ONLINECHANGED[5066]: [onlineipv6] finished
Nov 12 17:27:13 7590-Ort kern.info kernel: [  158.707485][0]/proc/tffs: info request: success
Nov 12 17:27:14 7590-Ort kern.warn kernel: [  159.038538][3][3]system-load  25% loadavg 2.92 1.39 0.54 - task runtime:13% max:ctlmgr 4%  softirqs:1.12% (netiface_xmit_queue_function [kdsldmod] 25%) pgstat: sum=176677 free=68455 slab=5082 alloc=2534/s fault=3451/s ai_user
Nov 12 17:27:15 7590-Ort kern.err kernel: [  159.903041][1]AVM_WATCHDOG_release(hdl=9 ctlmgr): success
Nov 12 17:27:16 7590-Ort kern.warn kernel: [  161.044370][0][0]system-load  31% loadavg 2.92 1.41 0.55 - task runtime:27% max:feedd 10%  softirqs:1.05% (TIMER 63%) pgstat: sum=176108 free=67823 slab=5085 alloc=7837/s fault=10202/s ai_user:0.70/s 0x55972884 multid (sleep
Nov 12 17:27:16 7590-Ort kern.info kernel: [  161.188451][0]guest: port 1(guest_st1) entered disabled state
Nov 12 17:27:16 7590-Ort kern.info kernel: [  161.212275][0]device guest_st1 left promiscuous mode
Nov 12 17:27:16 7590-Ort kern.notice kernel: [  161.212348][0]audit: type=1700 audit(1605198436.485:13): dev=guest_st1 prom=0 old_prom=256 auid=4294967295 uid=0 gid=0 ses=4294967295
Nov 12 17:27:16 7590-Ort kern.info kernel: [  161.212363][0]guest: port 1(guest_st1) entered disabled state
Nov 12 16:27:16 7590-Ort user.err multid[2232]: setup_mc_mdb: netlink_mdb_add_group failed
Nov 12 17:27:16 7590-Ort kern.info kernel: [  161.275894][1]guest: port 1(guest_st1) entered blocking state
Nov 12 17:27:16 7590-Ort kern.info kernel: [  161.275938][1]guest: port 1(guest_st1) entered disabled state
Nov 12 17:27:16 7590-Ort kern.info kernel: [  161.276854][1]device guest_st1 entered promiscuous mode
Nov 12 17:27:16 7590-Ort kern.notice kernel: [  161.276927][1]audit: type=1700 audit(1605198436.549:14): dev=guest_st1 prom=256 old_prom=0 auid=4294967295 uid=0 gid=0 ses=4294967295
Nov 12 17:27:16 7590-Ort kern.info kernel: [  161.277467][1]guest: port 1(guest_st1) entered blocking state
Nov 12 17:27:16 7590-Ort kern.info kernel: [  161.277490][1]guest: port 1(guest_st1) entered forwarding state
Nov 12 17:27:18 7590-Ort kern.warn kernel: [  163.156684][1][1]system-load  32% loadavg 2.92 1.41 0.55 - task runtime:13% max:gcupd 4%  pgstat: sum=175903 free=67615 slab=5084 alloc=3372/s fault=4407/s ai_user:6.90/s 0x55972884 multid (sleep 10)
Nov 12 17:27:22 7590-Ort kern.err kernel: [  167.641559][1]AVM_WATCHDOG_release(hdl=9 ctlmgr): success
Nov 12 17:27:23 7590-Ort kern.warn kernel: [  167.865282][2][2]system-load  26% loadavg 2.93 1.44 0.56 - task runtime:12% max:pbd 2%  softirqs:8.57% (do_cbm_tasklet 17%) pgstat: sum=175939 free=67645 slab=5096 alloc=1378/s fault=1823/s ai_user:0.90/s 0x55972884 multid (s
Nov 12 17:27:24 7590-Ort kern.warn kernel: [  169.037558][3][3]system-load  27% loadavg 2.93 1.44 0.56 - task runtime:22% max:pbd 9%  softirqs:1.51% (pa_rps_dequeue_task 31%) pgstat: sum=175697 free=67425 slab=5096 alloc=554/s fault=717/s (sleep 1)
Nov 12 17:27:26 7590-Ort kern.info kernel: [  171.491931][2]kdsld: IPv6: internet: gu 2003:d8:5fff:2912:464e:6dff:fe17:a2e7 remote ::
Nov 12 17:27:37 7590-Ort kern.err kernel: [  182.339523][3]AVM_WATCHDOG_release(hdl=9 ctlmgr): success
Nov 12 17:27:39 7590-Ort kern.warn kernel: [  183.912366][0]TCP: dsl: Driver has suspect GRO implementation, TCP performance may be compromised.
Nov 12 16:27:41 7590-Ort daemon.info chronyd[5776]: chronyd version 3.5 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP -SCFILTER -SIGND +ASYNCDNS -SECHASH +IPV6 -DEBUG)
Nov 12 16:27:41 7590-Ort daemon.warn chronyd[5776]: commandkey directive is no longer supported
Nov 12 17:27:42 7590-Ort kern.info kernel: [  187.535543][2]kdsld: IPv6: internet: gu 2003:d8:5fff:2912:464e:6dff:fe17:a2e7 remote ::


    
12.11.2020 17:27 – up 3 min – optimiert für Mozilla Firefox

€dit:
Neue Testzeiträume sind ab morgen früh wieder verfügbar...
 
Zuletzt bearbeitet:
Nun schlägt offenbar ein Watchdog in "untrustedd" zu ... und zwar zweimal, wobei ich mal denke, daß Du die Box auch mit dem 07.21-Image hast zweimal hintereinander starten lassen - die Uhrzeiten sprächen jedenfalls dafür.

Diesen Daemon gibt's erst seit 07.19 und er dient wohl irgendwie zu Sammeln von Informationen von anderen Quellen - ich nahm zunächst an, daß es dabei um welche von den Mesh-Teilnehmern gehen würde. Aber die genauen Aufgaben sind m.W. noch von niemandem (außerhalb AVM) genauer untersucht und beschrieben worden.

Ich habe mir den irgendwann beim Blick unter die Haube in 07.19 etwas genauer angesehen und dabei festgestellt, daß die von diesem Daemon importierten Bibliotheken sich mit dem Ein- und Auspacken von Datenstrukturen (libminneapolis.so), der Verwaltung irgendwelcher Datenquellen (libasec.so) und der Implementierung von Transportprotokollen (libasecutil.so -> Server, Client, Protokolle, etc.) befassen, wobei letztere wohl auf ein FOSS-Project unter MIT-Lizenz zurückgreift: https://nng.nanomsg.org/man/v1.3.2/nng.7.html - zumindest deuten Funktionsnamen darauf hin und auch nicht nur einer, so daß das ansonsten schon ein komisches Zusammentreffen wäre.

Weil der eben auch weitgehend unbekannt ist, was die Aufgaben und die Funktion angeht, kann ich mir auch nur sehr schwer vorstellen, daß hier tatsächlich Freetz für das Problem verantwortlich sein soll. Daher stelle ich mal eine ganz dumme Frage, die das praktisch "auf Anfang" dreht: Hast Du diese Box auch schon mal mit der originalen AVM-Firmware 07.2x (und zwar auch über ca. 24 h) betreiben können? Denn wenn meine Vermutungen zu den Aufgaben des "untrustedd" stimmen sollten (es sind eben auch nur Annahmen), dann würde natürlich die Konfiguration der Box (die sie ja bei den meisten auch von der vorhergehenden Version erbt) auch eine entscheidende Rolle spielen und ggf. hilft es dann tatsächlich schon, wenn man die Box neu einrichtet. Ich habe jetzt nichts gelesen, daß das bei Dir schon passiert wäre mit einer solchen Neueinrichtung ... aber ebensowenig, ob Du das tatsächlich (nachdem die 07.12 ja "mit Freetz" war) schon mal mit der AVM-Firmware gegengeprüft hast.

Etwas anderes fällt mir zu diesem Daemon jedenfalls auch nicht ein ... der verwendet zwar seinerseits auch zwei neue TFFS-Nodes (240 und 241), aber auch mit denen sollte sich Freetz vertragen, denn das verwendet ja die 60 (0x3C) und dürfte damit auch nichts vom "untrustedd" überschreiben. Insofern fehlt mir da etwas der Zusammenhang damit, warum Freetz hier die Ursache sein sollte.

Aber man sieht oben ja auch, daß der Systemstart-Watchdog für Freetz tatsächlich zu kurz sein könnte (auch wenn der "untrustedd" nicht abstürzen sollte) - die Box synchronisiert erst sehr spät (nach mehr als 2 1/2 Minuten ab Kernel-Initialisierung) und da es (aus dem Gedächtnis - ich müßte erst nachsehen, ob das (a) in Freetz noch so ist und dann auch noch (b) in Freetz-NG erhalten blieb) irgendwo auch ein Warten auf die Internet-Verbindung (und das Setzen einer gültigen Uhrzeit) gab beim Start einiger Freetz-Pakete, kommt damit dann der Watchdog auch garantiert ins Schleudern, wenn der erst dann vom "supervisor" abgebrochen wird, wenn auch der letzte Service für das gewünschte "run target" sein OK gegeben hat.

Hast Du nun eigentlich die Änderungen beim Start der "rcmod.service" drin gelassen und nur das Timeout verlängert bei diesem Anlauf oder hast Du das alles wieder zurückgedreht?

Wenn Du das nächste Mal probierst, baue mal noch ein "cat /proc/avm/wdt" ein (wenn der Start nach meinem Vorschlag umgebaut sein sollte - ansonsten vergiß es, denn es macht keinen Sinn, wenn hier zwei Leute, noch dazu mit unterschiedlichen Ansichten, woran es liegen könnte, parallel suchen ... dann lasse ich den Ideen von @cuma den Vortritt und halte mich raus), damit man sehen kann, ob der Watchdog für den Startvorgang überhaupt noch aktiv ist oder ob das vielleicht jetzt schon das nächste Problem ist, dem man hier nachjagt. Denn wenn der Start von "rcmod.service" entkoppelt ist (und da nicht noch etwas fehlt o.ä.), sollte es eigentlich auch kein Problem sein, wenn da tatsächlich irgendjemand auf Internet und Uhrzeit warten sollte in der "rc.mod" oder einem von dort gestarteten Skript (das "rc.mod" startet ja dann auch die Freetz-Pakete).
 
Hast Du nun eigentlich die Änderungen beim Start der "rcmod.service" drin gelassen und nur das Timeout verlängert bei diesem Anlauf oder hast Du das alles wieder zurückgedreht?
Bin ITler und habe gelernt, dass man nicht alle Änderungen auf einmal testet.
Wollte es einmal getrennt testen, damit nicht 99 Efekte aufeinander wirken und man am Ende nicht mehr weiß welcher Effekt was gemacht hat.

Kann jetzt noch deine Änderung dazu nehmen.

"cat /proc/avm/wdt"
Okay worein?

Wie die
Code:
cat /dev/debug > /var/media/ftp/$(date +%s)_dev_debug.txt
in die rc.custom?

Weil der eben auch weitgehend unbekannt ist, was die Aufgaben und die Funktion angeht, kann ich mir auch nur sehr schwer vorstellen, daß hier tatsächlich Freetz für das Problem verantwortlich sein soll. Daher stelle ich mal eine ganz dumme Frage, die das praktisch "auf Anfang" dreht: Hast Du diese Box auch schon mal mit der originalen AVM-Firmware 07.2x (und zwar auch über ca. 24 h) betreiben können? Denn wenn meine Vermutungen zu den Aufgaben des "untrustedd" stimmen sollten (es sind eben auch nur Annahmen), dann würde natürlich die Konfiguration der Box (die sie ja bei den meisten auch von der vorhergehenden Version erbt) auch eine entscheidende Rolle spielen und ggf. hilft es dann tatsächlich schon, wenn man die Box neu einrichtet. Ich habe jetzt nichts gelesen, daß das bei Dir schon passiert wäre mit einer solchen Neueinrichtung ... aber ebensowenig, ob Du das tatsächlich (nachdem die 07.12 ja "mit Freetz" war) schon mal mit der AVM-Firmware gegengeprüft hast.
Ne hab noch nicht gegengeprüft könnte ich machen.
 
Auf's Internet wird nicht gewartet, außer
- external, falls so konfiguriert. External wird aber durch mounten von USB-Partitionen getriggert (durch freetzmount/udevmount)
- der DEB-watchdog rebootet falls keine Inetrnet da ist (genau weiss ich das nicht)
Ich hab hier auch eine lahme Internetverbindung. Also nicht nur vom Durchsatz sonder der Sync kann auch mal mehrere Minurten brauchen

Beim "2x booten" muss man darauf achten, dass man nicht aus Versehen den Flashvorgang im RAM mitzählt. Das passiert mir auf der Console manchmal

Also den Watchdog global auf 5 Minuten setzen für FOS7+? AVM nutzt aktuell 2 oder 4
Wenn man "viel" Packages hat kann das Starten auch "viel" länger dauern

2
Code:
grep 'm_watchdog init-start 120' */etc/init.d/* 2>/dev/null -l | sed 's!/.*!!g'
FRITZ.Box_4020.de-en-es-it-fr-pl.147.07.01
FRITZ.Box_6430_Cable-07.12
FRITZ.Box_6490_Cable-07.12
FRITZ.Box_6490_Cable.de-en-es-it-fr-pl.141.07.02
FRITZ.Box_6590_Cable-07.12
FRITZ.Box_6590_Cable.de-en-es-it-fr-pl.148.07.02
FRITZ.Box_6591_Cable-07.04
FRITZ.Box_6591_Cable-07.13
FRITZ.Box_6660_Cable-07.15
FRITZ.Box_6820_LTE.de-en-es-it-fr-pl.142.07.01
FRITZ.Box_6820v1_LTE-de-en-es-it-fr-pl-07.13
FRITZ.Box_6820v2_LTE-de-en-es-it-fr-pl-07.13
FRITZ.Box_6890_LTE-en-de-es-it-fr-pl-nl-07.13
FRITZ.Box_6890_LTE.en-de-es-it-fr-pl-nl.162.07.03
FRITZ.Box_7362_SL-07.12
FRITZ.Box_7362_SL.131.07.01
FRITZ.Box_7430-07.12
FRITZ.Box_7430.146.07.01
FRITZ.Box_7430.en-de-es-it-fr-pl.146.07.01
FRITZ.Box_7430.int.07.12
FRITZ.Box_7520-07.14
FRITZ.Box_7530.07.13.int
FRITZ.Box_7530-07.14
FRITZ.Box_7530.164.07.02
FRITZ.Box_7530.en-de-es-it-fr-pl-nl.164.07.02
FRITZ.Box_7560-07.12
FRITZ.Box_7560.149.07.01
FRITZ.Box_7560.en-de-es-it-fr-pl.149.07.01
FRITZ.Box_7560.int.07.12
FRITZ.Box_7580-07.12
FRITZ.Box_7580.153.07.01
FRITZ.Box_7581-07.13
FRITZ.Box_7582-07.13
FRITZ.Box_7583-07.12
FRITZ.Box_7583.int.07.15
FRITZ.Box_7590-07.12
FRITZ.Box_7590.154.07.01
FRITZ.Box_7590.en-de-es-it-fr-pl-nl.154.07.01
FRITZ.Box_7590.int.07.13
FRITZ.Box_WLAN_Repeater_1750E-07.12
FRITZ.Box_WLAN_Repeater_1750E.en-de-es-it-fr-pl.134.07.01
FRITZ.Box_WLAN_Repeater_450E-07.12
FRITZ.Box_WLAN_Repeater_450E.en-de-es-it-fr-pl.128.07.01
FRITZ.Box_WLAN_Repeater_DVB_C-07.08-66669-Inhaus
FRITZ.Box_WLAN_Repeater_DVB_C.en-de-es-it-fr-pl.133.07.01
FRITZ.Powerline_1240E.150.07.01
FRITZ.Powerline_1240E.150.07.12
FRITZ.Powerline_540E.129.07.01
FRITZ.Powerline_540E.129.07.12
FRITZ.Powerline_546E.118.07.01
FRITZ.Powerline_546E.118.07.12
FRITZ.Repeater_1200-07.14
FRITZ.Repeater_2400-07.12
FRITZ.Repeater_3000-07.14
FRITZ.Repeater_3000.en-de-es-it-fr-pl.174.07.04

4
Code:
grep 'm_watchdog init-start 240' */etc/init.d/* 2>/dev/null -l | sed 's!/.*!!g'
FRITZ.Box_3490-07.12
FRITZ.Box_3490-07.12.int
FRITZ.Box_3490.140.07.01
FRITZ.Box_3490.en-de-es-it-fr-pl.140.07.01
FRITZ.Box_4040-07.14
FRITZ.Box_4040.de-en-es-it-fr-pl.155.07.01
FRITZ.Box_5490-07.12-V2
FRITZ.Box_5490.de-en-es-it-fr-pl.151.07.01
FRITZ.Box_5491-07.12
FRITZ.Box_5491.de-en-es-it-fr-pl.171.07.01
FRITZ.Box_7490-07.12
FRITZ.Box_7490.07.12.int
FRITZ.Box_7490.113.07.01
FRITZ.Box_7490.en-de-es-it-fr-pl.113.07.01
FRITZ.Powerline_1260E.157.07.01
FRITZ.Powerline_1260E.157.07.12

Von den ganzen in Freetz unterstützten Geräten haben nur diese den untrustedd

Code:
 find . -name untrustedd|sort
./FRITZ.Box_6490_Cable-07.20/usr/bin/untrustedd
./FRITZ.Box_6590_Cable-07.20/usr/bin/untrustedd
./FRITZ.Box_6591_Cable-07.21/usr/bin/untrustedd
./FRITZ.Box_6820v1_LTE-07.19-82252-LabBETA/usr/bin/untrustedd
./FRITZ.Box_6820v2_LTE-07.19-82254-LabBETA/usr/bin/untrustedd
./FRITZ.Box_6820v3_LTE-07.19-82255-LabBETA/usr/bin/untrustedd
./FRITZ.Box_6850_5G-07.19-82499-Inhaus/usr/bin/untrustedd
./FRITZ.Box_6850_LTE-07.21/usr/bin/untrustedd
./FRITZ.Box_6890_LTE-07.21/usr/bin/untrustedd
./FRITZ.Box_7430-07.21/usr/bin/untrustedd
./FRITZ.Box_7490-07.21/usr/bin/untrustedd
./FRITZ.Box_7520-07.21/usr/bin/untrustedd
./FRITZ.Box_7530-07.21/usr/bin/untrustedd
./FRITZ.Box_7580-07.21/usr/bin/untrustedd
./FRITZ.Box_7583-07.21/usr/bin/untrustedd
./FRITZ.Box_7583_VDSL-07.19-79748-intern/usr/bin/untrustedd
./FRITZ.Box_7590-07.21/usr/bin/untrustedd
./FRITZ.Box_7590_AX-07.19-80575-intern/usr/bin/untrustedd
 
dass man nicht alle Änderungen auf einmal testet.
Man sollte sich aber zuvor vergewissern, daß die Änderungen auch tatsächlich - wie geplant - ausgeführt wurden und gewirkt haben.

Deshalb habe ich ja noch die Aufforderung nachgeschoben, diverse Protokolle zu sichern, damit man nachsehen kann, was da jeweils angeworfen wurde und wie weit das kam. Von Deinem ersten Versuch mit den von mir vorgeschlagenen Änderungen wissen wir bisher ja auch nur, daß die Box offenbar erneut abgestürzt ist, weil wohl das "init-done" nicht vom "supervisor" kam.

Hilfreicher wäre es aber zu wissen, was der in der Zwischenzeit alles gestartet hat, wie die Abhängigkeiten der Services NACH dem Patch aussehen (das Kommando dazu hatte ich weiter oben verlinkt) und welche Services er gestartet hat, die sich jetzt in welchem Zustand befinden (auch das steht weiter oben als Kommando zur Abfrage).

Für den erwähnten Versuch ist nicht einmal - sicher - bekannt, ob dabei der "rcmod.service" überhaupt gestartet wurde oder ob nicht vielleicht der "supervisor" diese (unabhängigen) Services erst mal in eine Warteschlange einreiht, deren Abarbeitung erst dann begonnen wird, wenn der derzeit angeordnete "Zustand" (auch das "multi-user.target" für die Abhängigkeiten der Dienste, die vor dem "init-done" gestartet sein müssen, ist ja nur eine Annahme) erreicht wurde. Das wäre auch nicht absolut ungewöhnlich ... irgendwie muß der "supervisor" ja (wie der "systemd" auch) die Transitions serialisieren, weil das System ja nicht gleichzeitig in zwei Zuständen sein kann bzw. nicht gleichzeitig versuchen kann, zwei (verschiedene) Zustände einzunehmen.

Daß der Start aus der "tail" heraus nur die erste Idee war und man ggf. nach einem besseren Platz dafür suchen müßte, wenn das so nicht funktionieren sollte, hatte ich (iirc) schon weiter vorne geschrieben - ebenso, daß man natürlich auch einfach zwischen "rcmod.service" und "999-zzz-rcmod" noch ein weiteres Skript einbauen kann, das dann die "rc.mod" vom Service entkoppelt - dann kann man den auch wieder zum Bestandteil von "multi-user.target" machen. Denn daß so etwas prinzipiell auch möglich ist und funktioniert, zeigt ja meine Umsetzung für die "rc.user" in "modfs", die m.W. auch für GRX-Boxen (konkret auch die 7590) funktioniert und nicht zum Absturz der Box führt, auch wenn man die Watchdogs nicht anfaßt.

Das Sichern der ganzen Protokolldaten bringt auch nicht wirklich etwas, wenn man das "von Hand" machen will ... das kann man problemlos skripten und dann läuft es garantiert auch viel flüssiger und schafft es, mehr Daten vor dem Neustart zu sichern - bis hin zu eingestreuten "sync"-Aufrufen, damit Buffer in den Flash-Speicher geschrieben werden. Es bringt jedenfalls nichts, eine Idee zu verwerfen, wenn man sich nicht zuvor davon überzeugt hat, daß man sie auch fehlerfrei und wie geplant umgesetzt hat und sie dann nicht den gewünschten Erfolg erzielte.

Zumal ja das Verlängern des Timeouts nun nicht so "unübersichtlich" ist als Änderung, daß davon irgendwelche negativen Auswirkungen auf anderes zu erwarten wären (und man das schon als "something completely different" werten müßte, was man nicht mit anderem vermischen sollte) ... im schlechtesten Falle erfolgt der Neustart wegen des abgelaufenen Systemstart-Watchdogs dann eben erst später. Wenn der (rechtzeitig) vom "supervisor" korrekt abgeschaltet wird, ist es auch egal, wieviel Restlaufzeit der noch hatte.

Wenn Du es für andere ordentlich nachvollziehbar machen willst, schreibst Du auch selbst bei jedem neuen Versuch genau dazu, welche Änderungen (bis hin zur Deaktivierung des Watchdog-Patches) da jeweils vorgenommen wurden - dann muß man nicht erst raten oder nachfragen, was dabei - ggü. dem Stand aus dem Repo - geändert wurde.

@cuma:
Ich würde zwar die Zeit bis zum Timeout etwas verlängern, aber nur zum Testen und parallel trotzdem danach suchen, warum der Watchdog nicht sauber abgeschaltet wird. Denn daß der "supervisor" selbst dabei nicht auf das Internet wartet, ist auch klar ... sonst würde ja eine DSL-Störung zu einer ständigen Reboot-Schleife führen.

Da muß es also schon vorher eine Bedingung im "supervisor" geben (der importiert jedenfalls die Funktion "watchdog_init_done" aus der "libwdt.so"), die ihn dazu veranlaßt, den Watchdog auch lange vor dem Ablauf der Zeit (bei anderen waren noch 78 Sekunden übrig) zu deaktivieren und das nur unter Freetz-Bedingungen zu verzögern, denn (noch mal) mein eigener zusätzlicher Service für die "rc.user" (aus "modfs") funktioniert ja auch, ohne daß der "supervisor" da irritiert wird und dessen Service-Einstellungen sehen auch so aus, wie die für "rcmod.service".

Nur die Arbeitsweise in der von dort aufgerufenen Shell-Datei unterscheidet sich eben deutlich ... zuvor hatte ich das auch über "delay" entkoppelt, nur haut dann ein Neustart des "multid" (der u.U. von der AVM-Firmware beim "online" ausgelöst werden kann) auch ins Kontor, weil sich der "multid" keinen der Aufträge merkt, die er per "delaystart" als IPC-Kommando erhalten hat, wenn er neu gestartet wird. Danach habe ich das auf "nohup" umgestellt und auch das funktioniert (soweit ich das gehört habe und einige haben sich wohl auch eine 7590 so modifiziert, wobei ich natürlich jeweils nicht die Hand dafür ins Feuer legen kann, daß die auch alle das entsprechende "modscript" benutzen).

Da es sich hier ja um ein Timing-Problem handelt (der "supervisor" muß vor dem Ablauf des Watchdogs zu der Überzeugung kommen, daß der Start abgeschlossen ist), muß man eben versuchen, das "blockierende Element" zu isolieren und aller Wahrscheinlichkeit nach liegt das nun mal in einer Änderung durch Freetz(-NG), weil die originale Firmware ja auch funktioniert. Da liegt es - am Beginn - für mich nun mal am Nächsten, daß man versucht, den Start der ganzen Freetz-Pakete vom Start des FRITZ!OS zu entkoppeln ... das war (spätestens bei der "rc.custom" oder der "debug.cfg"/"rc.user") aber schon immer mein Credo, weil ansonsten falsche Einträge in diesen Dateien (oder falsches Vorgehen) das gesamte System beinträchtigen können (also der Freetz-Benutzer sich das System damit - sehr leicht - zerschießen kann) - beim Start über "rc.S" wurde dann eben der Startvorgang von "init" nie wirklich beendet, weil er immer noch irgendwo in der "debug.cfg" festhing.

Genau für die Feststellung, in welchen Zustand sich der "supervisor" denn jeweils gerade befindet, muß man eben die Abhängigkeiten der Services ermitteln (das reicht einmalig) und den aktuellen Zustand dieser Service-Units - das aber (zumindest bei der Fehlersuche) so häufig wie möglich. Dann kann man daraus schließen, wo er zu diesem Zeitpunkt gerade ist und welcher Service da wohl auf welchen wartet, damit es weitergehen kann und irgendwann doch noch das "init-done" abgesetzt wird. Nachdem das erwähnte "watchdog_init_done" auch von keinem anderen Binary importiert wird (sagt jedenfalls mein "grep"), kann es eigentlich auch nur dieser Prozess sein, der dafür zuständig wäre, den Watchdog wieder abzuschalten.
 
Zuletzt bearbeitet:
Man sollte auch hier wieder das supi DEB addon nicht vergessen...
Auszug aus 1.5.1
Code:
    if [ -n "$UPDATE_URL" ]; then
            wget -q -O - "$UPDATE_URL"
            sleep 120
            ipcheck
    fi
Ob das beim Start ausgeführt wird hab ich nicht nachgeschaut, falls ja werden die 2 Minuten locker überschritten. @JokerGermany sollte also auf jeden Fall ohne Addons testen...

Was ist denn der trustedd?
Code:
supervisor -p /lib/systemd/system >/dev/null
[Supervisor] Warning: cpunet.service: could not resolve dependency trustedd.service
[Supervisor] Warning: dsl.service: could not resolve dependency inetd.service
 
Zuletzt bearbeitet:
sollte also auf jeden Fall ohne Addons testen...
Wenn ich das richtig verstanden habe, ist das sogar ein Minimal-Image von Freetz-NG, was er da verwendet? Die ".config.compressed" steht vielleicht auch inzwischen irgendwo hier im Thread - zumindest hatte ich darum gebeten.

Was ist denn der trustedd?
Gab es vielleicht nie? Oder nicht auf den GRX-Boxen, sondern nur auf den "Doppelstern"-Systemen (dafür könnte die Abhängigkeit von "cpunet.service" sprechen)? Zumindest ist der in der 07.24 auch wieder verschwunden bei der 7590.

Mich würde ja eher irritieren, wieso der "inetd.service" zwar nicht existiert, aber noch in den Abhängigkeiten des "dsl.service" auftaucht ... auch wenn da lediglich sichergestellt werden soll, daß der "dsl.service" (erfolgreich) gestartet wurde, bevor dann der "inetd.service" angeworfen wird und damit ein Warten des "dsl.service" auf den "inetd.service" ja ausgeschlossen ist. Aber wenn Du den "inetd.service" entfernst, würde ich auch die Abhängigkeiten der anderen von ihm auflösen. Wer weiß, wann AVM da mal eine "strenge Prüfung" vornimmt. Bei den VR9-Modellen gibt es ja wohl den gesamten "cpunet.service" nicht - in der 113.07.21 sind zumindest auch keine nicht auflösbaren Abhängigkeiten.
 
Wenn ich das richtig verstanden habe, ist das sogar ein Minimal-Image von Freetz-NG, was er da verwendet? Die ".config.compressed" steht vielleicht auch inzwischen irgendwo hier im Thread - zumindest hatte ich darum gebeten.

Natürlich, macht doch keinen Sinn noch 90 weitere Einflussfaktoren zu haben...
Code:
FREETZ_USER_LEVEL_EXPERT=y
 
Doppelstern? Meinst du die Docsis mit arm+x86?
Bei Addon USern ist es üblich das hier nicht anzugeben, da es im ippf nicht gern gesehen ist
Weshlab ich da überhaupt reingeschaut hab, bei mir läuft auf der 7590 der untrustedd schon seit 2 Wochen (aber mit deaktiviertem watchdog)
Code:
 ps|grep trus
S     0  3631   699  4004   620 0:0   Oct30 00:00:00 /usr/bin/untrustedd
Wäre interessant zu wissen was der macht, evtl könnte man den sollte man den entfernen :)
 
Bei Addon USern ist es üblich das hier nicht anzugeben, da es im ippf nicht gern gesehen ist
Etwas nicht anzugeben und ganz klar zu sagen, dass meine keine Addons am laufen hat sind zwei verschiedene paar Schuhe ;)

Es ist nicht mehr möglich in der make menuconfig den AVM Watchdog zu aktivieren, wenn man die 7590 + 7.21 ausgewählt hat.
Habe daher
Code:
FREETZ_PATCH_DISABLE_AVM_WATCHDOG=y
in
Code:
# FREETZ_PATCH_DISABLE_AVM_WATCHDOG is not set
manuell geändert

Alles andere ist Standard.
=> make menuconfig => Expert => FB790 7.2X => make

Es geht hier ja auch erstmal darum das Teil überhaupt stabil unter Freetz + 7.21 laufen zu lassen...
 
Nur um sicher zu gehen ;-)
Also stabil stabil meine, hat 2 Wochen uptime
 
Na ja ... das ist aber ein wenig wie ein stummgeschalteter Countdown zur Selbstzerstörung - nur weil man ihn nicht mehr hört, ist man ja nicht außer Gefahr.

Spannend wäre es ja, was beim derzeitigen Stand von Freetz-NG passiert, wenn man nur den ersten Watchdog (das wäre dann der für den Systemstart und den kann man ja auch separat behandeln) per Patch manuell beendet (das "init-done" kann man auch einfach mit einem avm_watchdog init-done absetzen) und die anderen Watchdogs dann weiterlaufen können (weil man eben kein "disable" für alle macht). Kommt es dann auch bei anderen zu einem Neustart wg. eines anderen Watchdogs (bei @JokerGermany haben wir zumindest mal schon einen, der vor den 300 Sekunden für den Systemstart-Watchdog zuschlägt), ist es wohl deutlich mehr als ein einzelnes Problem, was man hier sucht.

Denn - nur noch einmal zur Erinnerung - ohne Freetz läuft das System auch dann, wenn man die Watchdogs nicht selbst durcheinander wirbelt oder gar komplett abschaltet.
 
  • Like
Reaktionen: JokerGermany
Stabil ists ja. Der Watchdog soll ja nur Crashs von avm's Blobs ausbügeln. Ich würde trotzdem gerne wissen weshalb das so ist.
Bei der 7270 war der watchdog-timeout übrigens noch 8 Minuten
 
Also in die /freetz-ng-2020-11-09/patches/scripts/115-systemd-services.sh das hier:

Code:
[ -n "$SYSTEMD_CORE_MOD_DIR" ] || return 0


echo1 "adding modload.service"

cat << 'EOF' > "${FILESYSTEM_MOD_DIR}/lib/systemd/system/modload.service"

[Unit]

ExecStart=/etc/boot.d/core/20-modload

Type=oneshot

DefaultDependencies=no

After=tffs.service environment.service

[Install]

WantedBy=environment.target

EOF


echo1 "adding rcmod.service"

cat << 'EOF' > "${FILESYSTEM_MOD_DIR}/lib/systemd/system/rcmod.service"

[Unit]

ExecStart=/etc/boot.d/core/99-zzz-rcmod

Type=oneshot

DefaultDependencies=no

After=net.service modload.service

EOF


echo "svctl start rcmod" >> "${FILESYSTEM_MOD_DIR}/etc/boot.d/core/tail"

Also wenn ich den patch mit einfließen lasse, kommt er nach wie vor gar nicht erst hoch.

Noch nicht einmal anpingbar


Ich dachte damit soll nur der Freetz Teil verzögert werden?


Hier die cat /dev/debug (bin mir aber nicht sicher, ob es nicht die 7.12 ist...)


Eine panic oder ein crash gibt es nicht, vermute weil ich dich box vom strom trennen musste um zu wechseln....

PS: @ Upgrade auf 7.21:
Wenn die Fritz!Box hoch kommt zeigt er mir jedes mal an das es jetzt z.B. WPA3 gibt.
Er scheint also die Fritz!Box jedes mal wie neu gepatcht zu behandeln.

€dit:
Habe jetzt versucht mit der Orginal 7.21 Firmware zu updaten.
Über Freetz: Freetz startet die FritzBox nicht neu oO
Über Fritz!OS mit Datei: Nur die Power-Leuchte leuchtet und nichts passiert.
Über Fritz!OS mit Autoupdate: Power-Leuchte leuchtet und Info Leuchte blinkt und nichts passiert.

Was auch nicht geht ist ein reboot über die Freetz Oberfläche.
Auch nicht über das normale Fritz!OS, Power und Wlan Leucht leuchten und nichts passiert.

€dit2:
Automatische Rückmeldung von AVM 2* per Mail:
Das FRITZ!OS Ihrer FRITZ!Box 7590 (UI) [7590-Ort] wurde nicht aktualisiert.
Interner Fehler beim Installieren der neuen FRITZ!OS-Version.
 
Zuletzt bearbeitet:
Wenn Du die Box nicht über 22 Minuten mit 07.21 hast stehenlassen, KANN das ja nicht der Inhalt von "/dev/debug" aus diesem System sein, denn das Protokoll geht ja bis zum Zeitstempel 1320 (das sind 22 Minuten) und noch knapp darüber hinaus.

Ich verstehe aber die anderen Punkte nicht ... ja, der Patch (für die Service-Datei) sollte dafür sorgen, daß der "supervisor" den nicht mehr automatisch startet, wenn er den Zustand "multi-user.target" einnehmen will (was beim Start wohl der Fall ist). Daß es auch solche Service-Definitionen im FRITZ!OS gibt und der "supervisor" damit also auch umgehen können sollte, kann man sich anhand des "spindown.service" ansehen. Der wird auch nicht direkt beim Systemstart angeworfen über irgendwelche Abhängigkeiten, sondern explizit in der "/etc/hotplug/storage" über ein "svctl start" in Gang gesetzt. Genau das sollte dieser Vorschlag auch bewirken, wobei dafür ja tatsächlich nur minimale Änderungen notwendig waren - deshalb war das auch der erste Versuch.

Und ich kann mir unter:
kommt er nach wie vor gar nicht erst hoch.
jetzt alles Mögliche vorstellen - aber der Hinweis auf die kleinen blauen Pillen wird hier auch nur wenig helfen.

Man kann ja zumindest anhand der LEDs beobachten, ob die Box einfach nur stehen bleibt oder ob sie immer wieder versucht, das System zu starten (das gleichzeitige kurze Aufblitzen aller LEDs erfolgt am Beginn des Bootloader). Wenn die auch dann, wenn der Freetz-Mod noch gar nicht gestartet wird (und das würde er mit dem Patch ja nicht, solange die "tail" den dann nicht doch noch per "svctl" anwirft - das wäre also als Nächstes auszulassen zum Test), direkt wieder abstürzt, dann funktioniert sie (mit der vorliegenden FRITZ!OS-Konfiguration) vermutlich auch mit der originalen Firmware nicht oder es liegt gar nicht am Starten des Freetz-Mod, sondern schon an anderen Änderungen - auch wenn ich noch keine Idee habe, welche das sein könnten.

Ich werde aber auch aus den Beschreibungen, was da nun mit der originalen Firmware beim Versuch der Installation passiert und was nicht, absolut nicht schlau - ich denke nur verstanden zu haben, daß das Update mit der originalen Firmware nicht funktioniert. Da verstehe ich dann halt wieder nicht, wie das mit Freetz geklappt hat ... außer es war tatsächlich immer die Installation über EVA und nicht über das laufende FRITZ!OS 07.12, das ja auch schon mit Freetz behandelt wurde. Es spricht nichts dagegen, auch die originale Firmware über den Bootloader zu installieren (das erfolgt dann in die aktiven Partitionen, da muß man also aufpassen und ggf. vorher selbst umschalten - das wäre bei einem Freetz-Image aber genauso), sofern man diese zuvor in das passende Format bringt (Stichwort "image2ram" oder wie man das auch sonst machen will - es gab ja erst kürzlich irgendwo hier Diskussionen dazu).

Bei all dem Durcheinander würde ich tatsächlich erst mal vorschlagen, ein originales FRITZ!OS zu installieren (alte Sicherungsdateien gibt es ja hoffentlich auch noch, die Freetz-Einstellungen kann man vorsichtshalber auch sichern, obwohl sie erhalten bleiben müßten) und dann zu schauen, ob damit alles so funktioniert, wie es soll. Danach ist es dann ohnehin empfehlenswert, wenn man beim Wechsel des OS zuvor das WLAN deaktiviert - dann treten auch keine Konflikte mit WPA3 auf (bzw. sollten keine auftreten), wenn man wieder auf eine Version zurückschaltet, die WPA3 nicht kennt. Ich denke mal, das WLAN wird hier momentan noch am wenigsten verdächtigt, den Unterschied zwischen AVM-Firmware und Freetz auszumachen.

Bei dem Fehlerbild, was sich hier jetzt mind. einmal gezeigt hat (das waren die Abstürze durch den Watchdog des "untrustedd"), ist es witzlos, einen Fehler im Freetz(-NG) zu suchen, solange man nicht sicher weiß, daß es nicht an der Konfiguration der AVM-Komponenten liegt und das testet man eben am einfachsten mit einer originalen Firmware. Dann muß man zwar für Änderungen am System oder das Umschalten auf ein anderes jedesmal den Bootloader bemühen, aber da kommt man nicht umhin.
 

Neueste Beiträge

Statistik des Forums

Themen
244,640
Beiträge
2,215,722
Mitglieder
371,219
Neuestes Mitglied
csgaming
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.