Installare Open Hardware Monitor su Ubuntu 20.04 LTS

Su Ubuntu 20.04 LTS non esiste un’installazione “pulita” di Open Hardware Monitor come su Windows, perché il progetto nasce per .NET Framework e per l’ecosistema hardware di Windows. Se l’obiettivo è leggere temperature, tensioni, ventole e carico CPU/GPU da una macchina Ubuntu, la scelta tecnica va fatta prima di tutto in base a cosa vuoi monitorare e quanto ti serve affidabilità. In pratica hai tre strade: usare un’alternativa nativa Linux, eseguire Open Hardware Monitor in Wine con aspettative basse, oppure esportare i dati verso un sistema di monitoraggio più serio.

La realtà tecnica: Open Hardware Monitor su Linux non è una soluzione nativa

Open Hardware Monitor legge sensori esposti da driver e API che, su Ubuntu, non sono equivalenti a quelli Windows. Anche se riesci ad avviare l’app, la parte utile spesso si riduce a poco o nulla: alcune letture non compaiono, altre restano vuote, altre ancora dipendono da supporto hardware molto specifico. Questo è il punto da chiarire subito: non stai installando un software Linux, stai cercando di far girare un programma Windows in un ambiente non pensato per lui.

Se il tuo scopo è controllare una workstation, un server o un mini PC con Ubuntu 20.04, conviene ragionare così:

• Vuoi solo vedere temperature e ventole: usa strumenti Linux nativi come lm-sensors e psensor.
• Vuoi l’interfaccia di Open Hardware Monitor per abitudine: prova Wine, ma considera il risultato come sperimentale.
• Vuoi monitoraggio affidabile nel tempo: esporta i dati a Prometheus, Zabbix, Grafana o a un pannello già in uso.

Prima verifica: il sistema espone davvero i sensori?

Prima di installare qualsiasi cosa, verifica se Ubuntu vede già l’hardware. Su molte macchine la differenza non la fa il software, ma il firmware, il BIOS/UEFI e i moduli kernel caricati. Se i sensori non sono esposti al sistema, nessuna GUI li inventa.

Installa gli strumenti base e fai una scansione:

sudo apt update
sudo apt install -y lm-sensors psensor
sudo sensors-detect

Durante sensors-detect accetta le rilevazioni proposte solo se capisci cosa stai abilitando. Alla fine esegui:

sensors

Se vedi temperature CPU, velocità ventole o valori di tensione, sei già a buon punto. Se l’output è vuoto o parziale, il problema è a monte: kernel module, BIOS, supporto chipset o permessi sui device in /sys/class/hwmon/.

Per capire rapidamente cosa è disponibile, controlla anche:

ls -l /sys/class/hwmon/
for d in /sys/class/hwmon/hwmon*; do echo "== $d =="; cat "$d/name" 2>/dev/null; done

Se qui non compare nulla di utile, Open Hardware Monitor non risolverà il problema. In quel caso la strada giusta è sistemare il layer sensori, non l’applicazione.

Opzione consigliata: alternative Linux native

Se l’obiettivo è operare su Ubuntu 20.04 in modo sensato, la combinazione più pratica è lm-sensors per la raccolta e psensor per la visualizzazione. È meno “scenografica” di Open Hardware Monitor, ma parla direttamente con Linux e con l’hardware reale.

Dopo l’installazione, avvia Psensor dal menu applicazioni oppure da terminale:

psensor

Se lavori su una macchina headless, puoi anche limitarti a leggere i dati da shell e integrarli in script o sistemi di monitoraggio. In ambienti server, questa è spesso la soluzione più pulita: meno dipendenze grafiche, meno problemi di sessione utente, meno tentativi di far convivere un tool desktop con un host da produzione.

Se vuoi proprio Open Hardware Monitor: passaggio via Wine

Qui vale la premessa pratica: non è la via consigliata, ma può avere senso in laboratorio, su una workstation personale, o per fare un confronto rapido con un ambiente Windows. Su Ubuntu 20.04 puoi installare Wine e provare a eseguire l’applicazione Windows, tenendo presente che l’interfaccia potrebbe aprirsi senza esporre dati utili.

Installa Wine e gli strumenti di base:

sudo dpkg --add-architecture i386
sudo apt update
sudo apt install -y wine64 wine32 winetricks

Verifica la versione:

wine --version

Scarica Open Hardware Monitor dal repository ufficiale del progetto o da una fonte che puoi verificare. Non usare archivi casuali già modificati, perché qui il rischio non è teorico: stai eseguendo un binario Windows fuori dal suo contesto nativo.

Se hai un archivio ZIP, crea una directory dedicata e avvia l’eseguibile con Wine:

mkdir -p ~/tools/openhardwaremonitor
cd ~/tools/openhardwaremonitor
unzip /percorso/OpenHardwareMonitor.zip
wine OpenHardwareMonitor.exe

Il primo avvio può creare il prefisso Wine in ~/.wine. Se l’app non parte, controlla l’errore a terminale: spesso il problema è un componente .NET mancante o una dipendenza di rendering. In quel caso puoi provare con winetricks, ma la probabilità di ottenere un funzionamento completo resta bassa.

Dipendenze .NET e limiti reali del porting

Open Hardware Monitor è legato a .NET Framework, non a .NET moderno nativo di Linux. Questo dettaglio conta perché Wine può emulare parte dell’ambiente Windows, ma non sempre riesce a coprire bene il comportamento richiesto dall’app e dal suo accesso ai sensori. In altre parole: l’eseguibile può anche lanciarsi, ma il valore operativo può restare scarso.

Se vuoi verificare se il problema è l’app o Wine, osserva tre segnali:

1. L’interfaccia si apre ma i sensori restano vuoti: il problema è quasi sempre nel supporto hardware o nel layer di accesso ai driver.
2. L’app non si avvia e Wine stampa errori su .NET o API mancanti: il problema è la compatibilità runtime.
3. L’app si avvia, ma i dati sono incoerenti o incompleti: il limite è la combinazione hardware + emulazione.

Questa distinzione ti evita di perdere tempo su una strada che, nel migliore dei casi, resta una dimostrazione e non uno strumento di monitoraggio affidabile.

Una soluzione più solida: esportare i dati in un sistema di monitoraggio

Se il requisito non è “vedere la finestrella” ma monitorare davvero, la scelta pulita è leggere i sensori da Linux e inviarli a un sistema centrale. Su Ubuntu 20.04 puoi fare in modo che i dati di lm-sensors siano consumati da un exporter o da un agente già presente nella tua infrastruttura.

Per un controllo locale minimo, puoi già usare il comando:

sensors | sed -n '1,120p'

Se stai costruendo un host da osservabilità, il passo successivo è scegliere una metrica obiettivo: ad esempio temperatura CPU, velocità ventole o saturazione termica. Senza una metrica target, installi software ma non risolvi un bisogno operativo.

Quando conviene fermarsi e non forzare Open Hardware Monitor

Ci sono casi in cui insistere con Open Hardware Monitor su Ubuntu non ha senso:

• server senza ambiente grafico;
• host con sensori già esposti correttamente da lm-sensors;
• macchine con hardware recente che richiede supporto nativo Linux;
• ambienti in cui serve tracciabilità, logging e alerting, non solo visualizzazione locale.

In questi contesti, l’uso di Wine aggiunge complessità senza un guadagno reale. Se il tuo obiettivo è amministrativo, meglio investire mezz’ora in una pipeline nativa che un pomeriggio in una compatibilità fragile.

Checklist operativa per Ubuntu 20.04

Se vuoi procedere in modo ordinato, questa è la sequenza che userei su una macchina reale:

1. Verifica che i sensori esistano con sensors.
2. Controlla /sys/class/hwmon/ per capire quali device sono esposti.
3. Installa psensor se vuoi una GUI nativa.
4. Prova Wine solo se hai un motivo specifico per usare Open Hardware Monitor.
5. Se il monitoraggio deve essere affidabile, integra i dati in un sistema centrale.

Questo approccio riduce il rischio di confondere il problema software con quello hardware. È una distinzione importante, perché spesso il vero collo di bottiglia è il supporto del kernel o del firmware, non l’applicazione che visualizza il dato.

Conclusione tecnica: cosa fare davvero

Su Ubuntu 20.04 LTS, Open Hardware Monitor non è la soluzione giusta come installazione nativa. Se ti serve uno strumento immediato e coerente con Linux, parti da lm-sensors e psensor. Se vuoi proprio usare Open Hardware Monitor, fallo passare da Wine sapendo che la compatibilità è parziale e che il valore operativo può essere limitato. Se invece stai amministrando un host in modo serio, porta i sensori in un sistema di monitoraggio nativo e usa la GUI solo come interfaccia, non come fondamento della raccolta dati.

In pratica: prima verifica che il sistema esponga i dati, poi scegli lo strumento. Fare il contrario porta quasi sempre a una falsa installazione riuscita e a un pannello vuoto.