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 --statusSe 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 --installIl 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 -vQui vuoi vedere almeno una distro in versione 2. Se compare in versione 1, puoi convertirla con:
wsl --set-version NOME_DISTRO 2Per impostare WSL 2 come default sulle nuove installazioni:
wsl --set-default-version 2Questo è 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.tarSostituisci 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 AmazonLinux2Se 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-releaseIl 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 | headSe 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 makecacheSe 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.comSe 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.confIn 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 -ySe 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.
Commenti (0)
Nessun commento ancora.
Segnala contenuto
Elimina commento
Eliminare definitivamente questo commento?
L'azione non si può annullare.