1 19/10/2026 10 min

Per portare CloudReady, oggi basato su Chromium OS, dentro una macchina virtuale, il punto non è “farlo partire e basta”: bisogna allineare bene firmware, controller disco, rete e dimensione del supporto, altrimenti si finisce con schermate nere, boot loop o un sistema che parte ma non salva nulla in modo affidabile. In pratica, la VM deve imitare abbastanza bene un portatile UEFI moderno, senza però complicare inutilmente la configurazione.

Qui sotto trovi un percorso pulito per scaricare l’immagine, prepararla e installarla in una VM su Linux. Il flusso è pensato per VirtualBox e VMware come casi più comuni, ma i passaggi concettuali restano gli stessi anche su KVM/QEMU: firmware UEFI, disco virtuale capiente, rete NAT o bridged, e una conversione corretta dell’immagine se parti da un file destinato a chiavetta USB o da un formato compresso.

CloudReady e Chromium OS in VM: cosa aspettarsi davvero

CloudReady non è una distribuzione Linux classica. È un sistema orientato al browser, con forte dipendenza da avvio UEFI, partizioni specifiche e aggiornamenti gestiti in modo molto diverso da un desktop tradizionale. Dentro una VM questo si traduce in tre vincoli pratici: il firmware deve essere UEFI, il disco deve essere visto come un dispositivo stabile e la rete deve funzionare già al primo avvio, perché gran parte della configurazione dipende dal login online e dai servizi remoti.

Se stai cercando un ambiente per testare estensioni, policy di login, comportamento del browser o compatibilità con servizi web, la VM è sensata. Se invece vuoi un desktop generico con software Linux, CloudReady non è lo strumento giusto: è volutamente limitato. Questo va tenuto presente prima di investire tempo nella parte di installazione.

Scaricare l’immagine corretta senza confondere i formati

Il primo errore tipico è scaricare il file sbagliato: un’immagine pensata per USB, un archivio compresso, oppure un pacchetto destinato a un installer diverso. Il nome del file cambia nel tempo, quindi conviene sempre verificare sul sito ufficiale quale build sia ancora supportata e in quale formato venga distribuita. In generale, cerca un’immagine disco o un archivio che contenga già il sistema avviabile, non un ISO “generico” come quello delle normali distribuzioni Linux.

Una volta scaricato il file, controlla integrità e tipo. Su Linux puoi fare così:

file cloudready*.img.gz
sha256sum cloudready*.img.gz

Il primo comando ti dice se hai un archivio compresso o un’immagine già pronta; il secondo serve a confrontare l’hash pubblicato, quando disponibile. Se l’hash non è presente, almeno conserva il file originale e annota la versione. In ambiente tecnico la tracciabilità conta: se qualcosa non boota, sapere esattamente quale build hai usato ti evita mezz’ora di tentativi a vuoto.

Preparare la VM: UEFI, RAM, CPU e disco

La configurazione minima che funziona bene in laboratorio è semplice: 2 vCPU, 4 GB di RAM e un disco virtuale da almeno 16–32 GB. In pratica, 16 GB sono il minimo sindacale per test brevi; 32 GB danno più margine se vuoi aggiornare il sistema o installare più estensioni senza saturare lo spazio. Il controller disco deve essere stabile e non esotico: SATA in VirtualBox o SCSI/SATA in VMware sono scelte ragionevoli.

Il punto più importante è il firmware. Abilita UEFI e, se il hypervisor lo permette, disattiva il boot legacy. CloudReady tende a comportarsi meglio quando vede un ambiente coerente con il mondo ChromeOS/Chromium OS, cioè UEFI + disco GPT + rete pronta. Se la VM parte in modalità BIOS classica, spesso l’installer non prosegue oppure il sistema installato non torna su dopo il primo riavvio.

Per il disco, evita dimensioni troppo piccole e non usare thin provisioning aggressivo se il tuo host è già al limite di spazio. Una VM che si riempie durante l’installazione produce sintomi fuorvianti: boot incompleto, filesystem in sola lettura o riavvii improvvisi. Se il tuo storage host è ballerino, prima correggi quello.

Installazione su VirtualBox: impostazioni che contano

VirtualBox è spesso la scelta più rapida per una prova locale. Crea una nuova VM di tipo Linux/Other Linux a 64 bit, poi intervieni sulle impostazioni avanzate prima di avviarla:

  1. Abilita EFI nelle impostazioni di sistema.
  2. Assegna almeno 2048 MB, meglio 4096 MB se l’host lo consente.
  3. Imposta almeno 2 CPU se il sistema host è multicore.
  4. Usa un controller disco SATA e collega il disco virtuale lì.
  5. Collega la rete in NAT per il primo test, poi eventualmente passa a bridge.

Se parti da un’immagine compressa in formato .img.gz, prima decomprimila. Su Linux:

gunzip -k cloudready*.img.gz

Poi, se serve, convertila in formato VDI o VMDK. VirtualBox lavora bene con VDI, ma può anche usare VMDK. Se hai solo un raw disk image, puoi importarla così:

VBoxManage convertfromraw cloudready.img cloudready.vdi --format VDI

Se invece vuoi partire da un disco virtuale vuoto e scrivere l’immagine dentro, fai attenzione a non sovrascrivere il device sbagliato. In quel caso verifica sempre il nome del disco con lsblk prima di usare qualsiasi comando di scrittura. Non dare mai per scontato che il device sia quello che credi.

Installazione su VMware: differenze pratiche

Su VMware Workstation o Player il comportamento è simile, ma spesso l’emulazione UEFI è più lineare. Anche qui il disco deve essere semplice e la rete pronta. Se la VM non vede il boot media, controlla che non stia forzando un controller troppo particolare. In molti casi un disco virtuale standard e un CD/DVD virtuale collegato all’immagine bastano per arrivare al menu di avvio.

Se il tuo obiettivo è eseguire il sistema in modalità persistente, non fermarti al boot live: verifica che l’installer scriva correttamente sul disco virtuale. Alcune immagini per Chromium OS sono pensate per supporti rimovibili e richiedono passaggi aggiuntivi per la persistenza. Il sintomo classico è questo: il sistema parte, ma al riavvio torna allo stato iniziale o non conserva il login.

Boot iniziale: cosa controllare se la VM non parte

Se la VM resta nera, o si ferma su un prompt minimalista, la causa più probabile è quasi sempre una di queste: UEFI disattivato, immagine non corretta, disco non presentato nel formato atteso oppure boot order sbagliato. Prima di cambiare mille parametri, fai un controllo essenziale e ordinato.

  1. Verifica che la VM sia avviata in UEFI.
  2. Controlla che il file immagine sia davvero quello giusto con file.
  3. Assicurati che il disco virtuale sia collegato al controller corretto.
  4. Controlla che il boot order veda prima il disco o il supporto di installazione, in base alla fase.
  5. Se usi una ISO o immagine compressa, ricrea il supporto con un file pulito, non con una copia manipolata male.

Se la rete non è disponibile al primo avvio, non è necessariamente un guasto della VM, ma può diventare un blocco funzionale. CloudReady/Chromium OS tende a dipendere da servizi online già dalla fase iniziale. In NAT di solito si risolve subito; in bridge, invece, la rete host può introdurre complicazioni con DHCP, VLAN o policy aziendali.

Scrivere l’immagine su disco virtuale in modo sicuro

Se decidi di scrivere l’immagine raw direttamente su un disco virtuale o su un file destinato a essere montato come disco, la prudenza è obbligatoria. Il comando classico usa dd, ma va usato solo quando hai identificato con certezza il target. L’errore qui non è teorico: puoi sovrascrivere un disco host se sbagli device.

Flusso minimo:

lsblk -o NAME,SIZE,MODEL,TYPE,MOUNTPOINT
sudo dd if=cloudready.img of=/dev/sdX bs=4M status=progress conv=fsync

Il primo comando serve a identificare il device corretto; il secondo scrive l’immagine. Rischio: alto. Rollback: non esiste rollback del device fisico sovrascritto, quindi questo passaggio ha senso solo su un disco virtuale o su un file immagine dedicato. Se non sei sicuro, usa una VM con disco vuoto e importa l’immagine tramite gli strumenti del hypervisor, non con scritture dirette sul sistema host.

Primo avvio: account, lingua e controllo di persistenza

Quando il sistema parte correttamente, la procedura iniziale è in genere semplice: lingua, tastiera, rete, login con account supportato dal sistema e primo accesso al desktop. In questa fase controlla subito due cose: che la risoluzione video sia accettabile e che il profilo utente venga creato correttamente. Se dopo il riavvio perdi tutto, il problema non è il browser ma la persistenza del disco.

Un test utile è questo: installa una estensione del browser, imposta un parametro visibile e riavvia. Se al ritorno trovi tutto intatto, la VM è configurata bene. Se invece il sistema torna a uno stato iniziale, stai probabilmente usando un supporto live non persistente o un disco che non viene montato come expected.

Rete, DNS e accesso ai servizi Google

Molti problemi che sembrano “installazione fallita” sono in realtà problemi di rete. Se il login non procede, se il browser non sincronizza o se le pagine restano in timeout, verifica prima DNS e connettività. Dalla macchina host puoi fare un controllo veloce della rete della VM, ma il test più utile è sempre dentro il guest: aprire una pagina, vedere se risolve i nomi e se la data/ora sono corrette.

In ambienti con proxy o firewall restrittivi, CloudReady può comportarsi male perché si aspetta accesso a servizi esterni. Se sei in una rete aziendale, valuta NAT con uscita controllata o una VLAN di test. In caso di problemi di certificati o login, controlla anche l’orario della VM: un clock fuori sync rompe facilmente TLS e autenticazione.

Driver video e input: perché a volte il problema sembra grafico ma non lo è

Se l’interfaccia va a scatti, il mouse ha ritardo o lo schermo appare deformato, non partire subito con la caccia ai driver. Nelle VM spesso il collo di bottiglia è la combinazione tra accelerazione 3D, guest additions e impostazioni video del hypervisor. In molti casi basta disattivare o cambiare una singola opzione per rendere l’esperienza usabile.

Se il sistema mostra artefatti grafici, prova prima una configurazione più conservativa: meno memoria video, accelerazione disattivata e risoluzione standard. È una modifica reversibile e spesso risolve più di un tentativo di tuning aggressivo. La regola pratica è semplice: prima stabilità, poi prestazioni.

Quando conviene usare un disco separato invece di un’immagine sola

Per test seri conviene usare un disco virtuale separato e tenere l’immagine originale intatta. In questo modo puoi rifare la VM da zero senza riscaricare nulla, confrontare comportamenti tra build diverse e ripristinare rapidamente in caso di errore. È anche il modo migliore per evitare confusione tra file sorgente e supporto finale.

Una buona abitudine è nominare i file in modo esplicito, ad esempio cloudready-202x-xx-guest.img per l’immagine sorgente e cloudready-vm.vdi per il disco usato dalla VM. Sembra banale, ma in laboratorio riduce parecchio gli errori operativi.

Checklist finale prima di considerare la VM pronta

  1. UEFI abilitato e boot legacy disattivato.
  2. Disco virtuale presente, capiente e collegato al controller giusto.
  3. Rete funzionante in NAT o bridge, senza blocchi DNS.
  4. Orario della VM corretto.
  5. Persistenza verificata con un riavvio reale.
  6. Versione dell’immagine annotata e file sorgente conservato.

Se questi punti sono a posto, CloudReady/Chromium OS in VM è perfettamente utilizzabile come ambiente di test. Se uno solo di questi salta, il sintomo può essere ambiguo e farti perdere tempo su dettagli sbagliati. L’approccio giusto è quello da sysadmin: verifiche minime, modifica reversibile, poi solo dopo tuning o correzioni più invasive.

Assunzione operativa: la VM serve a test o laboratorio, non a sostituire un desktop Linux generico. Se l’obiettivo cambia, cambia anche la scelta del sistema.

Se vuoi automatizzare il provisioning, il passo successivo è creare una VM template con UEFI già pronto, disco vuoto già dimensionato e networking standardizzato. A quel punto la parte “scaricare e installare” si riduce a poche operazioni ripetibili, con meno variabili e meno errori manuali.