[MisterFTTH]

non so su cosa si basa quel discovery oltre che sul workgroup

Non è una caratteristica del deprecato SMBv1?

[bandit400]

@MisterFTTH , @FrancYescO: No, le reti sono tutte in "Privata", SMBv1 non è in uso.
Il NAS basato su Fedora 31 + Samba 4.11.11 presente nella rete, per renderlo visibile (proprio per motivi legati a SMBv1) l'ho dovuto dotare di un demone "wsdd".
Comunque, ripeto: prima, tutto funzionava perfettamente. Dopo aver rimosso l'Asus, ho appoggiato tutta la rete locale sul DGA4132 e questo è il risultato. Senza null'altro toccare. Ragionevolmente, mi sembra un problema circoscritto al modem/router.

[MisterFTTH]

Interessante wsdd, negli anni mi ero abituato a mappare direttamente le unità di rete senza pensare a soluzioni integrative ma potrei tornare sui miei passi...per il resto non lo avevo messo in dubbio e concordo con te che evidentemente c'è qualche differenza tra Asus e Tech tale da inficiare la discovery...

[FrancYescO]

@larsen64it ci sono 3 for con 3 cp dentro, mettilo subito dopo i cp (sì lo eseguirà ad file che copia)

@bandit400 hai cambiato subnet dallasus o è la stessa? Magari il nas deve aggiornare il dominio LAN , non so per ora non mi vengono altre idee, dovrei approfondire come avviene quel discovery

[larsen64it]

Ho modificato do_migrate_overlay
https://termbin.com/y7x6
Alla fine della fiera mi son trovato in bank2 con bank1 attiva e vuota, con la gui originale e senza root
log
https://termbin.com/bwgmy

[bandit400]

@MisterFTTH : Si, interessante. Roba che proviene dal ReadyNAS OS della Netgear. Lo scovai su GitHub (https://github.com/kochinc/wsdd2, https://github.com/Andy2244/wsdd2) cercando una soluzione a questo problema. Se non mi sbaglio, ce ne dovrebbe essere anche qualcuno scritto in Python. Funziona benone, non da noie, non pesa e risolve un fastidio. Che chiedere di più?!

Codice: [Seleziona]

root@XXX ~ # ps aux | grep wsdd | grep -v grep
root         705  0.0  0.0   2484  2020 ?        Ss   15:02   0:00 /usr/sbin/wsdd2
root@XXX ~ #
@FrancYescO : Nulla. Non ho cambiato nulla. Sui client non è stato toccato nulla. Ripeto, sparito un Asus e subentrato un Technicolor. Il risultato è quello mostrato.
Per ulteriore prova, ho smontato un Asus RT-AC66U_B1, che mi fa da access point nell'altro lato di casa, e l'ho connesso al Technicolor al posto dell'altro Asus che si è fulminato. Il risultato è questo...



...mi aiutate?

[larsen64it]

https://github.com/christgau/wsdd

[MisterFTTH]

@bandit400 ma da client linux stesso comportamento? Non l'hai accennato in primis quindi o non si presenta il problema oppure non usi client linux...mera curiosità...

(avevo poi installato wsdd, la versione per altro linkata da larsen64it:  )

[LuKePicci]

@larsen64it l'echo lo devi mettere anche nei due cicli precedenti, non solo nel terzo

[bandit400]

@MisterFTTH : In verità non lo so. Da Fedora del NAS non opero molto e, quando mi serve, monto a mano la share che mi interessa.
Sollevo questo probema perché in casa mia moglie si è accorta di questa stranezza. Per ora ho tamponato connettendo il volume principale del NAS come unità di rete su ogni client Windows 10 di nostro interesse (3 PC, alla fine), ma tornare ad avere la vecchia "Network neighborhood" popolata in ogni client Windows 10 sarebbe, ovviamente, la soluzione migliore.

[larsen64it]

File modificato
https://termbin.com/4q1g
Modificando il file in 3 o 4 o 5 punti il risultato non cambia, si ferma sempre nello stesso punto prima del bootp

Codice: [Seleziona]

[   14.851000] mount_root-mod: copying /overlay/bank_2/* to /tmp/migrate_overlay/ ...
[   15.111000] mount_root-mod: copying /tmp/migrate_overlay/* to /modoverlay/bank_mod/ ...
[   21.648000] mount_root-mod: check-for-rm /overlay/bank_2/etc
[   21.660000] mount_root-mod: check-for-rm /overlay/bank_2/lib
[   21.668000] mount_root-mod: check-for-rm /overlay/bank_2/mnt
[   21.676000] mount_root-mod: check-for-rm /overlay/bank_2/modoverlay
[   21.682000] mount_root-mod: check-for-rm /overlay/bank_2/saferoot
[   21.689000] mount_root-mod: check-for-rm /overlay/bank_2/sbin
[   21.698000] mount_root-mod: check-for-rm /overlay/bank_2/usr
[   21.767000] mount_root-mod: migration done!
[   21.774000] mount_root-mod: update_file_if_needed /etc/init.d/rootdevice
[   21.821000] mount_root-mod: update_file_if_needed /etc/rc.d/S94rootdevice
[   21.840000] mount_root-mod: update_file_if_needed /usr/sbin/random_seed
[   21.856000] mount_root-mod: update_file_if_needed /sbin/insmod
[   21.876000] mount_root-mod: update_file_if_needed /lib/mount_modroot/05_transfer_basefiles
[   21.895000] mount_root-mod: update_file_if_needed /etc/init.d/do_migrate_overlay
[   21.922000] mount_root-mod: update_file_if_needed /usr/sbin/mount_modoverlay
[   21.941000] mount_root-mod: update_file_if_needed /sbin/mount_root-mod
Watchdog was terminated due to requested system reboot.
[   22.829000] ddr_tm_base_address 0xce800000, size 20971520/20971520, ddr_tm_base_address_phys 0x0e800000
[   22.830000] ddr_multicast_base_address 0xce400000, size 4194304/4194304, ddr_multicast_base_address_phys 0x0e400000
[   22.855000] ++++Runner gso_desc_pool created successfully
[   23.758000] RDPA Speed Service Command Driver
[   23.759000] RDPA DS WAN UDP Filter Command Driver
[   26.662000] Restarting system.
[   26.664000] kerSysMipsSoftReset: called on�----

[LuKePicci]

Buono, quel riavvio è richiesto dallo script, ora è arrivato in fondo alla migrazione. L'unico di quei 5 comandi (echo 1 > /dev/watchdog) che probabilmente serve davvero è il secondo,, il primo ed il terzo sono ragionevolmente evitabili, gli altri due sono di sicuro inutili.

Dopodiché va in BOOTP? Dopo quanti tentativi, servirebbe un altro log da cima a fondo, anche dei reboot successivi al BOOTP.

edit: lascia sempre anche gli "echo ... > /dev/kmsg" servono a capire ad ogni reboot se sta copiando gli stessi file, sospetto che dopo la prima migrazione (e conseguente reboot) lui ripeta erroneamente il processo di migrazione (e conseguente riavvio) all'infinito

[larsen64it]

Quello che ciò appare e dopo il secondo e terzo riavvio in bank2.... si riavviano nello stesso punto, dopodiché va in bootp.

[LuKePicci]

Ok chiaro, vediamo il log con gli echo sui nomi file cosa dice per la conferma, mi aspetto di vedere ripetersi proprio in questi ultimi tentativi sempre la stessa lista di una manciata di file.

[larsen64it]

Messi solo i primi 3 watchdog
https://anonfiles.com/T6x8R0Gboc/up_txt
Credo che per completare la copia serva il quarto ... il quinto non aveva effetti.