Le bizzarrie dell'hardware rotto/difettoso :-)

[clarintux]

Lo scopo di questo thread sarà rimarcare l'importanza importantissima dei backup ed, eventualmente, farci qualche risata sulle nostre e altrui disgrazie tecnologiche.

Qualunque cosa vi sia capitata, appartiene ormai al passato: quindi sdrammatizziamo un po' cercando magari di raccogliere bizzarrie divertenti, dovute ad una RAM difettosa o qualcosa di simile.
Postate qui quindi comportamenti imprevedibili, strani, che non succederebbero su hardware ancora sano. Sia chiaro...non problemi di compatibilità o semplici bug di un software...

Magari voi avrete qualcosa di più divertente, ma comincio io con un problema che ho attualmente:

ls -l /usr/share/terminfo/w/wyse60-43-w

lrwxrwxrwt 1 root 8388608 9 May  7  2023 /usr/share/terminfo/w/wyse60-43-w -> 'w'$'\371''60-43-w'

Non ho conoscenze informatiche così approfondite per potervi parlare di bit, numeri binari o ottali, ma posso dirvi che ci sono diversi bit sballati in quanto vi ho mostrato e che ciò è possibile "grazie" ad un hardware moribondo (probabilmente la RAM).
Intanto il file in questione sarebbe un link simbolico e non può esistere quella "t" (sticky bit) su un link simbolico su Linux. Al posto della "t" dovremmo avere una "x".
Poi si è sballato completamente anche il gruppo, che dovrebbe essere "root" (zero) e non "8388608".
Infine si è passati da una "y" a "$'\371'" nel nome del file a cui il link punta.

Poiché di questo sistema mi importa poco e sembra che tutto (quel che serve) continui a funzionare, rimando l'investigazione del problema e la sostituzione di... RAM? ...disco?. Chissenefrega visto che mi importano solo i dati e di quelli ho diversi backup. L'hardware si può buttare senza problemi.

Quindi eccomi qui a raccontarvi tranquillamente il fattaccio e (ri)consigliarvi di fare per bene i vostri backup!

Ma ora la parola a voi! Spero che qualcuno venga a raccontare le sue disavventure...

[DajeLinux]

@clarintux Ma come hai fatto ad individuare proprio quel file? E così a occhio, forse, potrebbe sembrare più un problema di disco!

[clarintux]

@DajeLinux Me ne sono accorto solo grazie ai backup, che venivano effettuati con successo ma saltando il trasferimento di un file. Poi guardando meglio:

rsync: [sender] readlink_stat("/usr/share/terminfo/w/wyse60-43-w") failed: Value too large for defined data type (75) IO error encountered -- skipping file deletion

Lo dico anche pubblicamente ( ) :
Si tratta di un piccolissimo server ancora attivo, per cui mi scoccia renderlo temporaneamente inattivo per effettuare test approfonditi. Il pacchetto memtester permette di testare un certo quantitativo di RAM su un sistema attivo: non mi ha rilevato alcun problema finora.
Comunque il disco sarebbe semplicemente una micro SD-card e tutto l'hardware costa quasi niente. È un server a risparmio, ma i diversi servizi che mi offre vanno ancora tutti (nonostante tutto). Vedremo...

Fino a ieri c'era una stranezza che avveniva solo ogni tanto e riguardava l'eseguibile /usr/bin/dircolors. Oggi il problema sembrava persistere e:

file /usr/bin/dircolors
/usr/bin/dircolors: ELF 32-bit LSB pie executable, ARM, EABI5 (SYSV), corrupted program header size, corrupted section header size

Boh...vedo se riesco a fare un test della micro SD-card.

[DajeLinux]

@clarintux Il fatto è che se facessi una copia 1:1 con dd poi ti porteresti dietro anche gli errori!

[clarintux]

L'unica cosa da fare è rifare un'installazione pulita su micro SD-card e/o Raspberry funzionante. Come detto, dati e configurazioni varie effettuate nel tempo erano comunque già in salvo. Per il resto pazienza!
La cosa richiederà sicuramente un attimo in più rispetto ad un "dd" da una SD-card all'altra, ma c'è di peggio...