[larsen64it]

Domanda stupida ma partendo da bank_2 con bank_1 attiva. Installando la dev su firmware non moddato, non dovrebbe fare almeno un reboot.
Visto che con il log non completa la copia se invece di inviarlo su /dev/kmsg  lo mando su file? Tipo /tmp/migrate_log.

[FrancYescO]

No, in quella casistica allo stato attuale delle cose prepara tutto ma non forza alcun reboot, al primo reboot che avverrà farà il mount di modoverlay e la migrazione

il log puoi metterlo un po dove ti pare purchè sia scrivibile, era stato scelto kmsg perchè era l'unico visibile sia da seriale che ad avvio completo da logread

[LuKePicci]

Si quello che dovete fare ora è sostanzialmente capire se durante la migrazione /dev/watchdog esiste, se è bloccato ma in uso e quindi come killare chi lo sta usando per poterne assumere il controllo. Sono convinto che a quel punto watchdog-tch non sia ancora stato avviato, quindi se è in uso c'è l'ha occupato qualcos'altro. Queste prove però vanno fatte su quel device, perché altrimenti già sappiamo che a tenerlo correttamente occupato è procd.

[brusarp]

@brusarp dai upgradegui da terminale

Ok fatto... Ora è tutto ok, grazie @FrancYescO

[larsen64it]

Questo è quello che copia nei 3 log commentati
https://anonfiles.com/R3q1I1H2o1/migrate_log

[lorenzocanalelc]

(@lorenzocanalelc se hai voglia di riprovare, direi che e' il tassello che mancava per considerare almeno gli upgrade da stable fattibili senza problemi)

Giusto la prossima settimana dovrei andare a recuperare un DGA4132 che era fermo all'ultima stabile con un paio di impostazioni personalizzate (Tra cui anche questo l'IP su 192.168.10.1), vediamo come si comporta con l'aggiornamento

[larsen64it]

Questo è l'elenco dei file che ad ogni riavvio ricopia impedendo qualsiasi personalizzazione:
https://termbin.com/10s1

[FrancYescO]

mhhhh se li ricopia significa che non li elimina (o che qualcuno le ricrea prima che do_migrate_overlay venga eseguito), che per alcuni è giusto, ma quelle config non capisco perchè ci sono

[larsen64it]

In effetti dopo il boot /overlay/bank_2/etc/config/ non esiste, quindi vengono cancellati, ma non prima di averli ricopiati.

[FrancYescO]

Quel (quei?) firmware fa decisamente tanta roba extra in preinit, tipo: https://github.com/FrancYescO/tch_firmware_extracted/blob/16.2.8706_FW_214_IAD_TG789vacXtream/lib/preinit/90_restore_config

c'è anche questo script "curioso": https://github.com/FrancYescO/tch_firmware_extracted/blob/16.2.8706_FW_214_IAD_TG789vacXtream/lib/preinit/41_merge_overlay_hooks

mi sa che le config vengono ricreate prima dell'init e quindi ci si ritrova sempre a spostarle, l'alternativa potrebbe essere sempre mettere la nostra flag di copia completa, ma il fatto che comunque lui riesca a scrivere sull'overlay reale non e' proprio bello...

[larsen64it]

Quei!!! Io ho ill mos 214 ed ho controllato anche il mos 108 ed tutti hanno quella cartella ben farcita.

Edit Questo potrebbe spiegare molte cose
1) Lentezza nella copia perché indaffarato a fare le sue copie watchdog o meno (forse basta /etc/init.d/watchdog-tch stop)
2) in caso di prima installazione stravolgimento delle configurazioni che non sono quelle di partenza.
3) Continui riavvii malgrado lo sleep finale

[LuKePicci]

A questo punto la flag è l'unica cosa sensata.

@larsen64it forse volevi dire /etc/init.d/watchdog-tch start, ma c'è comunque da capire se lo start di un altro init script da un init script è possibiie

[larsen64it]

@LuKePicci Volevo dire proprio quello che ho scritto, memore di quanto aveva suggerito @FrancYescO qualche post indietro. Praticamente di fare quello che fa la gui in sede di installazione che disabilita watchdog.
Ad installazione della gui completata compare una nuova riga

Codice: [Seleziona]

watchdog- 7799        root    9r      CHR        1,9      0t0         87 /dev/urandome in considerazione del fatto che watchdog dovrebbe essere attivo sin dall'inizio

Codice: [Seleziona]

Gateway initialization sequence started
Boot Loader Version : 15.50.1005-0000000-20151209073757-4fd17452ef9fdf09e9f981340e5d6b3f85fe6c5a
Boot Loader OID     : unofficialbuildOID0000
CPU                 : BCM63138B0
RAM                 : 256MB
Flash               : 125MB NAND
Board Mnemonic      : VBNT-F
Market ID           : FFFC
Booting             : Bank 2 (bank 1 failed 3 times)               
SW Version          : 16.2.8706-3401002-20190430095635-7b7c7647291129d98ea436c767d61bebd6ea5151
Starting the Linux kernel

Enabling watchdog Riassumendo cercherò di schematizzare le varie opzioni.
Prove effettuate partendo da bank_2  (con l'opzione need_reboot="0" altrimenti si innesca il problema successivo e non si capisce nulla) e riavviando:
1) Senza modificare il watchdog non completa la copia.
2) Con /etc/init.d/watchdog-tch start completa la copia ma effettua un proprio riavvio.
3) Con /etc/init.d/watchdog-tch stop completa la copia senza nessun riavvio. Completato il riavvio lo stato di watchdog sembra normale.
Io mi focalizzerei sul vero problema, vale a dire su come impedire che il router si ricrei una propria configurazione ad ogni riavvio e che do_migrate_overlay la vada ogni volta a ricopiare... di conseguenza con l'opzione  need_reboot="1" attivata, il router si riavvia fino al BOOT-P

[FrancYescO]

Impedire che crea la configurazione lo vedo un po' complicato, impedire che la copi e di conseguenza riavii è abbastanza semplice (basta semplicemente non fare dipendere la copia dall'esistenza di /bank_2/etc/config, ma magari dalla non presenza di un file che piazzeremo in modoverlay poco prima di fare il reboot)

Mi sembra di capire che oltre questa cosa (che ovviamente farà restare in /overlay/bank2 una config inutilizzata e a cui si spera nessuno abbia un puntamento aperto dal preinit) ci sia anche da STOPPARE whatchdog-tch

[larsen64it]

1) /etc/config non si potrebbe provare a lasciarla piena di modo che il preinit non la ricrei?
2) Non escludo che il mio router stia diventando instabile ma con /etc/init.d/watchdog-tch start sembra riavviarsi per problemi suoi (trace) completa la copia prosegue l'init e si riavvia all'improvviso.