1 16/04/2026 9 min

Se l’obiettivo è avere Amazon Linux 2 dentro WSL su Windows 10 o 11, conviene partire da un punto scomodo ma importante: Amazon Linux 2 non è distribuita come immagine WSL ufficiale. Quindi non stai installando un pacchetto supportato con un click; stai costruendo un ambiente compatibile, oppure stai scegliendo un’alternativa più pulita per ottenere lo stesso risultato operativo.

In pratica hai tre strade: importare un rootfs di Amazon Linux 2 in WSL, usare una base compatibile con il runtime di Amazon Linux 2, oppure rinunciare a WSL e usare un contenitore o una VM quando ti serve fedeltà massima. La scelta cambia parecchio in termini di manutenzione, integrazione con Windows e rischio di incastrarsi su dettagli inutili.

Quando ha senso farlo davvero

Ha senso se devi validare script, toolchain o pipeline che devono girare su un sistema d’impronta RHEL-like e vuoi farlo da workstation Windows. Ha meno senso se cerchi un ambiente di produzione o se ti serve il comportamento completo del kernel Amazon Linux, perché WSL resta un layer di compatibilità e non una VM tradizionale.

Se l’obiettivo è sviluppare, testare pacchetti, verificare dipendenze o fare troubleshooting di script bash, WSL basta. Se invece vuoi testare systemd, moduli kernel, networking avanzato o comportamenti strettamente legati al boot di una macchina EC2, conviene spostarsi su una VM o su un’istanza Linux vera.

Prima distinzione: WSL 1 o WSL 2

Per questo scenario usa WSL 2. WSL 1 traduce chiamate di sistema e introduce più limiti; WSL 2 usa un kernel Linux reale dentro una VM leggera, quindi è la base giusta per un ambiente tipo Amazon Linux. Su Windows 11 è quasi sempre la scelta naturale, su Windows 10 dipende dalla build ma oggi è normalmente disponibile.

Verifica prima lo stato di WSL e le distro installate:

wsl --status

Se il comando non è disponibile, o se WSL non è attivo, devi prima abilitare le funzionalità di Windows e riavviare.

Installazione base di WSL 2 su Windows 10 e 11

Su Windows 11 il percorso è quasi banale. Su Windows 10 recente puoi usare lo stesso flusso, ma se la macchina è vecchia conviene controllare la build. Il passaggio minimo è questo:

wsl --install

Il comando abilita i componenti necessari e installa una distro predefinita. Non è ancora Amazon Linux 2, ma ti mette in condizioni di lavorare. Dopo il riavvio, controlla le distro:

wsl -l -v

Qui vuoi vedere almeno una distro in versione 2. Se compare in versione 1, puoi convertirla con:

wsl --set-version NOME_DISTRO 2

Per impostare WSL 2 come default sulle nuove installazioni:

wsl --set-default-version 2

Questo è il prerequisito di base. Da qui in poi puoi decidere se puntare a un import manuale o a una soluzione più pragmatica.

Perché Amazon Linux 2 non si installa “come Ubuntu”

Le distro WSL classiche arrivano dal Microsoft Store o tramite distribuzione ufficiale con rootfs pronto. Amazon Linux 2, invece, è pensato soprattutto per il mondo AWS e non viene normalmente pubblicato come pacchetto WSL pronto all’uso. Il risultato è semplice: non esiste un percorso standard unico, e chi prova a trattarlo come se fosse Ubuntu perde tempo.

Il punto tecnico è il root filesystem. WSL può importare una rootfs tarball e usarla come sistema Linux. Quindi il problema non è “WSL non supporta Amazon Linux 2”, ma “devi procurarti una rootfs compatibile e sapere cosa aspettarti da quel sistema una volta importato”.

Strada pratica: importare una rootfs di Amazon Linux 2

Questa è la strada più vicina al risultato richiesto. Ti serve un archivio tar della rootfs di Amazon Linux 2, da una fonte affidabile e coerente con l’architettura che vuoi usare. Se stai lavorando su PC x86_64, usa una rootfs x86_64. Se la rootfs non è corretta, il problema emerge subito all’avvio con errori di incompatibilità o binari mancanti.

Il comando WSL di import è questo:

wsl --import AmazonLinux2 C:
	o
ootfs C:
	o
ootfs
ootfs.tar

Sostituisci i percorsi con una directory reale su Windows. La directory di destinazione diventerà il contenitore della distro. Dopo l’import, avvia la distro con:

wsl -d AmazonLinux2

Se tutto è andato bene, ti troverai dentro una shell Amazon Linux 2 o comunque in un ambiente molto vicino a quella base. Il primo controllo è banale ma essenziale:

cat /etc/system-release

Il risultato atteso è una stringa coerente con Amazon Linux 2. Se non c’è, hai importato un rootfs diverso o incompleto.

Bootstrap minimo dopo il primo avvio

Una volta entrato nella shell, il primo obiettivo è capire se hai un sistema davvero utilizzabile o un ambiente troppo scarno. Controlla identità del sistema, rete e pacchetti:

uname -a
cat /etc/os-release
ip addr
rpm -qa | head

Se il comando rpm non è presente, la rootfs è troppo minimale o incompleta. Se ip non mostra interfacce, il problema è più lato WSL che lato distro.

Su Amazon Linux 2 il gestore pacchetti è yum. Verifica che sia operativo e aggiorna il metadata locale:

sudo yum clean all
sudo yum makecache

Se questi comandi falliscono, il punto non è WSL: di solito hai un problema di repository, DNS o rootfs incompleta.

Rete, DNS e differenze rispetto a una VM

WSL 2 usa una rete virtualizzata con NAT. Va bene per navigare, scaricare pacchetti e fare test HTTP/S, ma non va trattato come una macchina in LAN con IP stabile. Questo dettaglio pesa quando testi servizi in ascolto o quando vuoi raggiungere la distro da altre macchine.

Se devi fare troubleshooting di connettività, distingui sempre tra host Windows e guest WSL. Un test utile è questo:

curl -I https://www.amazon.com

Se fallisce, controlla prima il DNS del sistema Windows, poi la configurazione di rete WSL. Non ha senso inseguire Amazon Linux 2 se l’host non risolve correttamente i nomi.

Per vedere come WSL ha configurato la rete, puoi leggere:

cat /etc/resolv.conf

In molti casi il file viene generato automaticamente. Se lo modifichi a mano, sappi che WSL può sovrascriverlo. Quindi prima osserva, poi intervieni solo se hai un motivo preciso.

Systemd, servizi e limiti operativi

Una delle sorprese più frequenti è aspettarsi che WSL si comporti come una distribuzione completa con init classico. Su Amazon Linux 2 il mondo dei servizi è importante, ma in WSL devi verificare se la tua build supporta systemd e se la distro importata è coerente con quel modello. In caso contrario, molti servizi non partono come ti aspetteresti su una macchina EC2.

Controlla lo stato di systemd con:

ps -p 1 -o comm=

Se PID 1 non è systemd, non assumere che systemctl funzioni nel modo classico. In quel caso conviene usare approcci compatibili con WSL oppure passare a una VM se ti serve un init completo.

Per servizi semplici e test locali, spesso basta avviare direttamente il processo in foreground. Per test più realistici, meglio una VM o un’istanza dedicata.

Aggiornamento pacchetti e manutenzione

Una volta che la distro è viva, aggiornala subito. Non ha senso lasciare una rootfs vecchia, soprattutto se l’hai scaricata da un archivio fermo nel tempo. L’obiettivo minimo è ridurre il divario tra stato iniziale e stato atteso:

sudo yum update -y

Se lavori in modo ripetibile, annota la versione della rootfs, la data di import e i repository usati. Senza questi dati, fra tre settimane non saprai più se un comportamento dipende da WSL, dalla distro o da un update parziale.

Per controllare lo spazio usato dall’istanza WSL sul lato Windows, guarda la directory di installazione e tieni d’occhio la crescita del file VHDX. È un dettaglio che molti ignorano finché non esauriscono disco sulla workstation.

Integrazione con Windows: filesystem, editor e scambio file

Il vantaggio vero di WSL è l’integrazione con Windows. Puoi lavorare sui file in /mnt/c, aprire i file con il tuo editor Windows e lanciare test nella shell Linux. Però non è tutto equivalente: lavorare intensamente su filesystem montati da Windows è spesso meno performante che operare nel filesystem Linux della distro.

Regola pratica: codice e toolchain nel filesystem Linux della distro, documenti e file condivisi dove serve. Se compili o fai I/O pesante su /mnt/c, la latenza può salire in modo visibile.

Un controllo utile è misurare il tempo di un’operazione semplice in due posizioni diverse, ad esempio copia di file o unpack di un archivio. Se il gap è evidente, hai trovato il collo di bottiglia senza dover ipotizzare altro.

Alternative sensate se vuoi meno attrito

Se l’obiettivo è solo avere un ambiente Amazon Linux-like, spesso la soluzione più pulita è usare una distro compatibile in WSL e allineare i pacchetti necessari. Se invece ti serve Amazon Linux 2 per motivi di compatibilità stretta, allora una VM Hyper-V o VirtualBox è più onesta: hai boot completo, init completo e meno ambiguità.

Un’altra opzione è Docker, ma solo se ti serve un userland Linux per build o test e non un sistema operativo completo. Docker non sostituisce una distro WSL; risolve un problema diverso.

Errori tipici e come riconoscerli

Se la distro non parte, il primo sospetto è una rootfs sbagliata o corrotta. Se parte ma non risolve i nomi, guarda DNS e /etc/resolv.conf. Se i pacchetti non si aggiornano, controlla repository e connettività. Se i servizi non si comportano come atteso, verifica init/systemd e non dare per scontato il comportamento di una VM classica.

Un errore frequente è importare una rootfs ottenuta da fonti non controllate. È una pessima idea sia per affidabilità sia per sicurezza. Se devi distribuire questo setup in team, conserva la sorgente del rootfs, i checksum e la procedura di import. Non salvare segreti in file di testo dentro la distro; usa meccanismi di secret management o variabili temporanee, e ruota tutto ciò che è stato esposto per errore.

Procedura consigliata in pratica

Se vuoi farlo con il minor numero di sorprese, usa questa sequenza:

  • Abilita WSL 2 e verifica che sia attivo con wsl --status e wsl -l -v.

  • Recupera una rootfs affidabile di Amazon Linux 2 per l’architettura corretta.

  • Importa la rootfs con wsl --import in una directory dedicata.

  • Avvia la distro con wsl -d AmazonLinux2 e valida /etc/system-release.

  • Verifica rete, DNS e aggiornamenti con curl e yum.

  • Decidi subito se ti basta un userland compatibile o se ti serve una VM vera.

  • Decisione finale: cosa aspettarsi dal setup

    La risposta concreta è questa: Amazon Linux 2 su WSL si può ottenere, ma non come installazione ufficiale standardizzata. Se accetti il lavoro di import e il fatto che WSL non è una macchina EC2, hai un ambiente utile per sviluppo, test di script e verifica di compatibilità. Se invece vuoi fedeltà totale, stai chiedendo al tool sbagliato.

    La regola che evita tempo perso è semplice: usa WSL per velocità e comodità, usa una VM per fedeltà, usa una macchina reale per validare il comportamento finale. Se tieni distinti questi tre livelli, l’installazione di Amazon Linux 2 su Windows 10 e 11 smette di essere un esercizio di pazienza e diventa uno strumento pratico.