Installare Kubuntu o KDE Plasma su Ubuntu Server 24.04

Su Ubuntu Server 24.04 la scelta non è “installare un desktop” in astratto: devi decidere se vuoi Kubuntu, cioè il profilo desktop completo basato su KDE, oppure un KDE Plasma minimale sopra un server già pronto. La differenza pratica è netta: il primo approccio porta dentro più pacchetti, più servizi e più superficie d’attacco; il secondo ti lascia più controllo, ma richiede qualche decisione in più su display manager, sessione grafica e gestione remota.

Se il server è davvero in produzione, il punto non è solo “si può fare”, ma quanto impatto accetti: RAM occupata, spazio disco, avvio di servizi aggiuntivi, esposizione di login grafici e possibilità di accesso locale o remoto. Prima di toccare il sistema, conviene verificare lo stato attuale e preparare un rollback semplice. Su un host gestito via SSH, il rischio principale non è il pacchetto in sé, ma il cambio di stack grafico che può alterare login, target di systemd e accesso console.

Quando ha senso Kubuntu e quando basta Plasma

Kubuntu ha senso se vuoi un desktop pronto, coerente e con i componenti KDE già allineati: file manager, impostazioni, applicazioni base, login manager e sessione Plasma già predisposta. È la strada più semplice per una macchina che da server diventa anche postazione grafica.

KDE Plasma su Ubuntu Server è più adatto se vuoi mantenere il server il più pulito possibile e aggiungere solo l’interfaccia grafica necessaria. In pratica installi il desktop environment senza trasformare il sistema in una workstation completa. È la scelta che preferisco quando il server resta tale e il desktop serve solo per manutenzione locale, GUI di alcuni tool o accessi temporanei.

La regola operativa è semplice: se l’obiettivo è “uso quotidiano come desktop”, Kubuntu. Se l’obiettivo è “GUI occasionale e controllo stretto dei servizi”, Plasma minimale. In entrambi i casi, su un server con vincoli seri, valuta prima se non sia più sensato usare X11 forwarding, RDP, VNC o una macchina separata.

Verifiche prima dell’installazione

Prima di installare qualsiasi componente grafico, controlla spazio disco, memoria e stato del boot corrente. Non serve una fotografia perfetta, ma almeno questi dati devono essere chiari:

df -h / /var /home
free -h
systemctl get-default
uname -a

Atteso: spazio sufficiente sotto / e, se usi log estesi o cache pacchetti, margine anche su /var; default target normalmente multi-user.target su server. Se il disco è già al limite, il problema non è KDE ma la capacità di assorbire i pacchetti e gli aggiornamenti successivi.

Controlla anche che il server sia aggiornato e che non ci siano installazioni parziali o pacchetti in stato rotto:

sudo apt update
sudo apt -y full-upgrade
sudo apt -f install

Se apt -f install segnala dipendenze spezzate, fermati lì: installare un desktop su una base incoerente complica il troubleshooting e rende il rollback meno prevedibile.

Installare Kubuntu sul server: profilo completo

Il modo più diretto per ottenere un’esperienza Kubuntu è installare il metapacchetto desktop di Kubuntu. Su Ubuntu Server 24.04 questo aggiunge il set grafico standard e le dipendenze che ti aspetti da una postazione KDE completa.

Comando tipico:

sudo apt update
sudo apt install kubuntu-desktop

Durante l’installazione, il sistema può chiedere quale display manager usare. Su KDE, la scelta naturale è SDDM. Se il prompt compare, selezionalo; se non compare, puoi verificarlo dopo con:

cat /etc/X11/default-display-manager
systemctl status sddm

Atteso: il file punta a /usr/bin/sddm e il servizio risulta active (running). Se il server viene usato anche in remoto, considera che il display manager introduce una schermata di login locale: utile su console fisica, meno utile se non hai accesso diretto al monitor.

Una volta conclusa l’installazione, riavvia solo se necessario e verifica il target grafico:

systemctl get-default
systemctl status display-manager

Se il target di default passa a graphical.target, il sistema tenterà di avviare il desktop a ogni boot. Questo è corretto per una workstation, ma su un server può essere un cambio architetturale non banale. Se vuoi mantenere il comportamento da server e avviare la GUI solo quando serve, puoi lasciare il target di default invariato e lanciare la sessione grafica manualmente o tramite startx, dove appropriato.

Installare solo KDE Plasma: approccio più leggero

Se vuoi Plasma senza il pacchetto “tutto compreso”, installa l’ambiente desktop base e lascia fuori buona parte delle applicazioni accessorie. Su Ubuntu il metapacchetto più usato è kde-standard, ma in alcuni casi può essere ancora troppo abbondante. Per un setup più controllato, conviene ragionare per componenti.

Una base ragionevole è questa:

sudo apt update
sudo apt install plasma-desktop sddm

Se ti serve una sessione un po’ più completa ma sempre contenuta, puoi aggiungere applicazioni KDE selezionate in modo esplicito, per esempio file manager e terminale grafico:

sudo apt install dolphin konsole

Qui il vantaggio è evidente: sai esattamente cosa entra nel sistema. Il rovescio della medaglia è che devi gestire tu eventuali dipendenze mancanti rispetto a un profilo desktop completo. È una scelta corretta quando il server deve restare il più possibile vicino alla sua funzione originaria.

Gestire il display manager senza sorprese

Su KDE il display manager più naturale è SDDM, ma su un server può essere utile capire cosa sta facendo il sistema con i servizi grafici. Dopo l’installazione, controlla il servizio e l’unità generica del display manager:

systemctl status sddm
systemctl status display-manager

Se SDDM non parte, i log sono il primo posto da guardare:

journalctl -u sddm -b --no-pager
journalctl -u display-manager -b --no-pager

Un errore tipico è il conflitto tra display manager o una sessione grafica non coerente con la GPU o il driver video. In quel caso, la soluzione minima e reversibile è non forzare subito driver e accelerazione: prima verifica che il servizio si avvii con la configurazione base. Se il server è headless e ti serve solo accesso remoto, valuta se ha senso mantenere SDDM attivo oppure disabilitarlo e usare una sessione grafica remota dedicata.

Avvio grafico, accesso remoto e impatto operativo

Installare un desktop non significa che debba occupare sempre la scena al boot. Se il server è usato anche per servizi web, database o storage, l’impatto più concreto è il consumo di RAM e l’apertura di un login grafico locale. Su hardware stretto, questo si sente subito.

Per misurare l’effetto dopo l’installazione, confronta memoria e servizi attivi prima e dopo:

free -h
systemctl --type=service --state=running | grep -E 'sddm|plasma|kscreen|pipewire|wireplumber'

Non aspettarti che tutti questi servizi siano presenti in ogni installazione, ma se il numero cresce troppo rispetto al tuo caso d’uso, hai probabilmente installato più del necessario. Questo è il punto in cui conviene fermarsi e rifinire il profilo, non aggiungere altro “per sicurezza”.

Se vuoi operare da remoto, in molti scenari è più pulito usare SSH e, se serve GUI, un accesso remoto dedicato. In alternativa puoi installare un desktop e mantenerlo solo per console fisica, lasciando al server il suo ruolo principale. La decisione va presa prima, non dopo aver riempito il sistema di componenti grafiche.

Rollback pulito se il desktop non convince

Il rollback va pensato prima di installare. La strada più semplice è rimuovere il metapacchetto installato e poi ripulire le dipendenze non più necessarie. In pratica:

sudo apt remove kubuntu-desktop
sudo apt autoremove

Se hai installato componenti singoli, rimuovi solo quelli aggiunti. Per esempio:

sudo apt remove plasma-desktop sddm

Attenzione al blast radius: autoremove può eliminare pacchetti non più referenziati, quindi è bene leggere l’elenco prima di confermare. Il rischio non è la rimozione del desktop in sé, ma la possibilità di togliere anche dipendenze utili ad altri servizi. Se il server ospita più ruoli, verifica sempre cosa sta per uscire dal sistema.

Prima di disinstallare, salva lo stato dei pacchetti installati se vuoi una traccia chiara del cambio:

dpkg -l | grep -E 'kubuntu-desktop|plasma-desktop|sddm|kde'

Questa non è solo documentazione: in caso di ripristino rapido, sapere quali metapacchetti erano presenti evita di ricostruire l’ambiente a tentativi.

Problemi tipici dopo l’installazione

Se al reboot il sistema resta su console testuale, il primo controllo è banale: il display manager è attivo? Il target è grafico? La sessione ha errori nei log? La sequenza minima è questa:

systemctl get-default
systemctl status display-manager
journalctl -b -p err --no-pager

Se vedi errori legati a driver video, il problema potrebbe essere la GPU o l’assenza di accelerazione adeguata. Se invece il login grafico parte ma la sessione cade subito, guarda i log utente e quelli del display manager. In ambiente server, i problemi più frequenti non sono “KDE rotto”, ma conflitti con driver, permessi o un hardware grafico poco supportato.

Se il server ha una scheda video minimale o un accesso tramite console virtuale, il desktop può funzionare comunque, ma senza aspettarti fluidità da workstation. L’obiettivo qui è stabilità, non estetica. Se la parte grafica peggiora l’affidabilità del nodo, la scelta corretta è tornare a un setup headless e usare strumenti remoti più adatti.

Scelta pratica finale

In sintesi operativa: scegli Kubuntu quando vuoi un desktop KDE completo e accetti il cambio di profilo del server; scegli Plasma minimale quando vuoi aggiungere GUI con il minimo indispensabile. In entrambi i casi, parti da osservabilità, installa il meno possibile, controlla il display manager e tieni pronto il rollback con apt remove e apt autoremove. Su un server, il desktop non deve diventare un effetto collaterale permanente: deve restare una scelta consapevole, verificata e reversibile.