Come installare Oracle Linux su Windows 10 e 11 con WSL

Oracle Linux su WSL: quando ha senso e cosa aspettarsi

Oracle Linux su Windows 10 e 11 con WSL è una scelta sensata quando vuoi un ambiente Linux coerente con stack enterprise, strumenti compatibili con RHEL e una base pulita per testare script, automazioni, pacchetti e comportamenti di shell senza aprire una VM completa. Non è la strada giusta se ti servono kernel modules, systemd in ogni scenario o un isolamento forte: in quei casi una VM resta più lineare. Su WSL, invece, il vantaggio è pratico: avvio rapido, integrazione con filesystem Windows e costo operativo minimo.

Il punto da chiarire subito è il livello. WSL 1 traduce chiamate Linux in richieste Windows; WSL 2 usa una vera macchina virtuale leggera con kernel Linux. Per Oracle Linux, nella pratica, WSL 2 è la scelta corretta quasi sempre: migliore compatibilità, comportamento più vicino a Linux reale e meno sorprese con pacchetti e networking. Se il tuo obiettivo è usare Oracle Linux come base di lavoro quotidiana, parti da WSL 2 e non tornare indietro salvo vincoli specifici.

Prerequisiti reali: Windows, virtualizzazione e distribuzione

Prima di installare qualsiasi distribuzione, verifica tre cose: versione di Windows, supporto alla virtualizzazione e disponibilità di WSL 2. Su Windows 11 la parte è quasi sempre già predisposta; su Windows 10 conviene controllare build e aggiornamenti. Se la CPU o il firmware hanno la virtualizzazione disattivata, WSL 2 non parte correttamente e la distribuzione resta inutilizzabile o degradata.

Da PowerShell con privilegi amministrativi, il controllo minimo è questo:

wsl --status
wsl --version
systeminfo | findstr /i "Virtualization Hyper-V"

Se `wsl --status` non risponde o mostra errori, manca il componente WSL o il sistema non è aggiornato abbastanza. Se `systeminfo` indica che la virtualizzazione non è abilitata nel firmware, il fix non è lato Windows: devi intervenire nel BIOS/UEFI e abilitare Intel VT-x o AMD-V. Questo è il classico caso in cui si perde tempo a inseguire problemi di rete o distribuzione quando il blocco è sotto.

Installazione di WSL e attivazione della base Linux

Su Windows 11, e su Windows 10 aggiornato, il percorso più pulito è usare il comando nativo di WSL per installare il sottosistema e una distribuzione base. Anche se Oracle Linux non è sempre presente nello store predefinito di Microsoft, il flusso WSL va preparato allo stesso modo: prima abiliti il motore, poi importi o installi la distro.

Apri PowerShell come amministratore e lancia:

wsl --install
wsl --set-default-version 2

Il primo comando abilita i componenti richiesti e, se possibile, installa una distribuzione predefinita. Il secondo imposta WSL 2 come versione standard per le nuove distro. Dopo il riavvio, controlla lo stato con `wsl --status`. L’output atteso deve indicare kernel installato, WSL aggiornato e versione predefinita pari a 2.

Se il sistema è già predisposto ma non vuoi toccare il resto, puoi limitarti a verificare i feature flag di Windows. In caso di dubbi, il controllo lato GUI è in Attiva o disattiva funzionalità Windows: devono risultare attivi Sottosistema Windows per Linux e Piattaforma macchina virtuale. Se uno dei due manca, WSL 2 non si comporta come previsto.

Come ottenere Oracle Linux: Store, import manuale o tarball

Qui ci sono tre strade. La prima è lo store Microsoft, se Oracle Linux è disponibile nel tuo ambiente o nella tua policy aziendale. La seconda è l’import manuale di una rootfs tar. La terza è usare un’immagine già preparata da Oracle o da un repository affidabile e registrarla in WSL. Per un ambiente serio, la seconda e la terza sono le più controllabili perché ti consentono di fissare versione, checksum e percorso di installazione.

Se hai una rootfs compatibile, l’import è semplice. Esempio:

wsl --import OracleLinux C:\WSL\OracleLinux C:\temp\oraclelinux-rootfs.tar --version 2

Qui `C:\WSL\OracleLinux` è la directory dove WSL salva la distro, mentre il file `.tar` contiene il filesystem iniziale. Il vantaggio operativo è evidente: puoi tenere il pacchetto sotto controllo, replicarlo su più PC e fare rollback cancellando la distro importata e reimportando una versione precedente. Prima di importare, verifica sempre checksum o firma del pacchetto se il canale lo consente.

Se usi lo Store, il flusso è più rapido ma meno governabile. In quel caso conviene annotare versione esatta e sorgente del pacchetto, perché al primo refresh potresti ritrovarti con una rootfs aggiornata e non perfettamente allineata al resto del parco macchine. Per un laptop personale va bene; per un ambiente aziendale, molto meno.

Primo avvio e configurazione dell’utente

Dopo l’import o l’installazione, avvia la distro:

wsl -d OracleLinux

Al primo avvio, se la distribuzione è stata preparata correttamente, ti verrà chiesto di creare un utente Linux. Questo utente non deve essere root per l’uso normale. Con WSL è una cattiva abitudine lavorare sempre da root solo perché è comodo: basta un errore su file condivisi con Windows per fare danni inutili. Crea un utente operativo e usa `sudo` solo quando serve.

Se vuoi impostare l’utente predefinito da shell Windows, il metodo dipende da come hai registrato la distro. In generale, il controllo utile è questo:

wsl -l -v

L’output deve mostrare la distribuzione Oracle Linux, lo stato `Running` o `Stopped` e soprattutto la colonna `VERSION` uguale a 2. Se vedi `1`, la distro non sta usando il backend corretto e conviene correggerlo subito con:

wsl --set-version OracleLinux 2

La conversione può richiedere tempo in base alla dimensione della rootfs. Non interromperla e non forzare chiusure arbitrarie.

Pacchetti base: dnf, repository e strumenti da tenere subito pronti

Una volta dentro Oracle Linux, la prima verifica non è estetica ma funzionale: repository, update e tool essenziali. Oracle Linux usa `dnf` nella linea moderna, quindi il controllo iniziale è semplice:

sudo dnf repolist
sudo dnf check-update
sudo dnf install -y vim-enhanced git curl wget bind-utils net-tools

Se `dnf check-update` fallisce con problemi di mirror o DNS, il problema non è Oracle Linux in sé: su WSL 2 la rete passa da un layer virtuale e i nomi host possono fallire se il resolver è incoerente. In quel caso, prima di toccare repository o proxy, verifica che la navigazione da Windows funzioni e che dentro la distro `cat /etc/resolv.conf` mostri un nameserver valido. È un errore comune modificare a mano questo file senza aver capito chi lo rigenera.

Per un ambiente di lavoro minimale, io terrei subito pronti `curl`, `bind-utils`, `git` e un editor decente. Se fai amministrazione o sviluppo, aggiungi `rsync`, `tar`, `jq`, `openssl` e `procps-ng`. Sono pacchetti piccoli, ma evitano di dover tornare al prompt Windows per operazioni banali.

Rete, DNS e filesystem: i tre punti dove WSL sorprende più spesso

La rete in WSL 2 è comoda ma non identica a una macchina fisica. L’indirizzo IP della distro cambia, il firewall di Windows può interferire e alcuni servizi che ascoltano solo su `127.0.0.1` non sono esposti come ti aspetti. Se stai testando web server, API o database locali, il primo controllo è sempre il binding del servizio e non il firewall. Un server che ascolta soltanto su loopback dentro WSL non è raggiungibile dall’esterno del subsystem senza configurazione aggiuntiva.

Per verificare lo stato, usa:

ip addr show
ss -lntp
cat /etc/resolv.conf

Se devi esporre un servizio verso la LAN o verso Windows, ragiona sul binding applicativo e sul forwarding. Non partire da regole firewall a caso. Prima chiarisci se il processo ascolta su `0.0.0.0`, su `127.0.0.1` o su un indirizzo specifico della distro. È la differenza tra “non va” e “non è esposto”.

Il filesystem è l’altro compromesso da conoscere. I file sotto `/home` vivono nel filesystem Linux e sono più adatti a carichi Unix-like; i file sotto `/mnt/c` stanno sul filesystem Windows e sono comodi per scambio e integrazione, ma possono essere più lenti su operazioni con molti inode. Se fai build, test o lavori con repository git grandi, conviene tenere il codice dentro la home Linux e usare `/mnt/c` solo quando serve davvero l’interscambio.

systemd, servizi e differenze operative da non ignorare

Su alcune versioni di WSL il supporto a `systemd` è disponibile e va abilitato esplicitamente. Se devi eseguire servizi come database leggeri, agent di monitoraggio o stack di sviluppo che si aspettano systemd, controlla prima di tutto se è attivo:

ps -p 1 -o comm=

Se il PID 1 non è `systemd`, non dare per scontato che i servizi si comportino come su una VM classica. Se la tua build di WSL supporta systemd, l’abilitazione avviene nel file `/etc/wsl.conf`:

[boot]
systemd=true

Dopo la modifica, da PowerShell esegui:

wsl --shutdown

e poi riapri la distro. Se `ps -p 1 -o comm=` continua a non mostrare `systemd`, il supporto non è disponibile nel tuo ramo di WSL o la distro non ha preso la configurazione. In quel caso non forzare workaround strani: verifica la versione di WSL con `wsl --version` e la documentazione della build installata.

Integrazione con Windows: editor, path e scambio file

L’integrazione migliore è quella che non ti fa confondere i due mondi. Usa Windows per editor grafici se ti serve, ma conserva il lavoro operativo dentro la distro. Per aprire la directory corrente in Esplora file da WSL puoi usare:

explorer.exe .

Se vuoi richiamare un eseguibile Windows da shell Linux, puoi farlo con il nome `.exe`, ma senza abusarne. È comodo per strumenti puntuali, non per costruire flussi critici. Al contrario, quando lavori da PowerShell, puoi entrare in WSL con `wsl` e lanciare i comandi Linux direttamente. La regola operativa è semplice: scegli un ambiente primario e usa l’altro solo come supporto, non come terra di mezzo permanente.

Per capire dove stai lavorando, controlla il path e la home corrente:

pwd
echo $HOME

Se il tuo progetto vive in `/mnt/c`, accetta il trade-off prestazionale e tieni d’occhio i permessi e i caratteri di fine riga. Se il tuo progetto vive in `/home`, avrai comportamento Linux più pulito. In entrambi i casi, evita di mischiare troppo i due ambiti nello stesso flusso di build.

Snapshot, backup e rollback: la parte che salva tempo

Il vantaggio di WSL è che il rollback è molto più semplice di una macchina fisica. Prima di modificare pacchetti, repository o configurazioni di sistema, conviene esportare la distribuzione. È un’operazione lineare e ti consente di tornare indietro senza smontare il sistema a mano:

wsl --export OracleLinux C:\backup\OracleLinux-backup.tar

Se qualcosa si rompe e vuoi ripartire pulito, chiudi la distro e reimporta l’archivio. Questo approccio è più affidabile del tentare riparazioni casuali, soprattutto quando hai cambiato repository o librerie di sistema. Il blast radius resta basso: tocchi una sola distribuzione, non l’intero Windows host. Il rollback, però, va pianificato prima di installazioni invasive, non dopo il primo errore serio.

Se devi fare un cambio controllato, annota sempre tre cose: versione di Oracle Linux, versione di WSL e origine del rootfs. Sono i dati che ti servono per riprodurre il problema o per dimostrare che non è un bug dell’ambiente ma una differenza di build.

Problemi tipici e come leggerli senza perdere mezz’ora

Se la distro non parte, il problema più probabile è uno di questi: virtualizzazione disattivata, WSL non aggiornato, rootfs corrotta o versione sbagliata. Se i repository non risolvono i nomi, guarda DNS e `resolv.conf`. Se i servizi non ascoltano dall’esterno, guarda il binding e non il pacchetto. Se i comandi sono lenti sui file, sposta il lavoro nel filesystem Linux.

Una verifica rapida utile è questa:

wsl -l -v
wsl --status
cat /etc/os-release
ip route

`/etc/os-release` deve identificare chiaramente Oracle Linux; `ip route` deve mostrare una route coerente; `wsl -l -v` deve confermare la versione 2. Se uno di questi elementi non torna, non andare a tentativi: hai già il punto dove si rompe la catena.

Quando Oracle Linux su WSL è la scelta giusta e quando no

È la scelta giusta se vuoi un ambiente Linux vicino al mondo enterprise, compatibile con script e tool da server, rapido da ripristinare e facile da duplicare. È meno adatto se devi simulare un server completo con networking sofisticato, servizi persistenti complessi o componenti che dipendono fortemente dal kernel. In quel caso una VM o un host Linux dedicato restano più trasparenti.

La regola pratica è questa: WSL per sviluppo, test e operatività leggera; VM per isolamento e fedeltà infrastrutturale. Oracle Linux su WSL funziona bene proprio perché ti lascia lavorare con strumenti e convenzioni vicine al server, senza pagare il costo di una macchina virtuale piena quando non ti serve davvero.

Assunzione operativa: i comandi mostrati si riferiscono a una installazione WSL 2 aggiornata su Windows 10/11, con accesso amministrativo per l’abilitazione delle feature e con una rootfs Oracle Linux valida e verificata.