Da LMDE 7 con driver nVidia 550: Unsloth Studio non li vuole!

di

Cronaca di un aggiornamento che doveva essere semplice

L’obiettivo iniziale sembrava innocente: provare Unsloth Studio
sulla workstation LMDE 7 con due RTX 3060 da 12 GB.

Naturalmente Linux ha interpretato “provare Unsloth” come “oggi
imparerai cose sui driver NVIDIA che non avevi mai chiesto di sapere“.

Alla fine, però, il risultato è stato decisamente buono: sistema
ripulito, driver NVIDIA aggiornati, CUDA Toolkit globale (cioè installato Bare-Metal) eliminato,
ComfyUI e Open WebUI funzionanti nei rispettivi ambienti virtuali,
entrambe le GPU operative e Unsloth Studio installato con PyTorch CUDA
13.

Questo articolo riassume da dove sono partito, cosa ho fatto,
perché e quali problemi ho incontrato (a raffica, uno dietro l’altro).

1. La configurazione di partenza

La macchina è basata su:

LMDE 7 "Gigi"
Debian base: Trixie / Debian 13
Kernel: 6.12.101+deb13-amd64

CPU: Xeon E5-1650 v4
GPU: 2 × NVIDIA RTX 3060 12 GB
Driver NVIDIA iniziale: 550.163.01
CUDA Toolkit globale iniziale: 12.4

(link al video su Youtube dove si vede meglio)

Sul sistema erano già funzionanti Ollama, ComfyUI e Open WebUI. Erano
inoltre presenti diversi ambienti virtuali Python (venv).

L’idea era aggiungere Unsloth Studio, soprattutto per sperimentare
con modelli Hugging Face e GGUF e capire quanto potesse offrire rispetto
a Ollama.

2. Il primo problema: Unsloth e le dipendenze moderne

La versione di Unsloth è l’ultima che si trova nel sito ufficiale:

unsloth 2026.8.16

L’installer moderno tendeva verso uno stack PyTorch 2.11 con CUDA 13, mentre
il mio sistema utilizzava ancora i driver NVIDIA 550 che arrivano fino a CUDA 12.4

In precedenza era stato tentato uno stack CUDA 12.4, ad esempio:

uv pip install torch==2.5.1 torchvision==0.20.1 
  --index-url https://download.pytorch.org/whl/cu124

Il problema era il conflitto con versioni recenti di xformers, che
richiedevano un PyTorch più nuovo.

Avrei potuto provare a forzare una versione precedente di xformers
compatibile con CUDA 12.4, come la famiglia 0.0.29, ma questo avrebbe
significato mantenere manualmente uno stack vecchio per adattarlo a
Unsloth moderno.

La decisione è stata quindi opposta: aggiornare il driver NVIDIA e
lasciare che ogni ambiente Python (venv) utilizzi il proprio runtime CUDA.

3. CUDA Toolkit globale: ci serviva davvero?

Sul sistema era presente:

/usr/local/cuda-12.4

Ho quindi verificato direttamente ComfyUI:

source ~/comfyvenv/bin/activate

e poi:

python -c "import torch; print('Torch:', torch.__version__); print('CUDA runtime:', torch.version.cuda); print('CUDA disponibile:', torch.cuda.is_available()); print('GPU:', torch.cuda.device_count())"

Risultato:

Torch: 2.6.0+cu124
CUDA runtime: 12.4
CUDA disponibile: True
GPU: 2

Questo dimostrava che ComfyUI utilizzava il runtime CUDA fornito dal
proprio ambiente Python/PyTorch.

Le dipendenze installate nel venv comprendevano infatti pacchetti come:

nvidia-cublas-cu12
nvidia-cuda-cupti-cu12
nvidia-cuda-nvrtc-cu12
nvidia-cuda-runtime-cu12
nvidia-cudnn-cu12
nvidia-cufft-cu12
nvidia-curand-cu12
nvidia-cusolver-cu12
nvidia-cusparse-cu12
nvidia-nccl-cu12
torch 2.6.0+cu124
torchvision 0.21.0+cu124

Il CUDA Toolkit globale non era quindi necessario per il normale
utilizzo di ComfyUI.

4. Open WebUI ci dà un altro indizio

Nel venv di Open WebUI il controllo di PyTorch mostrava:

Torch: 2.12.0+cu130
CUDA runtime: 13.0
CUDA disponibile: False
GPU: 2

PyTorch rilevava le GPU, ma segnalava che il driver NVIDIA era troppo
vecchio.

Questo era un indizio molto importante: aggiornare il driver avrebbe
sistemato non soltanto Unsloth, ma anche lo stack CUDA 13 già presente
in Open WebUI.

5. Rimozione del CUDA Toolkit globale

Ho quindi rimosso CUDA Toolkit 12.4 dal sistema.

Dopo la disinstallazione:

ls -ld /usr/local/cuda*

mostrava ancora:

/usr/local/cuda-12.4

ma:

ls -la /usr/local/cuda-12.4

rivelava che era rimasto praticamente soltanto:

nsight-systems-2023.4.4

Un residuo minuscolo.

ComfyUI continuava comunque a funzionare: Conferma pratica che il CUDA Toolkit globale non era necessario.

6. Preparazione all’aggiornamento NVIDIA

Il sistema:

cat /etc/os-release

riportava:

PRETTY_NAME="LMDE 7 (gigi)"
DEBIAN_CODENAME=trixie
DEBIAN_VERSION_FULL=13.0

Kernel:

uname -r
6.12.101+deb13-amd64

Architettura:

dpkg --print-architecture
amd64

Prima di modificare il driver ho verificato gli headers:

sudo apt install linux-headers-$(uname -r)

che erano già installati.

Poi:

dkms status

per controllare che i moduli DKMS fossero correttamente presenti per i
kernel installati.

7. Aggiunta del repository NVIDIA per Debian 13

Ho scaricato il keyring ufficiale:

wget https://developer.download.nvidia.com/compute/cuda/repos/debian13/x86_64/cuda-keyring_1.1-1_all.deb

e installato:

sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt update

Controllando:

apt-cache policy nvidia-driver

APT proponeva addirittura la serie 610.

Nel repository erano presenti le serie 590, 595 e 610. Ho scelto
590.48.01, evitando un salto ancora più aggressivo.

8. Pinning del driver 590.48.01

Provando a installare direttamente una versione specifica del driver,
APT tentava di mischiare dipendenze appartenenti alle serie 550, 590 e
610.

Ho quindi cercato i pacchetti di pinning NVIDIA:

apt-cache search '^nvidia-driver-pinning'

Tra i risultati era presente:

nvidia-driver-pinning-590.48.01

Installazione:

sudo apt install nvidia-driver-pinning-590.48.01
sudo apt update

Dopo:

apt policy nvidia-driver

mostrava:

590.48.01-1 1000

La versione 590.48.01 aveva quindi priorità sulle versioni 595 e 610.

Questo permetteva ad APT di mantenere coerenti le dipendenze della
stessa release NVIDIA.

9. DKMS e i vecchi kernel

Durante l’installazione del driver, DKMS ha compilato il modulo NVIDIA
per tutti i kernel ancora presenti:

6.12.48
6.12.90
6.12.90+deb13.1
6.12.95
6.12.100
6.12.101

Verifica:

dkms status | grep nvidia

mostrava NVIDIA 590.48.01 installato sui vari kernel.

Per controllare il modulo del kernel corrente:

modinfo nvidia | grep -E '^(version|filename):'

Risultato:

filename: /lib/modules/6.12.101+deb13-amd64/updates/dkms/nvidia.ko.xz
version: 590.48.01

10. Primo reboot: conflitto con nouveau

Al primo riavvio (con kernel 6.12.101) compariva:

NVRM: GPU 0000:02:00.0 is already bound to nouveau

e il sistema non rispondeva più, mentre con il kernel 6.12.100 riusciva comunque ad arrivare in TTY (riga di comando senza desktop). Digitando:

startx

Cinnamon partiva.

Questo indicava che kernel, Xorg e desktop non erano completamente
compromessi. Il problema riguardava soprattutto l’inizializzazione
automatica tramite LightDM e lo stack NVIDIA durante il boot.

11. Configurazione della GPU primaria

La workstation dual-GPU aveva già una configurazione Xorg specifica.

Controllo:

grep -RniE 'BusID|PCI:1|nvidia' /etc/X11 /etc/lightdm 2>/dev/null

Risultato:

/etc/X11/xorg.conf.d/10-primary-gpu.conf:3: Driver "nvidia"
/etc/X11/xorg.conf.d/10-primary-gpu.conf:4: BusID "PCI:1:0:0"

La RTX 3060 sul bus 01:00.0 rimaneva quindi la GPU primaria per il
display.

12. nvidia-smi era sparito

Dopo il cambio di packaging:

ls -l /usr/bin/nvidia-smi

restituiva file inesistente.

Controllando:

dpkg -l | grep -E 'nvidia-smi|nvidia-driver|nvidia-kernel'

risultava:

nvidia-smi 590.48.01-1 Transitional dummy package

E:

dpkg -L nvidia-smi

mostrava praticamente soltanto documentazione.

Il pacchetto nvidia-smi era quindi diventato un pacchetto di
transizione nel nuovo repository.

13. Installazione dei componenti compute NVIDIA

Ho verificato:

apt policy nvidia-driver-cuda

ottenendo:

Candidato: 590.48.01-1

nvidia-driver-cuda non è il CUDA Toolkit completo: installa componenti
compute associati al driver NVIDIA.

Prima di procedere ho simulato:

sudo apt install --simulate nvidia-driver-cuda

APT proponeva di rimuovere il vecchio pacchetto dummy nvidia-smi e
installare componenti come:

libcudadebugger1
libnvidia-fbc1
libnvidia-nvvm4
libnvidia-opticalflow1
libnvidia-present
libnvidia-sandboxutils
libnvoptix1
nvidia-opencl-icd
nvidia-driver-cuda

Dopo l’installazione:

nvidia-smi

funzionava nuovamente:

NVIDIA-SMI 590.48.01
Driver Version: 590.48.01
CUDA Version: 13.1

ed entrambe le RTX 3060 venivano rilevate.

14. LightDM e il problema GLX

Ma tornando al mancato avvio, da TTY LightDM risultava attivo:

systemctl status lightdm --no-pager -l

e la configurazione conteneva già un ritardo:

systemctl cat lightdm
[Service]
ExecStartPre=/bin/sleep 3

Analizzando Xorg è emerso un problema con il modulo GLX NVIDIA.

Ho cercato:

sudo find /usr -name 'libglxserver_nvidia.so*' -o -name 'libglxserver_nvidia.so' 2>/dev/null

Risultato:

/usr/lib/xorg/modules/extensions/libglxserver_nvidia.so.590.48.01

Il file esisteva, ma mancava il collegamento generico
libglxserver_nvidia.so.

Verifica del pacchetto proprietario:

dpkg -S /usr/lib/xorg/modules/extensions/libglxserver_nvidia.so.590.48.01

Risultato:

xserver-xorg-video-nvidia

Ho quindi creato il symlink:

sudo ln -s /usr/lib/xorg/modules/extensions/libglxserver_nvidia.so.590.48.01 
/usr/lib/xorg/modules/extensions/libglxserver_nvidia.so

Controllo:

ls -l /usr/lib/xorg/modules/extensions/libglxserver_nvidia.so*

Il link risultava correttamente creato.

Tornando in TTY e riavviando LightDM con il comando:

sudo systemctl restart lightdm

la schermata di login è apparsa.

15. La race condition di LightDM

Al reboot successivo il sistema tornava però a fermarsi in TTY.

La cosa interessante era che bastava fare login e:

sudo systemctl restart lightdm

per ottenere immediatamente il login grafico.

Il problema era quindi fortemente compatibile con una race condition
durante il boot: LightDM partiva prima che lo stack NVIDIA fosse
completamente pronto.

Il precedente ritardo di 3 secondi non bastava più con il driver 590.

Ho modificato:

sudo systemctl edit lightdm

portando l’override a 5 secondi anziché 3:

[Service]
ExecStartPre=/bin/sleep 5

Poi:

sudo systemctl daemon-reload
sudo reboot

Con 5 secondi di ritardo, LightDM è partito regolarmente.

16. Situazione NVIDIA finale

Dopo il reboot:

nvidia-smi

mostrava:

NVIDIA-SMI 590.48.01
Driver Version: 590.48.01
CUDA Version: 13.1

Le due schede:

GPU 0: NVIDIA GeForce RTX 3060 - PCI 01:00.0 - Display On
GPU 1: NVIDIA GeForce RTX 3060 - PCI 02:00.0 - Display Off

Xorg e Cinnamon utilizzavano principalmente la prima GPU, come previsto
dalla configurazione BusID "PCI:1:0:0".

17. Pulizia dei vecchi kernel

Controllo dei kernel e degli headers:

dpkg -l | grep -E 'linux-image|linux-headers' | grep '6.12'

Ho mantenuto soltanto:

6.12.101  - kernel principale
6.12.100  - kernel di backup

e rimosso i kernel più vecchi:

6.12.95
6.12.90
6.12.90+deb13.1
6.12.48

insieme ai relativi headers.

Dopo la pulizia:

dkms status

mostrava soltanto i moduli relativi ai kernel 100 e 101:

broadcom-sta
nvidia/590.48.01
v4l2loopback

Anche /boot era finalmente ridotto ai due kernel necessari:

ls -lh /boot

18. Attenzione ad apt autoremove

Prima di eseguire una pulizia automatica ho lanciato il seguente comando:

apt autoremove --dry-run

APT proponeva di eliminare anche:

glx-alternative-mesa
glx-alternative-nvidia
glx-diversions
update-glx

oltre ad alcune librerie i386 NVIDIA/Mesa.

Dopo i problemi appena risolti con GLX, la scelta prudente è stata non
eseguire quell’autoremove alla cieca.

La simulazione --dry-run è utile proprio per questo: permette di
vedere cosa verrebbe eliminato senza modificare il sistema.

19. Open WebUI dopo il driver 590

Prima dell’upgrade:

Torch: 2.12.0+cu130
CUDA runtime: 13.0
CUDA disponibile: False

Dopo il driver 590, nel relativo venv:

python -c "import torch; print('Torch:', torch.__version__); print('CUDA runtime:', torch.version.cuda); print('CUDA disponibile:', torch.cuda.is_available()); print('GPU:', torch.cuda.device_count())"

Risultato:

Torch: 2.12.0+cu130
CUDA runtime: 13.0
CUDA disponibile: True
GPU: 2

Il problema era quindi realmente il vecchio driver 550.

20. Test CUDA reale sulle due RTX 3060

Non ci siamo limitati a verificare torch.cuda.is_available().

Ho eseguito un vero calcolo CUDA su entrambe le schede:

python - <<'PY'
import torch

print("Torch:", torch.__version__)
print("CUDA:", torch.version.cuda)
print("GPU rilevate:", torch.cuda.device_count())

for i in range(torch.cuda.device_count()):
    print(f"nGPU {i}: {torch.cuda.get_device_name(i)}")
    x = torch.randn((4096, 4096), device=f"cuda:{i}")
    y = x @ x
    torch.cuda.synchronize(i)
    print("Calcolo CUDA: OK")
    print(f"VRAM allocata: {torch.cuda.memory_allocated(i)/1024**2:.1f} MiB")

print("nEntrambe le GPU funzionano correttamente.")
PY

Risultato:

Torch: 2.12.0+cu130
CUDA: 13.0
GPU rilevate: 2

GPU 0: NVIDIA GeForce RTX 3060
Calcolo CUDA: OK
VRAM allocata: 136.1 MiB

GPU 1: NVIDIA GeForce RTX 3060
Calcolo CUDA: OK
VRAM allocata: 136.1 MiB

Entrambe le GPU funzionano correttamente.

Questa è una verifica molto più significativa del semplice rilevamento
delle schede: PyTorch ha realmente eseguito codice CUDA su entrambe le
GPU.

21. Installazione pulita di Unsloth Studio

Con il sistema finalmente sistemato ho rilanciato l’installer di
Unsloth senza forzare manualmente versioni vecchie di Torch o xformers.

L’installer ha rilevato:

torch 2.11.0+cu130

e ha installato automaticamente componenti compatibili, tra cui:

torchao==0.17.0

La versione installata di Unsloth:

unsloth 2026.8.16

All’avvio Studio ha finalmente mostrato:

Hardware detected: CUDA -- NVIDIA GeForce RTX 3060
CUDA devices (2, CUDA_DEVICE_ORDER=PCI_BUS_ID):
  [0] NVIDIA GeForce RTX 3060
  [1] NVIDIA GeForce RTX 3060

Entrambe le GPU venivano quindi rilevate correttamente.

22. Primo modello di prova

Come primo test è stato scelto:

Qwen3.6-27B-MTP-GGUF · UD-Q4_K_XL

Un modello abbastanza grande da rendere interessante la verifica della
distribuzione sulle due RTX 3060.

Per monitorare le GPU è particolarmente comodo:

nvtop

Rispetto a:

watch -n 1 nvidia-smi

nvtop permette di osservare più comodamente:

  • utilizzo di GPU 0 e GPU 1;
  • VRAM occupata;
  • processi;
  • andamento del carico in tempo reale.

Il test importante è distinguere tra Unsloth rileva due GPU e
Unsloth utilizza realmente entrambe per il modello.

23. Unsloth Studio e la generazione immagini

Un’altra sorpresa è stata la sezione immagini integrata direttamente in
Unsloth Studio.

L’interfaccia mette a disposizione funzioni come:

Create
Transform
Inpaint
Extend
Upscale
Reference
Edit

oltre a prompt, negative prompt, aspect ratio, risoluzione e numero di
step.

Questo significa che Studio non è soltanto una GUI per LLM o
un’alternativa a Ollama.

Si presenta come un ambiente locale più ampio per:

  • LLM;
  • modelli Hugging Face;
  • GGUF;
  • training e fine-tuning;
  • generazione e modifica di immagini;
  • gestione di altri modelli AI.

ComfyUI rimane naturalmente molto più adatto ai workflow grafici
complessi, ma Unsloth Studio dispone di una propria interfaccia per le
immagini e non deve necessariamente appoggiarsi a ComfyUI come frontend.

Configurazione finale

LMDE 7 / Debian 13
│
├── Kernel
│   ├── 6.12.101  <- principale
│   └── 6.12.100  <- backup
│
├── NVIDIA
│   ├── Driver 590.48.01
│   ├── supporto CUDA driver: 13.1
│   ├── RTX 3060 12 GB #0
│   └── RTX 3060 12 GB #1
│
├── CUDA Toolkit globale
│   └── NON NECESSARIO per questi workload
│
├── ComfyUI
│   └── Torch 2.6.0 + cu124
│
├── Open WebUI
│   └── Torch 2.12.0 + cu130
│
├── Unsloth Studio
│   ├── Unsloth 2026.8.16
│   ├── Torch 2.11.0 + cu130
│   └── 2 × RTX 3060 rilevate
│
└── LightDM
    ├── GPU primaria PCI:1:0:0
    └── ExecStartPre=/bin/sleep 5

La lezione più importante: driver NVIDIA e runtime CUDA non sono la stessa cosa

Il punto che inizialmente generava più confusione era CUDA.

Per questo tipo di workstation non è necessariamente utile avere un
intero CUDA Toolkit installato globalmente.

La configurazione ottenuta è concettualmente questa:

                    DRIVER NVIDIA 590
                           │
                  supporto CUDA 13.1
                           │
          ┌────────────────┼────────────────┐
          │                │                │
       ComfyUI         Open WebUI        Unsloth
          │                │                │
      Torch cu124      Torch cu130      Torch cu130
          │                │                │
      runtime suo      runtime suo      runtime suo

Ogni ambiente Python può portare con sé le librerie CUDA richieste dalla
propria build di PyTorch.

Il sistema operativo deve invece fornire un driver NVIDIA
sufficientemente recente da supportare quei runtime.

Il risultato pratico è che PyTorch cu124 e cu130 possono convivere
sulla stessa macchina, anche senza installare globalmente CUDA Toolkit
12.4 o CUDA Toolkit 13.

Conclusione

L’obiettivo iniziale era semplicemente installare Unsloth Studio.

Per arrivarci ho:

  1. verificato gli ambienti Python esistenti;
  2. capito che CUDA Toolkit globale non era indispensabile;
  3. rimosso il vecchio Toolkit 12.4;
  4. aggiunto il repository NVIDIA aggiornato per Debian 13;
  5. bloccato il driver alla versione 590.48.01;
  6. aggiornato driver e componenti compute;
  7. sistemato il caricamento GLX di Xorg;
  8. risolto una race condition di LightDM aumentando il ritardo da 3 a 5
    secondi;
  9. ripulito i vecchi kernel;
  10. verificato con un vero calcolo CUDA entrambe le RTX 3060;
  11. confermato il funzionamento CUDA 13 di Open WebUI;
  12. installato Unsloth Studio 2026.8.16 con Torch 2.11.0+cu130;
  13. verificato che Unsloth rilevasse entrambe le RTX 3060.

Il risultato finale è una workstation decisamente più pulita e moderna
rispetto alla situazione iniziale.

… e son solo partito da “provo Unsloth”.

Ho finito per aggiornare mezzo stack NVIDIA, diagnosticare GLX,
convincere LightDM ad aspettare cinque secondi, ripulire quattro kernel
e far convivere CUDA 12.4 e CUDA 13 nei rispettivi ambienti Python.

La normale esperienza Linux del venerdì pomeriggio.

Aggiornamento:
Unsloth è apparentemente la svolta … ecco la prova che splitta un modello da 19Gb sulle due 3060 occupando nella prima 10,5 Gb e nella seconda 9,8 Gb!!

Lascia un commento