VirtualBox 6.0 su Linux e Ubuntu si installa bene, ma solo se si chiariscono prima tre punti: il kernel deve poter caricare i moduli, il repository deve essere quello giusto per la distro, e l’utente che avvia le VM deve avere i permessi corretti. Saltare uno di questi passaggi porta ai classici sintomi: finestra che non parte, errore sui moduli, USB non disponibile, oppure VM che si avvia ma resta inutilizzabile perché manca l’accelerazione o l’accesso alla rete host-only.
Qui non serve fare teoria: conviene trattare l’installazione come un cambio controllato. Prima si verifica lo stato del sistema, poi si installa o aggiorna, quindi si controlla che i moduli siano caricati e che la GUI o la gestione da CLI rispondano. Se qualcosa non torna, il rollback deve essere semplice: rimozione del pacchetto, pulizia del repository aggiunto, e ripristino della configurazione precedente se si è toccato il gruppo utenti o l’Extension Pack.
Prerequisiti reali su Ubuntu e Linux
VirtualBox 6.0 è vecchio ma ancora presente in molti ambienti legacy. Su Ubuntu recente la parte delicata non è l’applicazione in sé, ma la compatibilità con il kernel e con i pacchetti DKMS. Prima di installare, conviene verificare versione del kernel, stato dei moduli e architettura del sistema.
Ecco i controlli minimi:
uname -r
lsb_release -a
dpkg --print-architecture
lsmod | egrep 'vboxdrv|vboxnetflt|vboxnetadp|vboxpci'
Se `lsmod` non mostra i moduli di VirtualBox, non è ancora un guasto: significa solo che il pacchetto non è installato oppure che i moduli non sono stati compilati per il kernel in uso. Il punto da chiudere è il toolchain locale: servono header del kernel, `dkms`, `build-essential` e, in alcuni casi, Secure Boot da gestire separatamente.
Installazione su Ubuntu con repository Oracle
Per Ubuntu, la via più lineare resta il repository Oracle, perché fornisce il pacchetto giusto per la serie 6.0 e aggiorna il componente principale senza dipendere da versioni vecchie nei mirror della distribuzione. Prima di procedere, conviene salvare il file sorgente del repository già presente, così il rollback è immediato.
Passaggi tipici:
- Aggiungere la chiave e il repository.
- Aggiornare l’indice pacchetti.
- Installare VirtualBox 6.0 e i moduli DKMS.
sudo apt update
sudo apt install -y wget gnupg ca-certificates dkms build-essential linux-headers-$(uname -r) wget -q https://www.virtualbox.org/download/oracle_vbox_2016.asc -O- | sudo gpg --dearmor -o /usr/share/keyrings/oracle-virtualbox.gpg echo "deb [arch=amd64 signed-by=/usr/share/keyrings/oracle-virtualbox.gpg] https://download.virtualbox.org/virtualbox/debian $(lsb_release -cs) contrib" | sudo tee /etc/apt/sources.list.d/virtualbox.list sudo apt update
sudo apt install -y virtualbox-6.0
Nota pratica: se la tua release Ubuntu non è più supportata dal repository Oracle per quella serie, il problema non è VirtualBox ma la combinazione distro/repository. In quel caso va chiuso con una verifica esplicita del file `sources.list.d` e della release codename restituita da `lsb_release -cs`. Se il repository non ha il pacchetto per quella release, si passa a un metodo alternativo, ad esempio pacchetto locale o upgrade del sistema ospite.
Installazione su distribuzioni Debian-based senza repository Oracle
Su sistemi derivati da Debian o su Ubuntu in ambienti con policy più rigide, può essere preferibile installare il pacchetto disponibile nel repository ufficiale della distro. La controparte è che la versione potrebbe non essere 6.0 esatta, quindi questo approccio ha senso solo se l’obiettivo è la stabilità operativa, non la fedeltà di versione.
Prima di cambiare strada, verifica il pacchetto disponibile:
apt-cache policy virtualbox
apt-cache search virtualbox | head
Se il pacchetto richiesto esiste ma non è la serie 6.0, la scelta va esplicitata: o accetti la versione del repository della distro, oppure mantieni il repository Oracle per allinearti alla 6.0. Mischiare pacchetti di origine diversa senza verifiche è il modo più rapido per finire con moduli incoerenti o dipendenze rotte.
Verifica dei moduli kernel e del caricamento automatico
Dopo l’installazione, il controllo più importante è il caricamento dei moduli. VirtualBox non è solo un binario grafico: senza `vboxdrv` non parte la virtualizzazione, senza `vboxnetflt` e `vboxnetadp` la rete host-only e parte delle funzionalità di networking risultano limitate.
sudo /sbin/vboxconfig
lsmod | egrep 'vboxdrv|vboxnetflt|vboxnetadp|vboxpci'
systemctl status vboxdrv.service 2>/dev/null || true
Se `vboxconfig` fallisce, il messaggio utile è quasi sempre in output: header mancanti, compilatore assente, oppure incompatibilità con il kernel. In pratica si chiude così: installi i prerequisiti, rilanci la compilazione e verifichi che i moduli compaiano in `lsmod`. Se Secure Boot è attivo, il problema può essere la firma dei moduli, non la compilazione. In quel caso il controllo va fatto nel firmware e nel log del boot, non dentro VirtualBox.
Un controllo rapido della versione installata evita ambiguità:
VBoxManage --version
virtualbox --help 2>/dev/null | head
Se il comando `VBoxManage` risponde ma la GUI no, il problema è spesso lato sessione grafica o permessi utente, non lato installazione. Se invece entrambi falliscono, va controllato prima il pacchetto e poi il percorso binario.
Permessi utente, gruppo `vboxusers` e accesso ai dispositivi
Molti problemi “misteriosi” di VirtualBox dipendono da un dettaglio banale: l’utente che avvia le VM non è nel gruppo `vboxusers`. Questo impatta soprattutto USB passthrough e alcune operazioni che richiedono accesso ai device. Il controllo va fatto in modo esplicito, poi si effettua logout/login per applicare la modifica.
groups $USER
sudo usermod -aG vboxusers $USER
Dopo il comando, non aspettarti effetti immediati nella sessione corrente: serve una nuova login session oppure un reboot. Il rollback è semplice: rimuovi l’utente dal gruppo se la policy interna non lo consente, ma fallo solo dopo aver verificato che il problema sia davvero quello e non un driver o un permesso su `udev`.
Extension Pack: quando serve davvero
Per VirtualBox 6.0, l’Extension Pack è necessario se ti servono USB 2.0/3.0 avanzato, RDP, cifratura del disco virtuale e altre funzioni non incluse nel pacchetto base. Non è un accessorio decorativo: va installato solo se usi davvero quelle feature, perché aggiunge un componente in più da tenere allineato alla versione del core.
Controlla prima la versione del core e poi quella dell’Extension Pack:
VBoxManage --version
VBoxManage list extpacks
La regola operativa è semplice: la versione dell’Extension Pack deve combaciare con quella di VirtualBox. Se non coincide, non cercare scorciatoie. Rimuovi il pacchetto errato e installa quello giusto, altrimenti ti ritrovi con errori in avvio o funzionalità disabilitate senza una causa immediata visibile.
sudo VBoxManage extpack install --replace Oracle_VM_VirtualBox_Extension_Pack-6.0.x.vbox-extpack
Se il file `.vbox-extpack` proviene da una fonte non affidabile, non installarlo: va trattato come software di terze parti con impatto sul sistema host. Scarica solo dal sito ufficiale e conserva il checksum se il processo di change lo richiede.
Aggiornamento da una versione precedente
L’aggiornamento è il punto in cui si rompe più spesso la continuità operativa, soprattutto quando si passa da una 5.x a 6.0 o quando il sistema ha un kernel aggiornato e moduli compilati in modo non coerente. La strategia giusta è: verificare la versione attuale, salvare la configurazione, aggiornare i pacchetti, ricompilare i moduli e poi testare una VM di prova.
VBoxManage --version
sudo apt update
sudo apt upgrade -y virtualbox-6.0
sudo /sbin/vboxconfig
Se l’upgrade cambia anche il kernel, il rischio non è VirtualBox in sé ma la finestra tra reboot e ricompilazione dei moduli. Per ridurre il blast radius, conviene fare il test prima su una macchina non critica o in finestra di manutenzione. Se la VM è essenziale, evita di aggiornare il pacchetto e il kernel nello stesso ciclo senza un punto di rollback chiaro.
Nel caso in cui il repository Oracle abbia una versione installata ma il sistema proponga un upgrade da repository della distro, non mischiare le sorgenti senza una scelta consapevole. Un mix tra pacchetti di origine diversa può lasciare i moduli in uno stato incoerente, e il problema emerge solo al riavvio o alla prima apertura della VM.
Controlli post-installazione che evitano sorprese
Dopo installazione o upgrade, il controllo non deve fermarsi alla versione stampata a schermo. Va verificato che una VM si avvii, che la rete sia funzionante e che l’host veda correttamente i dispositivi USB se richiesti. Questo è il punto in cui si distinguono i pacchetti installati correttamente da quelli solo “presenti”.
VBoxManage list vms
VBoxManage list hostonlyifs
VBoxManage list bridgedifs
Se la VM non parte, guarda prima i log della macchina virtuale, non solo la GUI. Il file `.vbox` e il log `VBox.log` nella directory della VM raccontano quasi sempre la vera causa: mancanza di VT-x/AMD-V nel BIOS, driver non caricati, oppure errori di accesso al disco virtuale.
Un test minimo utile è avviare una VM leggera e osservare se la console mostra errori subito dopo il boot. In ambienti server senza GUI, `VBoxManage startvm` e il relativo log bastano per capire se l’installazione è sana.
VBoxManage startvm "NomeVM" --type headless
Rollback pulito e punti di attenzione operativi
Se l’installazione o l’aggiornamento non va bene, il rollback deve essere lineare. Prima rimuovi l’Extension Pack se era stato installato, poi il pacchetto VirtualBox, quindi il repository aggiunto. Non cancellare a mano file di sistema se non hai prima verificato dove il pacchetto ha scritto davvero.
sudo VBoxManage extpack uninstall "Oracle VM VirtualBox Extension Pack"
sudo apt remove -y virtualbox-6.0
sudo rm -f /etc/apt/sources.list.d/virtualbox.list
sudo rm -f /usr/share/keyrings/oracle-virtualbox.gpg
sudo apt update
Il blast radius di queste operazioni è limitato al software di virtualizzazione e ai suoi moduli, ma le VM residenti restano intatte se non elimini le directory dati. Per questo è bene distinguere sempre tra pacchetto applicativo e storage delle macchine virtuali. Se le VM sono in una path custom, documentala prima del change.
Assunzione operativa: il sistema usa una release Ubuntu o Debian-based recente, con accesso sudo e repository gestibili dall’operatore; se il kernel è molto nuovo o Secure Boot è attivo, la verifica dei moduli firmati va fatta esplicitamente prima di considerare conclusa l’installazione.
Commenti (0)
Nessun commento ancora.
Segnala contenuto
Elimina commento
Eliminare definitivamente questo commento?
L'azione non si può annullare.