1 03/05/2026 10 min

Arch Linux si installa bene sia in VirtualBox sia su un PC reale, ma il punto non è “far partire l’installer”: è arrivare a un sistema pulito, ripetibile e facile da mantenere. Qui il flusso è quello corretto per evitare installazioni fragili: avvio della ISO, verifica rete, partizionamento consapevole, montaggio, base system, configurazione del bootloader, primo login e controlli finali. Se lavori in VirtualBox hai il vantaggio di un ambiente reversibile; su hardware fisico devi aggiungere attenzione a UEFI, dischi NVMe, firmware e schede di rete.

Prima decisione: VirtualBox o PC reale

Su VirtualBox la variabile principale è la semplicità: un disco virtuale, una NIC emulata, nessun rischio per i dati del host se il VM è isolato. Su PC reale la priorità cambia: verifica prima se il firmware è in modalità UEFI o legacy, se il disco è SATA o NVMe e se hai già un sistema operativo da preservare. Questa distinzione incide soprattutto su partizionamento e bootloader.

Se stai installando su macchina reale con dati già presenti, fermati prima di toccare le partizioni. Identifica il disco giusto con lsblk e blkid; non andare “a memoria” su /dev/sda o /dev/nvme0n1. In VirtualBox, invece, il disco è quasi sempre quello che hai creato tu e puoi permetterti test più aggressivi, purché il VM sia dedicato.

Scaricare la ISO e verificare l’integrità

Scarica la ISO ufficiale da Arch Linux e controlla checksum e firma quando possibile. Non è un formalismo: se la ISO è corrotta, i problemi emergono più tardi e diventano inutilmente ambigui. La verifica ti evita di inseguire bug che in realtà sono artefatti di download o storage difettoso.

Su Linux, dopo il download, il controllo minimo è questo:

sha256sum archlinux-*.iso

Confronta il digest con quello pubblicato sul sito ufficiale. Se vuoi fare le cose in modo più rigoroso, verifica anche la firma del file di checksum con i pacchetti GnuPG e le chiavi Arch, ma in pratica il checksum già intercetta gran parte degli errori operativi.

Avvio della live e tastiera corretta

All’avvio della live controlla subito layout tastiera, rete e modalità di boot. In una sessione italiana, se la tastiera non corrisponde, il rischio vero non è estetico: sbagli caratteri nei comandi, soprattutto su path, opzioni e password. Imposta il layout prima di fare altro.

loadkeys it

Verifica che il sistema sia partito in UEFI se vuoi installare in UEFI:

ls /sys/firmware/efi/efivars

Se la directory esiste, sei in UEFI. Se non esiste, sei in legacy BIOS o la VM è stata configurata male. In VirtualBox il dettaglio si corregge dalle impostazioni della macchina virtuale; su PC reale dipende dal firmware.

Rete: il prerequisito che molti danno per scontato

Arch non è utile offline durante l’installazione standard: ti servono mirror, pacchetti e spesso sincronizzazione oraria. In VirtualBox la rete NAT basta quasi sempre. Su PC reale, se DHCP non arriva, il problema sta spesso nella NIC non supportata, nel cavo, nel Wi-Fi o in un firmware che richiede driver aggiuntivi.

Controlla lo stato delle interfacce e la connettività reale, non solo la presenza del device:

ip link
ip addr
ping -c 3 archlinux.org

Se usi Wi-Fi in live, la via più pulita è con iwctl:

iwctl
station list
station wlan0 scan
station wlan0 get-networks
station wlan0 connect NOME_SSID
exit

Non saltare il controllo dell’ora. Arch si appoggia a repository firmati e una clock sballata può complicare TLS e validazione.

timedatectl set-ntp true
timedatectl status

Partizionamento: schema semplice, ma non improvvisato

Qui si decide la qualità dell’installazione. Per una macchina moderna in UEFI, lo schema più lineare è una EFI System Partition, una root e, opzionale, una swap. Se hai poco spazio o vuoi semplicità, puoi usare solo EFI e root, lasciando la swap a un file dopo il primo avvio. Su un PC reale con doppio boot, la partizione EFI può essere condivisa, ma va montata con attenzione e senza formattare quella già esistente se non è necessario.

Esempio con disco vuoto e UEFI:

cfdisk /dev/nvme0n1

Schema tipico:

  • EFI: 512 MiB, tipo EFI System
  • root: il resto del disco
  • swap: opzionale, in base a RAM e uso

Se preferisci fdisk, il principio non cambia. L’importante è essere coerenti tra tabella GPT e boot UEFI. In legacy BIOS puoi usare MBR, ma oggi ha senso solo se hai un vincolo preciso o hardware molto vecchio.

Formattazione e mount point

Una volta create le partizioni, formattale con filesystem standard e prevedibile. Per la root, ext4 resta la scelta più lineare se vuoi ridurre le variabili. Se hai un motivo concreto per usare btrfs o xfs, fallo con cognizione, non per moda.

mkfs.fat -F32 /dev/nvme0n1p1
mkfs.ext4 /dev/nvme0n1p2

Montaggio:

mount /dev/nvme0n1p2 /mnt
mkdir -p /mnt/boot
mount /dev/nvme0n1p1 /mnt/boot

Se usi una swap partition, attivala dopo il mount della root. Se invece vuoi un file swap più avanti, non è un problema: per l’installazione base puoi farne a meno.

Installazione della base system

Ora installi il sistema minimo e i pacchetti che ti servono davvero per partire. Non caricare mezza distribuzione subito: l’obiettivo è un root funzionante, aggiornabile e avviabile. Il comando base è quello che ti porta il necessario dentro /mnt.

pacstrap -K /mnt base linux linux-firmware vim networkmanager sudo

linux-firmware è utile quasi sempre, networkmanager semplifica la gestione della rete dopo il primo boot e sudo ti evita di lavorare come root oltre il necessario. Se sei su hardware particolare, valuta pacchetti aggiuntivi solo dopo aver identificato il device, non prima.

Generare fstab e preparare il chroot

La tabella dei mount deve essere coerente con quello che hai montato. Questo è uno di quei passaggi che sembrano banali ma, se sbagliati, ti lasciano un sistema che parte male o non parte proprio.

genfstab -U /mnt >> /mnt/etc/fstab
cat /mnt/etc/fstab

Il controllo con cat serve a verificare che UUID e mount point siano corretti. Poi entra nel nuovo sistema:

arch-chroot /mnt

Da qui in poi stai configurando il sistema installato, non più la live.

Timezone, locale e nome host

Configurazione minima ma essenziale. Il timezone corretto evita log confusi; il locale evita output incoerenti; l’hostname rende il sistema riconoscibile in rete e nei log.

ln -sf /usr/share/zoneinfo/Europe/Rome /etc/localtime
hwclock --systohc

Abilita il locale che ti serve in /etc/locale.gen, poi genera i locale:

nano /etc/locale.gen
locale-gen

Imposta la lingua di default in /etc/locale.conf:

LANG=it_IT.UTF-8

Hostname:

echo archbox > /etc/hostname

Password root, utente e privilegi minimi

Imposta subito la password di root e crea un utente normale con privilegi sudo. Non usare root per il lavoro quotidiano: è un’abitudine che complica audit, sicurezza e manutenzione.

passwd
useradd -m -G wheel -s /bin/bash mario
passwd mario
EDITOR=vim visudo

Nel file sudoers, abilita il gruppo wheel togliendo il commento alla riga corretta. Verifica con attenzione: un errore qui non rompe il sistema, ma ti lascia senza escalation comoda dopo il reboot.

Bootloader: systemd-boot o GRUB

In UEFI, systemd-boot è semplice e pulito se hai un singolo Linux o un setup essenziale. GRUB è più flessibile se prevedi multi-boot o casi più articolati. La scelta non è ideologica: dipende da ciò che devi avviare e da quanto vuoi semplificare la manutenzione.

Per systemd-boot:

bootctl install

Poi crea una entry, ad esempio in /boot/loader/entries/arch.conf:

title   Arch Linux
linux   /vmlinuz-linux
initrd  /initramfs-linux.img
options root=UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX rw

Recupera l’UUID con blkid. Se preferisci GRUB, l’installazione cambia ma il principio resta identico: devi dire al bootloader dove si trova la root e assicurarti che la partizione EFI sia montata correttamente.

Rete dopo il primo avvio

Se hai installato NetworkManager, abilitalo subito al primo boot. È il modo più semplice per non ritrovarti senza connettività dopo il riavvio, soprattutto in VirtualBox dove la rete può sembrare “ovvia” ma non lo è sempre.

systemctl enable NetworkManager
systemctl enable systemd-resolved

Se vuoi usare DNS gestito dal sistema, controlla il resolver attivo. In caso di problemi, i sintomi tipici sono ping per IP funzionante e risoluzione nomi assente. In quel caso la diagnosi non è “internet giù”, ma DNS locale o upstream.

Primo reboot e controlli essenziali

Dopo exit e lo smontaggio della root, riavvia. Se il sistema non parte, il problema è quasi sempre in uno di questi punti: partizione EFI non montata, bootloader non installato, entry errata, UUID sbagliato o modalità UEFI/legacy incoerente.

exit
umount -R /mnt
reboot

Una volta entrato nel sistema, verifica i punti minimi:

uname -r
ip a
systemctl status NetworkManager
lsblk -f

Se systemctl status NetworkManager mostra active (running), la rete base è correttamente sotto controllo. Se lsblk -f non mostra il filesystem atteso o la EFI non è montata come previsto, torna a correggere il boot e i mount point prima di aggiungere software.

VirtualBox: impostazioni che evitano problemi inutili

In VirtualBox conviene configurare bene il VM prima di partire: tipo Linux 64-bit, almeno 2 GB di RAM per un desktop minimale, 20 GB o più di disco e rete NAT se non hai esigenze particolari. Se vuoi testare servizi in ingresso, passa a bridge solo quando sai perché ti serve. Per l’installazione, l’ordine delle cose è più importante della quantità di risorse.

Se la VM non boota dalla ISO, controlla il controller ottico, l’ordine di boot e il fatto che la ISO sia effettivamente collegata al drive virtuale. È un errore banale ma frequente. Su PC reale l’equivalente è il menu di boot del firmware e la selezione del device giusto.

PC reale: dettagli che cambiano il risultato

Su hardware vero i problemi più comuni non sono Arch in sé, ma la piattaforma. Alcuni portatili richiedono impostazioni firmware specifiche per UEFI e Secure Boot; altri hanno controller storage o Wi-Fi che funzionano solo con firmware aggiornato. Se il disco è NVMe, i path cambiano ma il flusso no. Se hai un sistema preesistente, usa sempre lsblk, blkid e, se serve, il tool del firmware per capire cosa stai toccando.

Se vuoi mantenere un dual boot, la regola pratica è non formattare la partizione EFI esistente e non sovrascrivere entry di boot che non ti appartengono. Arch può convivere con altri sistemi, ma la convivenza richiede ordine: mount corretti, bootloader coerente e UUID controllati due volte.

Pacchetti successivi e manutenzione minima

Dopo l’installazione base, aggiungi solo ciò che sai di dover usare: ambiente grafico, driver video, strumenti di rete, editor, snapshot o servizi. La tentazione di installare tutto subito porta a sistemi più opachi e più difficili da debuggare. Arch rende bene quando lo costruisci a strati, non quando lo riempi a caso.

Prima di cambiare qualcosa di importante, conserva una traccia chiara: pacchetti installati, file modificati e motivo della modifica. In pratica, tieni sotto controllo /etc, il bootloader e l’elenco dei pacchetti con pacman -Qqe. È il modo più semplice per capire in seguito cosa hai aggiunto davvero e cosa puoi rimuovere senza effetti collaterali.

Checklist finale ragionata

Se vuoi una verifica rapida, controlla questi punti in ordine: ISO valida, rete attiva in live, disco identificato correttamente, partizioni coerenti con UEFI/BIOS, filesystem montati in /mnt, fstab corretto, chroot funzionante, locale e timezone impostati, bootloader installato, utente creato, NetworkManager abilitato. Se uno di questi manca, il sistema può anche avviarsi, ma non è ancora una base affidabile.

La differenza tra un’installazione che “sembra riuscita” e una che regge nel tempo sta nei controlli finali. Un Arch installato bene non è quello con più pacchetti, ma quello che puoi riavviare, aggiornare e recuperare senza dover rifare tutto da capo.