[LuKePicci]

@larsen64it appena hai voglia, riprova l'ultima la prossima dev .87 sull'xtream di fastweb, controlla se adesso il modoverlay funziona correttamente

[larsen64it]

@LuKePicci @FrancYescO
789 xtream
Upgradegui da .84 a .88 = BOOTP
https://anonfiles.com/Zfe8Q3F8oa/upgrade

[FrancYescO]

quello che doveva fare pare lo ha fatto, ma ho paura che qui il watchdog cotinui il conto anche dopo aver superato il preinit

non che sia una soluzione, ma forse se insisti nel farlo avviare forse a furia di crashare copia tutti i file e poi si avvia

soluzioni non mi vengono se non quella di far partire lo spostamento in uno stadio molto piu avanzato..

[larsen64it]

Anche la non-soluzione non funziona.
Gli ho fatto fare altri 3 giri completi, totale 9 tentativi. Si ferma sempre allo stesso punto.

[LuKePicci]

Prova ad abilitargli la stampa di questi messaggi commentati prima del reboot, rifai un paio di tentativi e rimanda il log.
https://github.com/Ansuel/tch-nginx-gui/blob/c4413ee22486309e19eb92b4edc4ad53c90f8739/decompressed/base/etc/init.d/do_migrate_overlay#L19

[larsen64it]

Partenza bank1 dev. 59 upgrade .88 fino a bootp
https://anonfiles.com/J5b1T9Feo5/upgrade
Riprova
https://anonfiles.com/D8baTbF7o5/upgrade2

P.S.
Fate presto comincia a dare segni di incandescenza con attacchi di panico
E.R.
Lo stiamo perdendo

[LuKePicci]

Di sicuro a furia di tentativi non si risolve perchè ogni volta riparte a copiare tutto da capo. Lo vedo perdere un casino di tempo qui:

Codice: [Seleziona]

[   10.354000] mount_root-mod: copying /overlay/bank_2/* to /tmp/migrate_overlay/ ...
[   26.202000] mount_root-mod: creating /tmp/migrate_overlay/bino qui:

Codice: [Seleziona]

[   10.632000] mount_root-mod: copying /overlay/bank_2/* to /tmp/migrate_overlay/ ...
[   48.214000] mount_root-mod: creating /tmp/migrate_overlay/bine chiaramente a seconda di quanto tempo perde poi va in timeout in punti diversi

Non ho idea di quando l'init di busybox vada a 'tickare' il watchdog e non so se sui vecchi firmware senza procd si possa prenderne il controllo in modo simile a quanto fatto qui per procd: https://openwrt.org/docs/guide-user/hardware/watchdog#controlling_the_watchdog

Del resto provare è semplice, basta aggiungere questa riga nei cicli di copia e vedere cosa succede:

Codice: [Seleziona]

echo 1 > /dev/watchdogSui vecchi firmware senza procd non dovrebbe dare alcun errore.

update: Sono abbastanza sicuro che il problema sia questo, cioè che sulle versioni senza procd, ovvero dove non c'è procd a tenere a bada il watchdog), non c'è nessuno che se ne occupi durante il trasferimento. Ci metterei un check per vedere se /dev/watchdog è scrivibile, se lo è vuol dire che va tenuto su durante i cicli di copia. Non ha senso spostare la copia ad un momento successivo all'avvio del servizio watchdog, nè stare a cambiare la priorita di avvio dello stesso. Se non lo è ancora, il driver del watchdog va caricato. Il preinit non è gestito da procd, quindi effettuando il trasferimento in quella fase lo stesso problema si ha su qualsiasi versione firmware. Le uniche differenze tra hardware (o meglio, tra versioni bootloader) possono essere nel valore di timeout impostato nel watchdog.

[grzmrc]

Posso resettare la password della GUI tramite ssh?
grazie

EDIT: l'ho ritrovata. sarebbe però interessante sapere se c'era un modo per resettarla tramite ssh.

[LaboDJ]

Ieri sera mi è successo esattamente la stessa cosa esposta nei precedenti post.
Firmware 2.2.2_001 con GUI dev .84
Upgrade tramite interfaccia a GUI dev .88, tutto ok.
Dopo un paio d'ore riavvio e va in bootloop + bootp, lo ha fatto per un'oretta di sicuro, ho provato anche a spegnerlo e lasciarlo calmo qualche minuto, niente.
Spengo tutto, vado a letto, lo riprendo dopo 12 ore, pronto con tftpd a riflasharlo, lo collego aspettando che vada in bootp, ma... parte. 
Magia? ma adesso ho paura a riavviarlo, meno male ho un mini ups 12v 

[bandit400]

Nome prodotto: DGA ( DGA4132 )
Versione software: AGTHP_2.2.0
Versione GUI: 9.5.88-c4413ee2

Domanda, forse è una banalità. Improvvisamente viene meno l'Asus RT-AC86U che ho in cascata con il mio DGA4132 (sopra, i dettagli della sua configurazione attuale).
Rimuovo l'Asus non più funzionante e mi appoggio direttamente al DGA4132, in attesa di acquistare un altro router. Fatto questo, su tutti i client connessi (tre laptop ed un PC fisso), in "Rete" non sono più visibili gli host presenti in rete (incluso un NAS autocostruito con su Fedora 31). Cosa devo "toccare" sul DGA4132 in modo che tornino visibili nell'elenco gli host presenti in rete?

Grazie in anticipo...

[FrancYescO]

@grzmrc direi prendendo questo blocco https://github.com/Ansuel/tch-nginx-gui/blob/master/decompressed/gui_file/tmp/web_unlock#L37-L42 e sostituendolo in /etc/config/web

@LaboDJ  il 2.2.2_001 non era (e direi che non lo è ancora del tutto) compatibilie con la GUI, con le >=9.5.85 ho sistemato il bug più grosso che aveva, ma chi ha installato le versioni precedenti e quel firmware potrebbe continuare a far cose strane soprattutto dopo riavvio

@bandit400 gli host hanno ip statici? credo dipenda troppo dal DHCP quella pagina piuttosto che dell'arp...

@larsen64it fammi sapere se riesci a completare la prova suggerita da Luke che la integriamo come soluzione e buona, magari poi possiamo anche tornare a mettere tutto in preinit se il motivo era quello..

[LuKePicci]

 Occhio che quella cosa da errore (ignorabile) in accesso al device del watchdog se fatto in init su procd (>=16.3)

[bandit400]

@bandit400 gli host hanno ip statici? credo dipenda troppo dal DHCP quella pagina piuttosto che dell'arp...

@FrancYescO: No, solo il NAS ha un IP statico, gli altri due laptop e l'altro PC hanno tutti indirizzi assegnati dal DHCP.
Credo, però, di essermi spiegato male: la lista degli host in rete locale che citavo è quella disponibile in Esplora risorse di Windows 10 che, da quando ho tolto di mezzo il router, sui tre Windows 10 appare così...

[FrancYescO]

Ah quello potrebbe essere anche qualche problema di Windows tipo che non hai messo la rete come privata ma come pubblica e quindi non fa quel discovery

Potrebbe essere causato anche dal fatto di aver cambiato i DNS dalla pagina rete locale del modem, sinceramente non so su cosa si basa quel discovery oltre che sul workgroup

[larsen64it]

Ditemi il punto giusto dove mettere
echo 1 > /dev/watchdog.
dopo       
mkdir $ram_dir
e prima
tranfer_file $overlay_bank $ram_dir