UEFI o BIOS: come si avvia davvero la tua VPS

UEFI o BIOS su una VPS: chi sceglie il firmware

Su una VPS la scelta tra UEFI o BIOS la fa il provider, oppure la fai tu quando crei la macchina virtuale sull'hypervisor. Su KVM (Kernel-based Virtual Machine) le due opzioni tipiche sono SeaBIOS, un firmware BIOS classico, e OVMF, un'implementazione open source di UEFI. Per questo la domanda «quale è meglio» serve a poco. Le domande utili sono con quale firmware parte il tuo server e cosa cambia per partizioni e GRUB.

BIOS (Basic Input/Output System) è il firmware storico dei PC. UEFI (Unified Extensible Firmware Interface) è il suo successore. Su un PC fisico li vedi nel menu del firmware. Su una VPS il firmware è un componente dell'hypervisor, e di solito non lo vedi mai.

Questa guida parte da una situazione comune. Hai lanciato lsblk, hai trovato alcune partizioni piccole accanto a / e vuoi sapere se puoi eliminarle. Oppure GRUB ti ha dato un errore e vuoi capire perché. La risposta breve è questa. Prima scopri con quale firmware parte il server. Poi lascia comunque al suo posto /boot/efi.

Come capire se la VPS si avvia in UEFI o in BIOS

Il controllo più diffuso è una sola riga di shell:

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS

La riga controlla se esiste la cartella /sys/firmware/efi e stampa UEFI oppure BIOS. È il test che trovi in quasi tutte le guide. Trattalo come un primo indizio e confermalo con un secondo controllo. Eseguilo direttamente sul server, non dentro un container.

Il secondo controllo è efibootmgr, lo strumento che legge e scrive le voci di avvio salvate nella NVRAM (la memoria non volatile del firmware UEFI):

sudo apt install -y efibootmgr
sudo efibootmgr
echo $?

Su un avvio UEFI il comando stampa l'ordine di avvio e le voci registrate, e echo $? stampa 0. Su un avvio BIOS non ci sono variabili EFI da leggere. Il codice sorgente di efibootmgr prevede per questo caso un messaggio preciso e il codice di uscita 2:

EFI variables are not supported on this system.

Se i due controlli dicono la stessa cosa, sai su quale firmware sei. Se non concordano, non toccare il bootloader e chiedi al provider come è configurata la macchina.

Su Proxmox VE il firmware è un'impostazione della VM. La documentazione di Proxmox VE, consultata a ottobre 2026, dice che le VM QEMU usano SeaBIOS per impostazione predefinita e che OVMF è l'alternativa UEFI. Sugli host arm64 OVMF è l'unica opzione, perché SeaBIOS esiste solo per x86. Se stai decidendo tra una VM tua e un server in affitto, la guida sulle differenze tra una VM Proxmox e una VPS spiega cosa controlli tu e cosa controlla il provider.

Cosa sono le piccole partizioni accanto a /?

Questo comando mostra ogni partizione con dimensione, tipo e punti di montaggio:

lsblk -o NAME,SIZE,PARTTYPENAME,MOUNTPOINTS

La colonna PARTTYPENAME mostra il nome del tipo di partizione. La colonna MOUNTPOINTS mostra tutti i punti in cui il dispositivo è montato, anche più di uno, mentre MOUNTPOINT ne mostra solo uno. Se il tuo lsblk rifiuta una colonna, lsblk --help elenca quelle supportate dalla tua versione.

Un esempio pubblico aiuta a leggere il risultato. Nel bug Launchpad #2072929, aperto il 12 luglio 2024, un utente ha scritto l'immagine cloud di Ubuntu 24.04 (noble) su un disco da 10 GB con qemu-img. Il suo lsblk mostrava questo layout:

sda1     9G    /
sda14    4M
sda15  106M    /boot/efi
sda16  913M    /boot

Le partizioni sono numerate 1, poi da 14 a 16. Il bug parla proprio di questa numerazione: lo storage dell'utente, Dell PowerFlex, accetta al massimo 15 partizioni per volume, quindi la partizione 16 era un problema. Nel ramo di sviluppo attuale dello script che costruisce l'immagine, la partizione /boot da 1 GiB ha il numero 13. Il layout quindi è cambiato tra una versione e l'altra. Non dare per scontato che il tuo disco usi gli stessi numeri del 2024: guarda il tuo lsblk.

La partizione da 4M non ha un punto di montaggio, e il bug non dice di che tipo sia. Te lo dice la colonna PARTTYPENAME sul tuo server. Se vuoi il codice breve del tipo, installa gdisk e stampa la tabella delle partizioni. Sostituisci /dev/sda con il disco che vedi in lsblk:

sudo apt install -y gdisk
sudo sgdisk -p /dev/sda

La colonna Code mostra codici di quattro cifre. EF02 è la BIOS Boot Partition di GRUB. EF00 è la ESP (EFI System Partition), la partizione che legge il firmware UEFI.

Perché un'immagine Ubuntu ha sia la partizione BIOS boot sia la ESP

Lo script livecd-rootfs che costruisce le immagini cloud amd64 di Ubuntu crea una partizione 14 da 4 MiB con tipo EF02 e una partizione 15 con tipo EF00, formattata FAT32. L'immagine è costruita per contenere entrambi i percorsi di avvio, così lo stesso file può partire sotto un firmware BIOS oppure sotto un firmware UEFI. Ogni firmware usa la sua partizione e ignora l'altra.

Con un BIOS, GRUB lavora in due pezzi. Il primo si chiama boot.img e sta nel primo settore del disco. Il manuale di GRUB dice che il suo unico compito è leggere il primo settore di core.img e saltare lì. Il secondo pezzo, core.img, contiene i moduli che servono per raggiungere /boot/grub. Su un disco GPT (GUID Partition Table) avviato da BIOS, GRUB può mettere core.img in una partizione dedicata: la BIOS Boot Partition. Il manuale chiede che sia grande almeno 31 KiB e che abbia il tipo giusto, cioè EF02 in gdisk oppure il flag bios_grub in GNU Parted. Se vuoi capire perché GPT cambia le regole rispetto al vecchio schema, leggi la guida sulle differenze tra tabelle di partizione GPT e MBR.

Con UEFI il percorso è diverso. La specifica UEFI descrive la System Partition come una partizione normale che contiene cartelle, file di dati e immagini UEFI, cioè i file .EFI. Il firmware la trova guardando il GUID del tipo di partizione, e il formato previsto è FAT32. Per questo /boot/efi è una piccola partizione FAT32 e non ext4.

Quali pacchetti GRUB sono installati, e cosa cambia?

dpkg -l 'grub*'

Le righe che iniziano con ii sono pacchetti installati. Cerca soprattutto due nomi. grub-pc è la versione di GRUB per PC/BIOS, e la sua descrizione su Launchpad dice che installarlo indica che quel GRUB deve essere il bootloader attivo. grub-efi-amd64 è la versione EFI per amd64. Quello che trovi installato ti dice quale percorso di avvio il sistema mantiene aggiornato.

Il pacchetto conta perché grub-install scrive in posti diversi a seconda del target. Con il target BIOS, i386-pc, scrive boot.img all'inizio del disco e core.img nella BIOS Boot Partition. Con un target EFI scrive i file nella ESP e poi registra una voce di avvio nella NVRAM. Il manuale di GRUB dice che, se la ESP è montata in /boot/efi, non servono argomenti speciali. Altrimenti indichi la posizione con --efi-directory.

La pagina man di grub-install per noble indica i386-pc come target predefinito. Quel valore è scritto nel programma e non guarda come è partita la macchina. Per questo conviene sapere quale pacchetto hai e, in caso di dubbio, passare --target in modo esplicito.

Perché grub-install dice «EFI variables are not supported»?

Quando il target è EFI, grub-install chiama efibootmgr per registrare la voce di avvio nella NVRAM. Su una macchina avviata in BIOS quelle variabili non sono disponibili, quindi efibootmgr risponde con il messaggio che hai già visto:

EFI variables are not supported on this system.

Nel sorgente di GRUB, quando efibootmgr fallisce, grub-install si ferma con un errore che inizia con efibootmgr failed to register the boot entry:. Ubuntu applica patch proprie a GRUB, quindi leggi l'output reale sul tuo server prima di cercare il testo esatto. La causa resta la stessa: il target di grub-install non corrisponde al modo in cui la macchina è partita.

La soluzione è usare il target giusto. Controlla prima il nome del disco con lsblk e tieni aperta la console web del provider, perché un errore qui può lasciare la VPS senza avvio. Su una macchina avviata in BIOS:

sudo grub-install --target=i386-pc /dev/sda
sudo update-grub

Su una macchina avviata in UEFI, con la ESP montata in /boot/efi:

sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi
sudo update-grub

Esistono due opzioni valide solo per EFI che servono in casi particolari. --no-nvram scrive i file nella ESP senza toccare le variabili della NVRAM. --removable tratta il disco come un supporto rimovibile e installa GRUB nel percorso di riserva che il firmware cerca da solo.

Una partizione EFI è obbligatoria?

Dipende dal firmware. Con UEFI sì: la ESP è il posto in cui il firmware cerca i programmi di avvio, quindi senza ESP non parte niente. Con un BIOS e GRUB su un disco GPT, la ESP non serve, ma serve la BIOS Boot Partition. Questa è una conclusione che si ricava dalla specifica UEFI e dal manuale di GRUB. Non è una regola scritta da Canonical.

Posso cancellare /boot/efi?

Non farlo. Anche se la tua VPS oggi parte in BIOS, la ESP è piccola (106 MB nel layout del bug citato sopra), e cancellarla non ti dà niente di utile. Ti toglie invece la possibilità di avviare lo stesso disco sotto UEFI.

Pensa a cosa succede quando il disco cambia macchina. Una migrazione su un altro host, oppure un cambio da SeaBIOS a OVMF, porta il disco davanti a un firmware nuovo. Quel firmware non ha nella sua NVRAM nessuna voce per il tuo disco. La specifica UEFI dice che, quando la variabile BootOrder non esiste oppure nessuna voce funziona, il firmware usa il comportamento predefinito. Per un supporto rimovibile x64 quel comportamento cerca il file \EFI\BOOT\BOOTx64.EFI nella ESP. Senza la ESP quel percorso di riserva non esiste. Se prepari uno spostamento, la guida su come migrare un server su una nuova VPS copre il resto del lavoro.

Puoi vedere cosa contiene la tua ESP, e se è montata all'avvio, con questi comandi:

ls /boot/efi/EFI
ls /boot/efi/EFI/BOOT
findmnt /boot/efi
grep -i efi /etc/fstab

Se ls /boot/efi/EFI/BOOT risponde che la cartella non esiste, il tuo disco non ha il file di riserva, e un firmware nuovo dipende da una voce NVRAM che non ha. Se la ESP compare in /etc/fstab, il sistema prova a montarla a ogni avvio.

Perché cambiare firmware dopo l'installazione blocca l'avvio?

Ogni firmware cerca una cosa diversa. Un disco che ha solo la BIOS Boot Partition non ha niente da offrire a OVMF, perché OVMF cerca una ESP. Un disco che ha solo la ESP non ha niente da offrire a SeaBIOS, perché SeaBIOS legge il primo settore e cerca il codice di boot.img. Anche un disco che ha entrambe le partizioni parte sotto l'altro firmware solo se il percorso di quel firmware è stato installato e tenuto aggiornato.

Prima di cambiare, verifica sul tuo server quale pacchetto GRUB è installato e cosa contiene /boot/efi/EFI, compresa la cartella BOOT. Poi fai uno snapshot.

Su Proxmox VE c'è un dettaglio in più. Una VM con OVMF ha bisogno di un EFI Disk per salvare impostazioni come l'ordine di avvio. Proxmox ne permette uno solo per VM e lo include in backup e snapshot. La documentazione ricorda anche che alcuni sistemi operativi, come Windows 11, possono richiedere UEFI. Se passi una VM Linux esistente a OVMF, chiediti se la NVRAM del nuovo EFI Disk ha una voce per il tuo sistema. Se non ce l'ha, l'avvio dipende dal percorso di riserva nella ESP. Se invece la macchina non parte più dopo un aggiornamento, e non dopo un cambio di firmware, la causa di solito è altrove: parti dalla guida per una VPS che non si avvia dopo un aggiornamento del kernel.

Perché rinumerare le partizioni può bloccare GRUB in BIOS?

In BIOS, grub-install registra dentro boot.img la posizione del primo settore di core.img. Il manuale di GRUB lo descrive così: boot.img legge quel settore e salta lì. Quindi la catena di avvio BIOS contiene posizioni sul disco scritte al momento dell'installazione. Se dopo sposti o rinumeri le partizioni, quelle posizioni possono non corrispondere più al disco reale.

Tratta ogni cambio di layout come un caso da verificare. Dopo la modifica, e prima di riavviare, esegui di nuovo grub-install con il target i386-pc sul disco giusto, poi update-grub. Riavvia con la console del provider aperta. Se il menu di GRUB compare ma parte il kernel sbagliato, il problema è un altro, e la guida su come scegliere quale kernel avvia la VPS spiega come fissarlo.

E systemd-boot?

systemd-boot è un boot manager UEFI semplice, e la sua documentazione dice che supporta solo sistemi con firmware UEFI. Su una VPS avviata da SeaBIOS non è un'opzione. Le immagini Ubuntu di cui parla questa guida usano GRUB, e il resto della guida parla di GRUB.

FAQ

Come capisco se la mia VPS Ubuntu parte in UEFI o in BIOS?

Esegui [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS direttamente sul server. Poi conferma con sudo efibootmgr. Su un avvio UEFI stampa le voci di avvio. Su un avvio BIOS risponde EFI variables are not supported on this system. ed esce con codice 2. Se i due controlli non concordano, chiedi al provider come è configurata la macchina prima di toccare GRUB.

Posso cancellare la partizione /boot/efi della mia VPS?

È meglio di no, anche se oggi la VPS parte in BIOS. La ESP è piccola ed è l'unico modo per avviare lo stesso disco sotto UEFI. Quando il disco passa a un altro host o a un firmware OVMF, la NVRAM nuova non ha voci per il tuo sistema, e il firmware cerca un file di avvio di riserva proprio nella ESP. Controlla anche /etc/fstab, perché se /boot/efi è elencata lì il sistema prova a montarla a ogni avvio.

A cosa serve la partizione da 4 MB senza punto di montaggio?

Nelle immagini cloud amd64 di Ubuntu lo script di build crea una partizione da 4 MiB con tipo EF02, la BIOS Boot Partition. GRUB la usa quando la macchina parte da BIOS su un disco GPT, e ci mette core.img. Non ha un filesystem, quindi non ha un punto di montaggio. Verifica il tipo sul tuo disco con lsblk -o NAME,SIZE,PARTTYPENAME,MOUNTPOINTS oppure con sudo sgdisk -p /dev/sda.

Perché grub-install risponde «EFI variables are not supported»?

Perché stai usando un target EFI su una macchina avviata in BIOS. Con un target EFI, grub-install chiama efibootmgr per registrare la voce di avvio, e efibootmgr non trova variabili EFI da scrivere. Usa sudo grub-install --target=i386-pc /dev/sda se la macchina parte in BIOS, oppure sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi se parte in UEFI. Poi esegui sudo update-grub.