FB 6591 verschiedenes

[fesc]

Hier die Ausgabe:

Seltsam. Die Daten sehen ok aus. Ich kann mich an den beschrieben fall erinnern, ein anderes mal wo ich das hatte wurde es durch einen Neustart (power cycle) behoben (wenn mich mein Gedächtnis nicht im stich lässt). D.h. weitere Schritte arten wohl in try and error aus, wenn du dir das antun willst (wird halt zunehmend riskant!):

• Mit einem original-image auf diese art und weise testen, um zu schauen ob es nicht doch was mit dem freetz image zu tun hat.
• Mit der efi shell probieren (siehe recovery sektion)
• mittels dd die teil-images direkt in die inaktiven mtd partitionen schreiben

 

[lazux]

sieht nicht so aus!
von https://bitbucket.org/fesc2000/ffritz/src/6591/README-6591.md

Oh... hast recht, habs irgendwie überlesen.

Mit einem original-image auf diese art und weise testen, um zu schauen ob es nicht doch was mit dem freetz image zu tun hat.
Mit der efi shell probieren (siehe recovery sektion)
mittels dd die teil-images direkt in die inaktiven mtd partitionen schreiben

Mit dem original Image (Version 7.21) funktioniert das Flashen problemlos. Die Ausgaben füge ich mal unten an. Eventuell stimmt tatsächlich etwas mit dem Erstellten Freetz-Image nicht, aber so richtig beurteilen kann ich es nicht. Ich frage mich jetzt wie oder womit es weitergehen kann:

• Macht es Sinn, das ganze mit der EFI Shell zu probieren oder die Partitionen mit dd manuell zu schreiben?
• Kann ich auf das ffritz Projekt ausweichen und damit Pakete wie OpenVPN/Wireguard, OpenSSH und Dnsmasq installieren?
• Oder, falls es am freetz Image liegen sollte, doch lieber einen Fehler in https://github.com/Freetz-NG/freetz-ng melden und auf Behebung des Fehlers warten? fda77 ist wohl der Entwickler, zumindest bertreut er das Projekt. Möglicherweise ist es der gleiche Benutzer wie hier @fda89 ?

/sbin/burnuimg /var/media/ftp/firmware-update.uimg || echo FAILED

burnuimg: <<< 220 pumaglued ready.
burnuimg: >>> uimg update
Debug: rpc_mgm_aid_get_1_svc
Start running the command to get the active image index
[DEBUG]: main:194:active image partition[0] = 1
[DEBUG]: main:194:active image partition[1] = 1
[DEBUG]: main:194:active image partition[2] = 1
[DEBUG]: main:194:active image partition[3] = 1
[DEBUG]: main:194:active image partition[4] = 1
[DEBUG]: main:194:active image partition[5] = 1
[DEBUG]: main:194:active image partition[6] = 1
[DEBUG]: main:194:active image partition[7] = 1
[DEBUG]: main:194:active image partition[8] = 0
[DEBUG]: main:194:active image partition[9] = 0
[DEBUG]: main:194:active image partition[10] = 1
[DEBUG]: main:194:active image partition[11] = 1
[DEBUG]: main:194:active image partition[12] = 1
[DEBUG]: main:194:active image partition[13] = 1
[DEBUG]: main:194:active image partition[14] = 1
[DEBUG]: main:194:active image partition[15] = 1
Debug: rpc_mgm_aid_get_1_svc
burnuimg: <<< 227 /usr/sbin/update starting.
update: Exit OK.
Split parts mask: 0x00001F00
APPCPU Kernel type: 2
APPCPU Kernel size: 9437184
APPCPU Kernel crc:  0xA8050479
APPCPU RootFS type: 3
APPCPU RootFS size: 28020736
APPCPU RootFS crc:  0x778066CA
NPCPU Kernel type: 8
NPCPU Kernel size: 2761984
NPCPU Kernel crc:  0x4393F696
NPCPU RootFS type: 9
NPCPU RootFS size: 15761408
NPCPU RootFS crc:  0xD432A1A1
GWFS type: 10
GWFS size: 870400
GWFS crc:  0x56D1A825
UIMG: exit 0
burnuimg: <<< 220 pumaglued ready.
burnuimg: >>> uimg status
burnuimg: <<< 225 update status follow.
STATUS exit 0

/bin/aicmd pumaglued uimg switchandreboot

Finish running the command to get the active image indexDebug: rpc_mgm_aid_get_1_svc
Start running the command to get the active image index
[DEBUG]: main:194:active image partition[0] = 1
[DEBUG]: main:194:active image partition[1] = 1
[DEBUG]: main:194:active image partition[2] = 1
[DEBUG]: main:194:active image partition[3] = 1
[DEBUG]: main:194:active image partition[4] = 1
[DEBUG]: main:194:active image partition[5] = 1
[DEBUG]: main:194:active image partition[6] = 1
[DEBUG]: main:194:active image partition[7] = 1
[DEBUG]: main:194:active image partition[8] = 0
[DEBUG]: main:194:active image partition[9] = 0
[DEBUG]: main:194:active image partition[10] = 1
[DEBUG]: main:194:active image partition[11] = 1
[DEBUG]: main:194:active image partition[12] = 1
[DEBUG]: main:194:active image partition[13] = 1
[DEBUG]: main:194:active image partition[14] = 1
[DEBUG]: main:194:active image partition[15] = 1
Debug: rpc_mgm_aid_get_1_svc
Finish running the command to get the active image indexDebug: rpc_mgm_aid_get_1_svc
Start running the command to get the active image index
[DEBUG]: main:194:active image partition[0] = 1
[DEBUG]: main:194:active image partition[1] = 1
[DEBUG]: main:194:active image partition[2] = 1
[DEBUG]: main:194:active image partition[3] = 1
[DEBUG]: main:194:active image partition[4] = 1
[DEBUG]: main:194:active image partition[5] = 1
[DEBUG]: main:194:active image partition[6] = 1
[DEBUG]: main:194:active image partition[7] = 1
[DEBUG]: main:194:active image partition[8] = 0
[DEBUG]: main:194:active image partition[9] = 0
[DEBUG]: main:194:active image partition[10] = 1
[DEBUG]: main:194:active image partition[11] = 1
[DEBUG]: main:194:active image partition[12] = 1
[DEBUG]: main:194:active image partition[13] = 1
[DEBUG]: main:194:active image partition[14] = 1
[DEBUG]: main:194:active image partition[15] = 1
Debug: rpc_mgm_aid_get_1_svc
[INFO]:setActiveImage:666 Set active image AID[1] successful
[DEBUG]: main:224:Set active image successfully
Finish running the command to get the active image indexDebug: rpc_mgm_aid_set_1_svc
Running: aid_config_utility --set 0 0 0 0 0 0 1 1 0 0 1 1 1 1 1 1 Debug: rpc_mgm_aid_set_1_svc
Finish running the command
Debug: rpc_mgm_aid_set_1_svc

 

[fda89]

Ja, bin ich, warte aber noch auf eine Accountumbenennung durch @Beta-Eule ;-).
Ich hab keine Docsis fb. Es könnte ein Problem mit der Checksumme sein (https://www.ip-phone-forum.de/threads/307950/)
Lösch mal aus der ./fwmod ab Zeile 2008 den for-block nach "# Write checksum"

 

[fesc]

Macht es Sinn, das ganze mit der EFI Shell zu probieren oder die Partitionen mit dd manuell zu schreiben?

Eigentlich nicht .. irgendwas ist mit dem image faul. Du kannst es mir gern mal per PN zukommen lassen, vielleicht habe ich am WE mal Zeit und Nerf. Wenn es am uimg tool liegt bin eh ich schuld.

Kann ich auf das ffritz Projekt ausweichen und damit Pakete wie OpenVPN/Wireguard, OpenSSH und Dnsmasq installieren

Du kannst dir das README-APP durchlesen was so alles geht/ging .. ist halt alles etwas mehr, wie soll ich sagen, Handarbeit. Wireguard: Aktuell nicht, warte auf AVM sourcen, OpenVPN: jein (habe es nicht mehr verwendet in letzter zeit), openssh: warum wenn dropbear schon drin ist?, Dnsmasq: pihole ist drinnen und laeuft.

 

[fda89]

AVM sourcen gibts doch. Oder fehlt darin was?

 

[fesc]

AVM sourcen gibts doch

Für 6591 / 7.21?

 

[fda89]

Ja, wie immer auf http://osp.avm.de/
Die 6660 sourcen mit gleichm kernel sogar schon bisschen länger

 

[fesc]

Ja

Oh, danke, ganz übersehen.

 

[fda89]

Aktuell gibt es sogar für jedes aktuelle AVM Gerät sourcen, bzw für ein ähnliches. Für 7490 müssen noch die von der Labor genutzt werden
Falls du dich auf boxmatrix.info verlassen hast: dort fehlt so einiges!
@lazux Statt #323 kannst du auch die neueste Revision nehmen

 

[lazux]

@lazux Statt #323 kannst du auch die neueste Revision nehmen

Okay, hab alles gelöscht und freetz komplett neu gebaut. Das Erstellen und die Installation liefen ohne Fehler durch. Aber die FB befindet sich momentan in einem reboot loop. In putty hatte ich die Log-Option aktiviert. Falls ihr Bedarf seht und etwas Zeit dafür habt, kann ich euch gerne das Logfile zukommen lassen. Was mir als Laien aber auf den ersten Blick auffällt ist eine Fehlermeldung zum Kernelmodule zram:

modprobe: module zram not found in modules.dep
[ERROR] Failed to load kernel module zram

Dann noch diverse Fehler, die ich als Verbindungsproblem deuten würde, was darauf zurückgeführt werden kann, dass die FB nicht am Kabelanschluss hängt. Ob das für Freetz ein Problem ist?

Eigentlich nicht .. irgendwas ist mit dem image faul. Du kannst es mir gern mal per PN zukommen lassen, vielleicht habe ich am WE mal Zeit und Nerf. Wenn es am uimg tool liegt bin eh ich schuld.
Du kannst dir das README-APP durchlesen was so alles geht/ging .. ist halt alles etwas mehr, wie soll ich sagen, Handarbeit. Wireguard: Aktuell nicht, warte auf AVM sourcen, OpenVPN: jein (habe es nicht mehr verwendet in letzter zeit), openssh: warum wenn dropbear schon drin ist?, Dnsmasq: pihole ist drinnen und laeuft.

Hab beide Images (alt+neu) hochgeladen und lasse dir die Links zukommen. Wäre cool, wenn du dir das mal anschauen würdest.

Also das was man mit ffritz machen kann würde meine Erwartungen erfüllen. Wireguard muss nicht sein, OpenVPN finde ich völlig okay. Mit Dropbear hast du natürlich recht, OpenSSH wird dann nicht benötigt. Momentan möchte ich den Progress mit Freetz-NG noch nicht aufgeben. Mal schauen wie weit wir damit kommen.

 

[fda89]

Also konnte das Image nach der Änderung von gestern geflasht werden?
Ein kompletter Log vom Loop wäre nicht schlecht, damit könnte man vielleicht die Ursache finden und beheben. Vielleicht ist es der avm-watchdog: https://freetz-ng.github.io/freetz-ng/patches/#patch-disable-avm-watchdog
An zram wird es nicht liegen, das ist nur ein "RAM-Komprimierer". Das module haben auch nur die 6430 6490 6590. AVM hat das im Script wohl einfach nicht berücksichtigt.
Und normalerweise siehst du die Fehlermeldungen nicht

 

[lazux]

@fda89 Ja, bauen und flashen liefen problemlos durch. Schade, dass es jetzt im Loop festhängt.
Das Logfile habe ich hier hochgeladen. Das ist die Ausgabe zu einer Boot-Schleife, die Ausgabe wiederholt sich immer.

 

[fda89]

Prima. Es wird wohl so sein dass bei Boxen mit neuerem BIOS die Checksumme egal war, da die einzelnen Partitionen geflasht werden

[*][  136.272227] [  133.349840][0]Call Trace:
[*][  136.276613] [  133.352776][0] <IRQ>
[*][  136.280605] [  133.354946][0] [<813ab52d>] dump_stack+0x49/0x6c
[*][  136.287227] [  133.360131][0] [<814a5150>] ? AVM_WATCHDOG_set_timeout+0x90/0x90
[*][  136.295404] [  133.366860][0] [<810ea3d7>] panic+0x91/0x1b2
[*][  136.301636] [  133.371643][0] [<814a5150>] ? AVM_WATCHDOG_set_timeout+0x90/0x90
[*][  136.309813] [  133.378359][0] [<814a5150>] ? AVM_WATCHDOG_set_timeout+0x90/0x90
[*][  136.317990] [  133.385087][0] [<8162e163>] AVM_WATCHDOG_timer_init_ctrl_handler.cold.2+0xc/0xc
[*][  136.327624] [  133.393272][0] [<810a4089>] call_timer_fn.isra.29+0x29/0xc0
[*][  136.335314] [  133.399513][0] [<81086074>] ? rebalance_domains+0xe4/0x2a0
[*][  136.342906] [  133.405657][0] [<810a42d8>] run_timer_softirq+0x1b8/0x3b0
[*][  136.350402] [  133.411706][0] [<814a5150>] ? AVM_WATCHDOG_set_timeout+0x90/0x90
[*][  136.358579] [  133.418431][0] [<81086348>] ? run_rebalance_domains+0x118/0x1a0
[*][  136.366658] [  133.425061][0] [<81055ef8>] __do_softirq+0xf8/0x370
[*][  136.373572] [  133.430526][0] [<81055e00>] ? takeover_tasklets+0x110/0x110
[*][  136.381261] [  133.436768][0] [<8101a78d>] do_softirq_own_stack+0x1d/0x30
[*][  136.388853] [  133.442903][0] <EOI>
[*][  136.392852] [  133.445060][0] [<810562e5>] irq_exit+0xb5/0xc0
[*][  136.399280] [  133.450047][0] [<81036ecb>] smp_apic_timer_interrupt+0x4b/0x90
[*][  136.407263] [  133.456579][0] [<817b553d>] apic_timer_interrupt+0x2d/0x34
[*][  136.414855] [  133.462724][0] [<817b007b>] ? ip6_tnl_destroy_tunnels+0xbb/0xc0
[*][  136.422933] [  133.469354][0] [<815f642d>] ? cpuidle_enter_state+0x14d/0x250
[*][  136.430816] [  133.475790][0] [<815f654f>] cpuidle_enter+0xf/0x20
[*][  136.437632] [  133.481157][0] [<8108bddc>] call_cpuidle+0x1c/0x30
[*][  136.444449] [  133.486525][0] [<8108bfdf>] cpu_startup_entry+0x10f/0x1a0
[*][  136.451944] [  133.492571][0] [<817acf3e>] rest_init+0x6c/0x6f
[*][  136.458470] [  133.497647][0] [<81aa1a85>] start_kernel+0x35f/0x364
[*][  136.465480] [  133.503206][0] [<81aa1258>] i386_start_kernel+0x43/0x45
[*][  136.472782] [  133.512305][0]set_reboot_status: Soft-Reboot(PANIC)  - PANIC(3)SUM(3)UP(132)UTC(132)FW()HW(233)HWS(7)BV()
[*]  136.484940] [  133.523168] Kernel Offset: disabled

Versuch mal ob Aktivieren des oben verlinkten Patches hilft, scheint durch den watchdog zu rebooten

Falls du dann darauf zugreifen kannst, müsste die Ursache der ganzen "Segmentation fault" gefunden werden

...
[*][FREETZ] RCMOD: Segmentation fault
[*][FREETZ] RCMOD: Writing 2509 bytes to /var/flash/freetz ... done.
[*][FREETZ] RCMOD: Segmentation fault
[*][FREETZ] RCMOD: openvpn is disabled.
[*][FREETZ] RCMOD: Creating group 'openvpn' ... saving ... done.
[*][FREETZ] RCMOD: Segmentation fault
[*][FREETZ] RCMOD: Creating user 'openvpn' ... saving ... done.
[*][FREETZ] RCMOD: Segmentation fault
[*][FREETZ] RCMOD: creating static.key ...
[*][FREETZ] RCMOD: Segmentation fault
[*][FREETZ] RCMOD: Startup finished.

Vielleicht werden die nur durch log() in /etc/init.d/rc.mod mit "logger -t FREETZMOD text" verursacht. Bei den Docsis ist einiges an loggin durch avm deaktiviert

 

[lazux]

@fda89 Aktivieren des Patches? Meinst du damit die Aktivierung des Punktes "Disable AVM watchdog" unter "Other patches"? Falls ja, hat das den boot loop nicht behoben. Die FB startet nach erneutem flashen weiterhin immer wieder neu. Das Log dazu befindet sich hier.

 

[fda89]

Jetzt kommt immerhin nichts mehr vom watchdog. Allerdings gibt es auch keine RCMOD/"Segmentation fault" Meldungen mehr, hast du die herausgepatcht? Oder ist da gar kein Freetz mehr drauf?


Witzig:

[    0.109454] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
[    0.118993] Spectre V2 : Spectre mitigation: kernel not compiled with retpoline; no mitigation available!
[    0.129503] Speculative Store Bypass: Vulnerable
[    0.134674] L1TF: Kernel not compiled for PAE. No mitigation for L1TF
[    0.141914] MDS: Vulnerable: Clear CPU buffers attempted, no microcode

Meldet dieser swap.service eigentlich auch mit unmodifizierte AVM Firmware diesen Fehler? Kannst du die Ausgaben mit deiner Console sehen?
Man könnte swap.service unter build/original löschen, dann wird er beim nächsten make nicht mit ins image genommen/gestartet. Löschen von build/ setzt alles zurück.

[Supervisor] Info: start apparmor.service
[Supervisor] Info: start filesystem.service
[Supervisor] Info: start swap.service
[3[   67.344426] audit: type=1400 audit(66.052:3): apparmor="STATUS" operation="profile_load" name="/sbin/nqcs" pid=2503 comm="dd"
1m[ERROR][0m mi[   67.358090] audit: type=1400 audit(66.052:3): apparmor="STATUS" operation="profile_load" name="/sbin/nqcs//msgsend" pid=2503 comm="dd"
ssing zram devic[   67.373146] audit: type=1300 audit(66.052:3): arch=40000003 syscall=4 per=400000 success=yes exit=16649 a0=1 a1=721ee008 a2=4109 a3=1 items=0 ppid=2488 pid=2503 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="dd" exe="/bin/busybox" key=(null)
e
[Supervisor] [   67.404128] audit: type=1327 audit(66.052:3): proctitle=6464006966002F6C69622F61707061726D6F722E642F7362696E2E6E7163732E62696E006F66002F7379732F6B65726E656C2F73656375726974792F61707061726D6F722F2E6C6F616400627300314D
Info: swap.service exit error
0+1 records in
0+1 records out
[Supervisor] Info: apparmor.service exit success

Die Kernelpanic, hab aber keine Idee weshalb

[   70.187814] ------------------- Last part of Panic-log Content: -------------------
[   70.187814] 
[   70.187818]  0 kernel info: 0 [pcmlink_ctrl/1]
[   70.187823] [   69.084403][1][4294735090][pcmlink]error: trigger too late 9282 us
[   70.187828] [   69.084444] trigger too late:: (irq-cnt=370 spurious=0 dma-reinit=0) cpu: 0 % (peak: 0 %)
[   70.187832] [   69.084446][1]avm_DebugSignal: 0 kernel info: 0 [pcmlink_ctrl/1]
[   70.187837] [   69.093693][1][4294735099][pcmlink]error: trigger too late 9293 us
...
[   70.189026] [   69.912138] trigger too late:: (irq-cnt=460 spurious=0 dma-reinit=0) cpu: 0 % (peak: 0 %)
[   70.189030] [   69.912139][1]avm_DebugSignal: 0 kernel info: 0 [pcmlink_ctrl/1]
[   70.189035] [   69.921385][1][4294735927][pcmlink]error: trigger too late 9287 us
[   70.189039] [   69.921418] trigger too late:: (irq-cnt=461 spurious=0 dma-reinit=0) cpu: 0 % (peak: 0 %)
[   70.189044] [   69.921420][1]avm_DebugSignal: 0 kernel info: 0 [pcmlink_ctrl/1]
[   70.189048] [   69.921426] PANIC:: (irq-cnt=461 spurious=0 dma-reinit=0) cpu: 0 % (peak: 0 %)
[   70.189053] [   70.021534][1][4294736027][pcmlink]error: trigger too late 100194 us

[   70.189057] [   70.021720] TDM: FS: 790 Hz CLK: 80365 Hz (loop=20745 wishy-washy because slow gpio-interface)
[   70.189062] [   70.031462][1][4294736037][pcmlink]error: trigger too late 9923 us
[   70.189067] [   70.108775] [avm_power]pm_ressourceinfo_scriptparse: powerdevice_analog: norm_power_rate=200 act_rate=0 mul=141 div=10 offset=100 NormP=2920 mW -> SumNormP=2920 mW
[   70.189072] [   70.125211] [avm_power]pm_ressourceinfo_scriptparse: powerdevice_usb_host: norm_power_rate=500 act_rate=0 mul=55 div=10 offset=0 NormP=2750 mW -> SumNormP=5670 mW
[   70.189077] [   70.142091] [pcmlink](-2) closed-state received
[   70.189081] [   70.142109] Kernel panic - not syncing: 
[   70.189085] [   70.142109] To much trigger-violation - failed pcm-framesync ???
[   70.189089] [   70.142109] 
[   70.189094] [   70.142117] CPU: 1 PID: 2098 Comm: pcmlink_ctrl/1 Tainted: P           O    4.9.199 #1
[   70.189098] [   70.142119] Hardware name: Intel Corporation PUMA 7 C0 PLATFORM/TBD, BIOS CGM2.86C.597968.R.1809251311 09/25/2018
[   70.189103] [   70.142134]  af205f0c 813ab52d 00000000 001e8098 af205f24 810ea3d7 001e8098 00000000
[   70.189107] [   70.142143]  001e8098 aee1d300 af205f68 c3c78449 c3c7cbcc aee1d318 aee1d30c 00000246
[   70.189112] [   70.142151]  aee1d3c8 e51d8a6c c3c7f000 00000000 b480d000 8108b960 af205f54 af205f54
[   70.189116] [   70.142153] Call Trace:
[   70.189120] [   70.142168]  [<813ab52d>] dump_stack+0x49/0x6c
[   70.189124] [   70.142176]  [<810ea3d7>] panic+0x91/0x1b2
[   70.189129] [   70.142200]  [<c3c78449>] l_controltimer_thread.cold.8+0x1d/0x24 [pcmlink]
[   70.189133] [   70.142208]  [<8108b960>] ? wake_atomic_t_function+0x70/0x70
[   70.189137] [   70.142213]  [<8106b2df>] kthread+0xaf/0xd0
[   70.189141] [   70.142229]  [<c3c5a000>] ? pcmlink_ll_status_pcmbus+0x90/0x90 [pcmlink]
[   70.189146] [   70.142234]  [<8106b230>] ? kthread_park+0x50/0x50
[   70.189150] [   70.142240]  [<817b4b77>] ret_from_fork+0x1b/0x28
[   70.189155] [   70.144835] set_reboot_status: Soft-Reboot(PANIC)  - PANIC(1)SUM(1)UP(68)UTC(68)FW()HW(233)HWS(7)BV()
[   70.189159] [   70.144920] Kernel Offset: disabled
[   73.164079] ACPI MEMORY or I/O RESET_REG.
[CODE]

 

[lazux]

@fda89 Was ich gemacht habe ist folgendes: make distclean , make menuconfig. Hier unter "Other patches" den Punkt "Disable AVM watchdog" aktiviert, danach make olddefconfig und make ausgeführt. Anschliessend die erzeugte Firmware aufs FritzNAS geladen und mit /sbin/burnuimg /var/media/ftp/firmware-update.uimg || echo FAILED geschrieben, danach mit /bin/aicmd pumaglued uimg switchandreboot umgeschaltet und das System erneut geladen. Mehr habe ich nicht gemacht, auch nichts in der FB konfiguriert.

Da mir keine Logfiles von einem original FritzOS vorliegen, habe ich mal ein Recovery mit der original Firmware FritzOS 7.21 durchgeführt und die Logfile mit dem frisch hochfahrenden System hier abgelegt. Der gleiche Fehler bezüglich swap.service erscheint dort auch. Deutet das auf einen Defekt in der FB hin?

Leider kenne ich mich zu wenig mit der Hardware und dem gesamten Konzept aus, als das ich auf eigene Faust irgendwie weiterkommen könnte. Welche Chancen sieht du kurz- oder mittelfristig zu einem lauffähigen Freetz auf der 6591 zu kommen?

 

[fda89]

Ne, kein Defekt. der swap.service hätte nicht in die Firmware gesollt. Stört aber nicht, nur die Fehlermeldung ist unschön. Diese sieht man normalerweise aber nicht. Gut zu wissen dass das ohne Modifikation auch so ist, dann braucht man nicht in Freetz nach dem Fehler zu suchen
Wie schnell das behoben wird hängt von den Leuten mit so einem Gerät (dir) ab. Ich hab keine Docis + Geräte. Schau doch mal im Kenrelquellcode unter source/ was es mit diesen "trigger too late:" Meldungen auf sich hat

 

[lazux]

Vor dem was ihr mit euren Projekten (und der technischen Unterstützung dafür) leistet, habe ich echt Respekt, aber mir fehlt das Fachwissen und das Interesse intensiver darin mitzuwirken. Was Fritz-Produkte betrifft bleibe ich lieber auf der Konsumentenseite. Ich behalte freetz-ng im Auge und werde demnächst mal einen Versuch mit ffritz wagen. Für diese tolle Community und eure Unterstützung danke ich euch sehr @fda89 , @fesc , @prisrak1

 

[fda89]

Das ist ein Henne-Ei-Problem. Ohne Hardware ist schlecht zu testen

 

[dega]

Moin zusammen,

ich bin schon seit einiger Zeit stiller Mitleser und möchte hiermit ein fettes Dankeschön an alle schicken, die hier soviel Arbeit und Wissen reingesteckt haben. Echt top!
Ich bin, wie einige hier, auch auf einen Verkäufer einer gebrandeten Box hereingefallen, habe aber durch die Seite von fesc die Box auf die 7.21 geupdated bekommen. Ich habe aber zwei Herausforderung, bei denen ich Hilfe brauche.

• Ich habe die README-APP.md nicht verstanden. Wie bekomme ich die Erweiterungen auf die Box? Speziell PiHole... Ich habe verstanden, dass sie nach /nvram/ffnvram/ müssen, da nur diese nichtflüchtig ist. Ich habe ffservice und pihole auch im git clone gefunden. Muss ich einfach die Binaries per Memoriestick auch die Box bringen und dann Einträge in /nvram/ffnvram/etc/rc.d erzeugen?
• Ich habe PiHole aktuell auf nem Raspberry lauf und dort habe ich einen Domain-Redirect über die hosts eingerichtet. Funktioniert dies auch über die FritzBox? Habe per SSH die hosts verändert und der ping auf der Box geht auch auf lokale IP, aber der DNS-Server auf der Fritzbox scheint das zu ignorieren. Wenn PiHole auf der Fritzbox laufen würde, würde PiHole die hosts Einträge verwenden? Ist die hosts auch persistent oder würde die auch nach jedem Reboot zurückgesetzt? Wenn nicht persistent, bekomme ich die auch nach /nvram/ffnvram/ und per symlink eingebunden.

Danke schonmal im voraus.