1 04/11/2026 9 min

Su Windows 10, installare CentOS 8 Stream su WSL non passa quasi mai da un percorso “ufficiale” e pulito come succede con Ubuntu o Debian. La strada corretta, in pratica, è creare una rootfs compatibile e importarla manualmente in WSL. Funziona, ma va capito bene un punto: WSL non è una VM completa, quindi alcune aspettative tipiche di un server Linux tradizionale non si applicano.

Se l’obiettivo è avere un ambiente CentOS per test, build, scripting o compatibilità con tool che si aspettano una base RHEL-like, WSL può andare bene. Se invece cerchi un sistema “da server” con systemd pienamente operativo, servizi persistenti e comportamento identico a una macchina bare metal, devi mettere in conto limiti strutturali. Su Windows 10, inoltre, la versione di WSL conta: WSL 1 e WSL 2 non si comportano allo stesso modo, e per CentOS 8 Stream conviene puntare a WSL 2 quando possibile.

Prerequisiti reali prima di partire

Prima di fare qualsiasi import, verifica tre cose: la build di Windows 10 deve supportare WSL 2, la virtualizzazione deve essere attiva nel firmware, e devi avere spazio disco sufficiente per la rootfs e gli aggiornamenti iniziali. Se una di queste condizioni manca, l’installazione si inceppa subito o parte in modo fragile.

Dal lato Windows, apri PowerShell come amministratore e controlla lo stato di WSL:

wsl --status
wsl --list --verbose

Se il comando wsl --status non è disponibile, probabilmente hai una build troppo vecchia oppure WSL non è installato correttamente. In quel caso, il percorso più rapido è aggiornare Windows 10 a una release recente e abilitare le funzionalità richieste.

Le funzionalità da attivare sono queste:

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

Dopo l’attivazione, riavvia il PC. Se stai lavorando su una macchina aziendale, considera anche eventuali policy che bloccano il componente Hyper-V o la virtualizzazione annidata: sono casi meno comuni, ma nei contesti gestiti capitano più spesso di quanto si pensi.

Perché CentOS 8 Stream non si installa “dal Microsoft Store”

Le distribuzioni disponibili nello Store sono quelle pubblicate e mantenute come pacchetti WSL pronti. CentOS 8 Stream, nella pratica, di solito richiede un import manuale della root filesystem. Questo non è un difetto di WSL: è semplicemente il modo in cui il supporto alla distribuzione viene distribuito. Il vantaggio è la flessibilità; lo svantaggio è che devi costruirti tu il pacchetto iniziale.

Qui la logica è semplice: ottieni una rootfs tar compatibile con Linux, la importi in una directory dedicata e poi entri nella distro con wsl.exe. Se la rootfs è troppo minimale o non coerente, dovrai sistemare repository, DNS e pacchetti base al primo avvio.

Scaricare una rootfs CentOS 8 Stream affidabile

Il punto delicato è la provenienza della root filesystem. Non inventarti tarball trovati a caso: meglio usare una fonte attendibile, preferibilmente un’immagine ufficiale o un archivio noto e verificabile. Se hai già un ambiente Linux, puoi anche costruire tu una rootfs minima con dnf o mock, ma per la maggior parte dei casi è più rapido partire da un archivio già pronto.

Una rootfs adatta a WSL deve contenere una base coerente di pacchetti, una shell funzionante e i file minimi per l’avvio. Se manca /etc/passwd, /etc/group o la struttura base di sistema, non è detto che WSL fallisca del tutto, ma il primo accesso sarà pieno di correzioni manuali.

Importare CentOS 8 Stream in WSL 2

La via più pulita è usare wsl --import. Ti serve una cartella di destinazione sul disco Windows e un file tar della rootfs. Ecco un esempio operativo, con una directory dedicata sotto C:\WSL\CentOS8Stream e un archivio chiamato centos8stream-rootfs.tar:

wsl --import CentOS8Stream C:\WSL\CentOS8Stream C:\Temp\centos8stream-rootfs.tar --version 2

Dopo l’import, verifica che la distribuzione sia registrata e in versione 2:

wsl --list --verbose

L’output atteso deve mostrare CentOS8Stream con VERSION 2. Se vedi version 1, vuol dire che il sistema non ha accettato il parametro o che la piattaforma WSL 2 non è realmente attiva. In quel caso, non forzare correzioni a valle: prima risolvi la base.

Primo avvio e configurazione iniziale dell’utente

Una volta importata, avvia la distro con:

wsl -d CentOS8Stream

Se entri come root, è normale nel caso di un’import manuale. Il passo successivo è creare un utente normale e assegnargli i privilegi sudo. Su CentOS, il pacchetto sudo potrebbe non essere presente in una rootfs minimale, quindi controlla prima lo stato dei pacchetti installati:

rpm -q sudo

Se il pacchetto manca, installalo dopo aver sistemato i repository. Se invece è presente, puoi procedere così:

useradd -m -G wheel admin
passwd admin

Per abilitare il gruppo wheel a usare sudo, modifica il file /etc/sudoers solo con visudo, non con un editor qualsiasi. La riga tipica è questa:

%wheel ALL=(ALL) ALL

È una modifica piccola, ma se la sbagli rischi di tagliarti fuori dall’uso amministrativo. Il rollback, in questo caso, è semplice: ripristinare il file originale o correggere la riga con visudo.

Repository, DNS e aggiornamenti iniziali

La prima anomalia tipica delle rootfs importate è il repository non funzionante. Su CentOS 8 Stream, la configurazione dei mirror e dei metadati può richiedere aggiustamenti, soprattutto se la base immagine è vecchia. Se dnf update fallisce, non partire subito da ipotesi strane: controlla prima se il problema è DNS o repository.

Un test minimo è questo:

cat /etc/resolv.conf
ping -c 1 mirrors.centos.org
curl -I https://mirror.stream.centos.org

Se il DNS interno di WSL non risolve bene, puoi impostare manualmente un resolver valido. Il file da controllare è /etc/resolv.conf. In alcune configurazioni WSL lo rigenera automaticamente, quindi la modifica potrebbe non essere persistente se non disattivi la generazione automatica lato Windows. Prima di farlo, però, verifica che il problema sia davvero il DNS e non un repository obsoleto.

Se la rete funziona ma dnf restituisce errori sui mirror, controlla i file in /etc/yum.repos.d/. Un repository inattivo o un mirrorlist non più valido è una causa molto più probabile di un errore “misterioso” della piattaforma WSL.

Abilitare systemd: cosa aspettarsi davvero

Qui serve chiarezza: su molte installazioni WSL di Windows 10, systemd non è disponibile nello stesso modo di una installazione Linux tradizionale. Se il tuo obiettivo è gestire servizi con systemctl, devi verificare se la build di WSL lo supporta davvero. Altrimenti, alcuni servizi andranno avviati manualmente o tramite workaround specifici della distribuzione.

Il test più semplice è:

ps -p 1 -o comm=

Se PID 1 non è systemd, non aspettarti il comportamento classico di un host CentOS. In questo caso, la soluzione non è forzare servizi che dipendono da systemd, ma adattare il workflow: shell, toolchain, test applicativi, compilazione e task batch restano il caso d’uso migliore.

Configurare l’integrazione con Windows

Uno dei vantaggi di WSL è l’integrazione con il filesystem Windows e con gli strumenti lato host. Però va usata con criterio: lavorare intensamente dentro /mnt/c può rallentare operazioni di I/O rispetto al filesystem Linux nativo della distro. Per progetti con molte letture e scritture, conviene tenere i sorgenti nella home Linux della distro e usare Windows solo per il trasferimento o l’accesso occasionale.

Se devi aprire un progetto da Windows, puoi usare i percorsi WSL con la sintassi condivisa, ma evita di montare tutto il lavoro su filesystem NTFS se il carico è pesante. La differenza si sente su build grandi, test con molti file e archivi che vengono espansi di frequente.

Problemi tipici e come riconoscerli in fretta

Il primo problema classico è l’avvio che fallisce subito dopo l’import. In quel caso, la verifica da fare è banale: controlla se la rootfs contiene davvero una struttura Linux completa e se il tar non è corrotto. Un controllo veloce sul file tar, lato Windows o Linux, evita di perdere tempo su WSL quando il problema è il pacchetto di partenza.

Il secondo problema è il networking intermittente. Se dentro WSL riesci a fare ping ma non hai accesso affidabile ai repository, guarda prima il DNS e poi eventuali proxy aziendali. In ambienti corporate, il blocco non è quasi mai WSL in sé: più spesso è la combinazione di proxy, filtro DNS e policy di sicurezza del browser o del sistema host.

Il terzo problema è la percezione che CentOS “non tenga” gli aggiornamenti o che i servizi non partano. Qui bisogna distinguere: se stai usando una rootfs minimale e non hai configurato correttamente utente, sudo, repository e init, il comportamento è coerente con una base incompleta, non con un difetto di WSL.

Procedura consigliata, condensata in passi operativi

  1. Abilita WSL e Virtual Machine Platform su Windows 10, poi riavvia.
  2. Verifica con wsl --status e wsl --list --verbose che la piattaforma sia pronta.
  3. Recupera una rootfs affidabile di CentOS 8 Stream in formato tar.
  4. Importa la distro con wsl --import specificando la versione 2.
  5. Avvia la distro, crea un utente normale e configura sudo se serve.
  6. Controlla DNS, repository e aggiornamenti con dnf.
  7. Decidi se il tuo caso d’uso richiede davvero systemd o se basta un ambiente shell/tooling.

Questa sequenza evita il classico errore di partire dal pacchetto applicativo senza aver verificato la base. In WSL, soprattutto con distribuzioni non standard, il 70% dei problemi iniziali nasce da import errato, rootfs incompleta o aspettative sbagliate sul comportamento del sistema.

Quando conviene cambiare strada

Se ti serve un ambiente CentOS per sviluppo leggero, scripting, test di compatibilità o uso occasionale, WSL va bene. Se invece vuoi un host da amministrare come un server Linux classico, con servizi persistenti, journald, systemd pieno e networking più prevedibile, una macchina virtuale vera è spesso la scelta più sensata. Non è una bocciatura di WSL: è semplicemente la differenza tra un layer di compatibilità e un sistema completo.

In altre parole, CentOS 8 Stream su WSL è utile quando il tuo obiettivo è lavorare velocemente senza aprire una VM pesante. È meno adatto quando vuoi riprodurre fedelmente un server Linux di produzione. Il criterio giusto non è “si può fare?”, ma “si può fare senza introdurre più attrito di quello che ti fa risparmiare?”.

Verifiche finali da fare subito dopo l’installazione

  • Versione WSL: la distro deve risultare in versione 2 con wsl --list --verbose.
  • Shell funzionante: l’accesso alla distro deve aprire una prompt Linux senza errori di bootstrap.
  • Rete: curl -I verso un repository o un sito noto deve restituire una risposta valida.
  • Pacchetti base: dnf deve poter leggere i repository configurati e fare update senza errori di DNS o mirror.
  • Persistenza utente: il login con l’utente creato deve funzionare dopo il riavvio di WSL.

Se uno di questi punti fallisce, non partire subito con workaround invasivi. Isola prima il layer: import, rete, repository o permessi. È il modo più veloce per evitare di trasformare un problema semplice in una configurazione ingestibile.