Distribuzione FUSS » fuss-client

Sarebbe utile sapere quali siano i messaggi di errore citati, idealmente con un typescript completo (come spiegato su Bug_Reporting)

Basandomi su quanto scritto fin'ora:

fuss-client -a non fa (esplicitamente) verifiche sull'hardware: fa delle richieste via rete verso il server, e al massimo delle richieste verso i repository per scaricare pacchetti da installare (che però su fuss-client dovrebbero essere già installati).

Nel caso fallisca l'agganciamento al server con richiesta password effettivamente fuss-client si interrompe senza dare il messagio di riepilogo finale, ma a quel punto ha solo contattato il server per ottenere alcuni dati e per fare l'agganciamento, scrivendo localmente nella directory /root, che non dovrebbe coinvolgere il lettore cdrom in alcun modo.

Il primo punto in cui mi viene in mente qualcosa che potrebbe leggere dal cdrom è successivo, quando vengono letti i repository dei pacchetti: questo però avviene dopo che sono iniziati i messaggi colorati, e quindi dovrebbe esserci un messaggio di riepilogo finale.
Questo caso potrebbe avvenire nel caso in cui dopo l'installazione siano rimasti abilitati in /etc/apt/sources.list i riferimenti al disco di installazione: questo mi stupisce, dato che mi risulta vengano disabilitati automaticamente, ma potrebbero essere stati riabilitati per qualche motivo, e spiegherebbero l'avvenuto tentativo (fallito) di lettura dal cdrom.

Per poterne sapere di più però, come scritto sopra, serve necessariamente il log completo dell'esecuzione.

Mi dispiace ma a ripordurre questo errore dovrei tornare in quella scuola sganciare il PC dal dominio ripristinare il hardware staccato e rifare la procedura. In sostanza il comportamento è quello che fuss-client -a -g <cluster> parte con la conferma della chiave ssh 3 volte la richiesta della password di root/sudoers del server per l'agganciamento ... Dopo di che iniza a fare delle manovre sul CD/DVD-ROM per mezzo minuto e poi secondo mè fuss-client va in timeout e butta fuori una serie di errori ...

Il problema è che ad andare in timeout probabilmente non è fuss-client ma uno dei tanti programmi che fuss-client lancia internamente per svolgere i suoi compiti.

Senza avere un log completo di quando il problema succede e con quali errori è impossibile scoprire di quale dei programmi si tratti e quindi non c'è modo di intervenire per aiutare fuss-client a prevenire la situazione.

Con le informazioni attuali io non posso fare altro che proporre di chiudere il bug in quanto non riproducibile, e semmai lo si può riaprire / aprirne un altro nel caso in cui succeda ancora e ci sia un typescript dell'esecuzione su cui lavorare.

Vista la neccessità del log completo appena rientro dalle ferie dopo il 20 agosto andrò alla scuola nella quale ho riscontrato l'errore descritto e cerco di riprodurlo. Quindi sospendiamo intanto il ticket e lo aggiorno quando ho disponibile l'esito delle prove che farò.

Ok, grazie Markus!

Buonasera!
non serve log :D
ho installato l'aula a vipiteno e tutti i pc con drive cdrom/dvd difettosi davano questo errore:
TASK [setup] ***********************************************************
An exception occurred during task execution. To see the full traceback, use -vvv. The error was: TimeoutError: Timer expired
fatal: [localhost]: FAILED! => {"changed": false, "cmd": "/bin/lsblk --list --noheadings --paths --output NAME,UUID --exclude 2", "failed": true, "msg": "Timer expired", "rc": 257}
to retry, use: --limit @/usr/share/fuss-client/connect.retry

da root manualmente il comando:
/bin/lsblk --list --noheadings --paths --output NAME,UUID --exclude 2

dava solo questo output:

/dev/sda
/dev/sda1 9ce3a25c-d9e5-4a15-a76d-958987171f56
/dev/sda2 82231d1a-753e-440f-8ad1-3d03143ffae6
/dev/sr0

pure usando lo switch -t di fuss-client settato a 100000 dava sempre timeout(col drive cdrom/dvd che cmq faceva rumori)

l'unica soluzione al momento è aprire i pc(appena visto battlestar galactica e mi ricorda sharon/boomer che si infila la fibra ottica nel polso) e staccare il drive cdrom/dvd che in alcune aule è un'impresa. tipo a vipiteno i pc sono appesi sotto al tavolo con una cinghia XD

saluti
Gianni

Riassegno a Paolo, dopo discussione di oggi sull'argomento.

Il problema e' legato ad ansible, non tanto a fuss-client, che fa la collects dei facts della macchina prima di procedere.

Puoi intervenire sulla collect dei facts di ansible?

Anche se rimango dell'idea che sarebbe meglio intervenire sull'hardware fuori uso (piuttosto levandolo) ed evitando che n utenti provino ad utilizzarlo lamentandosi del malfunzionamento.

Innanzitutto, noi usiamo alcuni dei facts durante la configurazione, per cui non possiamo semplicemente disattivare la loro raccolta.

È possibile disattivare la raccolta di una parte dei facts, ma in modo poco granulare, per cui non si può semplicemente dire di ignorare i cdrom, ma bisogna escludere tutti i fatti relativi all'hardware (e poi reinserire quelli relativi alla rete, che sicuramente ci servono: mi segno qui che il valore giusto di gather_subset per farlo sembra essere '!hardware,network' — da mettere nell'ansible.cfg).

Prima di farlo bisogna però controllare con cura che non si stia usando nessun fact della categoria "hardware", in nessuna delle modalità di funzionamento del fuss-client.

Però è un po' un hack per coprire il caso specifico dei cdrom che non funzionano, e anche secondo me la soluzione di togliere l'hardware che non va per evitare che poi gli utenti cerchino di usarlo è molto più pulita.

Come dicevo, se ci sono componenti hw guasti, o si disattivano/levano o si sostituiscono.
Non è il primo caso che mi capita: hai una macchina non nuova (e per la quale sorge il dubbio che tutto l'hardware sia funzionante) per la quale non vuoi fare un memtest e poi, a macchina installata, ti chiedi come mai il sistema vada in crash in modo non deterministico.

Chiudiamo il discorso che mi sembra non porta alla soluzione del problema indicato ... A me sembra più un bug che un Feature.

Acetto gli argomenti e la decisione in merito a questo discorso e cerco di arrangiarmi.

Saluti
Markus.