Partizione di sistema EFI

La partizione di sistema EFI (chiamata anche ESP) è una partizione indipendente dal sistema operativo che funge da luogo di memorizzazione per i bootloader EFI, le applicazioni e i driver da lanciare dal firmware UEFI. È obbligatorio per l’avvio UEFI.

Questo articolo o sezione è candidato a spostarsi in Unified Extensible Firmware Interface#UEFI drivers.

Note: I driver per i file system non-FAT sono fuori dallo scopo di questo articolo. (Discutere in Talk:EFI system partition#)

La specifica UEFI impone il supporto per i file system FAT12, FAT16 e FAT32 (vedere la specifica UEFI versione 2.8, sezione 13.3.1.1), ma ogni fornitore conforme può opzionalmente aggiungere il supporto per altri file system; per esempio, il firmware dei Mac Apple supporta il file system HFS+.

Verificare la presenza di una partizione esistente

Se stai installando Arch Linux su un computer con capacità UEFI con un sistema operativo installato, come Windows 10 per esempio, è molto probabile che tu abbia già una partizione di sistema EFI.

Per scoprire lo schema delle partizioni del disco e la partizione di sistema, utilizzare fdisk come root sul disco da cui si desidera avviare:

# fdisk -l /dev/sdx

Il comando restituisce:

La tabella delle partizioni del disco: indica Disklabel type: gpt se la tabella delle partizioni è GPT o Disklabel type: dos se è MBR.
L’elenco delle partizioni sul disco: Cercare la partizione di sistema EFI nella lista, di solito è almeno 100 MiB di dimensione e ha il tipo EFI System o EFI (FAT-12/16/32). Per confermare che questo è l’ESP, montatelo e controllate se contiene una directory chiamata EFI, se lo fa questo è sicuramente l’ESP.

Consiglio: Per scoprire se si tratta di un file system FAT12, FAT16 o FAT32, seguire FAT#Detecting FAT type.

Attenzione: Quando si fa il dual-boot, evitare di riformattare l’ESP, poiché potrebbe contenere file necessari per avviare altri sistemi operativi.

Se si è trovata una partizione di sistema EFI esistente, procedere semplicemente a #Monta la partizione. Se non ne hai trovata una, dovrai crearla, procedi a #Crea la partizione.

Crea la partizione

Le due sezioni seguenti mostrano come creare una partizione di sistema EFI (ESP).

Attenzione: La partizione di sistema EFI deve essere una partizione fisica nella tabella delle partizioni principale del disco, non sotto LVM o RAID software ecc.

Nota: Si raccomanda di usare GPT poiché alcuni firmware potrebbero non supportare l’avvio UEFI/MBR perché non è supportato da Windows Setup. Vedere anche Partizionamento#Scegliere tra GPT e MBR per i vantaggi di GPT in generale.

Per fornire uno spazio adeguato per memorizzare i boot loader e altri file necessari per l’avvio, e per prevenire problemi di interoperabilità con altri sistemi operativi, la partizione dovrebbe essere di almeno 260 MiB. Per le prime implementazioni UEFI e/o con buggy potrebbe essere necessaria una dimensione di almeno 512 MiB.

I dischi partizionati GPT

La partizione di sistema UEFI su una GUID Partition Table è identificata dal tipo di partizione GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B.

Scegliete uno dei seguenti metodi per creare un ESP per un disco partizionato GPT:

fdisk: Crea una partizione con tipo EFI System.
gdisk: Crea una partizione con tipo EF00.
GNU Parted: Crea una partizione con fat32 come tipo di file system e imposta il flag esp su di essa.

Procedi alla sezione #Formatta la partizione qui sotto.

I dischi partizionati MBR

La partizione di sistema EFI su una tabella di partizione Master Boot Record è identificata dall’ID del tipo di partizione EF.

Scegliete uno dei seguenti metodi per creare un ESP per un disco partizionato MBR:

fdisk: Crea una partizione primaria con tipo di partizione EFI (FAT-12/16/32).
GNU Parted: Crea una partizione primaria con fat32 come tipo di file system e imposta il flag esp su di essa.

Procedi alla sezione #Formattare la partizione qui sotto.

Formattare la partizione

La specifica UEFI prevede il supporto dei file system FAT12, FAT16 e FAT32. Per prevenire potenziali problemi con altri sistemi operativi e anche perché la specifica UEFI richiede solo il supporto di FAT16 e FAT12 su supporti rimovibili, si raccomanda di usare FAT32.

Dopo aver creato la partizione, formattala come FAT32. Per usare l’utilità mkfs.fat, installare dosfstools.

# mkfs.fat -F32 /dev/sdxY

Se si ottiene il messaggio WARNING: Not enough clusters for a 32 bit FAT!, ridurre la dimensione del cluster con mkfs.fat -s2 -F32 ... o -s1; altrimenti la partizione potrebbe non essere leggibile da UEFI. Vedere mkfs.fat(8) per le dimensioni dei cluster supportate.

Monta la partizione

I kernel, i file initramfs e, nella maggior parte dei casi, il microcodice del processore, devono essere accessibili dal boot loader o da UEFI stesso per avviare il sistema con successo. Quindi, se si vuole mantenere la configurazione semplice, la scelta del boot loader limita i punti di montaggio disponibili per la partizione di sistema EFI.

Punti di montaggio tipici

Gli scenari più semplici per montare la partizione di sistema EFI sono:

montare ESP su /efi e usare un boot loader che sia in grado di accedere ai kernel e alle immagini initramfs che sono memorizzati altrove (tipicamente /boot). Si veda Arch boot process#Boot loader per maggiori informazioni sui requisiti e le capacità del boot loader.
montare ESP su /boot. Questo è il metodo preferito quando si avvia direttamente un kernel EFISTUB da UEFI o lo si avvia tramite un boot manager come systemd-boot.
montare ESP su /efi e inoltre montare una “partizione di avvio estesa” (XBOOTLDR) su /boot. Questo può essere utile quando un ESP creato in precedenza è troppo piccolo per contenere più boot loader e/o kernel ma l’ESP non può essere facilmente ridimensionato (come quando si installa Linux dopo Windows per il dual boot). Questo metodo è supportato almeno da systemd-boot.

Suggerimento:

/efi è un rimpiazzo per il precedentemente popolare (e forse ancora usato da altre distribuzioni Linux) punto di montaggio ESP /boot/efi.
La directory /efi non è disponibile di default, sarà necessario crearla con mkdir(1) prima di montarvi l’ESP.

Punti di montaggio alternativi

Se non si usa uno dei metodi semplici di #Punti di montaggio tipici, sarà necessario copiare i file di avvio su ESP (di seguito esp).

# mkdir -p esp/EFI/arch# cp -a /boot/vmlinuz-linux esp/EFI/arch/# cp -a /boot/initramfs-linux.img esp/EFI/arch/# cp -a /boot/initramfs-linux-fallback.img esp/EFI/arch/

Nota: Potrebbe anche essere necessario copiare il microcodice nella posizione di avvio.

Inoltre, sarà necessario mantenere i file sull’ESP aggiornati con i successivi aggiornamenti del kernel. In caso contrario si potrebbe avere un sistema non avviabile. Le sezioni seguenti discutono diversi meccanismi per automatizzarlo.

Nota: Se l’ESP non è montato su /boot, assicuratevi di non fare affidamento sul meccanismo di automount di systemd (incluso quello di systemd-gpt-auto-generator(8)). Fatelo sempre montare manualmente prima di qualsiasi aggiornamento del sistema o del kernel, altrimenti potreste non essere in grado di montarlo dopo l’aggiornamento, bloccandovi nel kernel attualmente in esecuzione senza alcuna possibilità di aggiornare la copia del kernel su ESP.

In alternativa precaricate i moduli del kernel necessari all’avvio, ad es.:

/etc/modules-load.d/vfat.conf

vfatnls_cp437nls_ascii

Usando bind mount

Invece di montare l’ESP stesso su /boot, è possibile montare una directory dell’ESP su /boot usando un bind mount (vedere mount(8)). Questo permette a pacman di aggiornare direttamente il kernel mantenendo l’ESP organizzato a proprio piacimento.

Nota: Questo richiede un kernel e un bootloader compatibili con FAT32. Questo non è un problema per una normale installazione di Arch, ma potrebbe essere problematico per altre distribuzioni (in particolare quelle che richiedono symlink in /boot/). Vedere il post sul forum.

Proprio come in #Alternative mount points, copiare tutti i file di avvio in una directory sul vostro ESP, ma montare l’ESP al di fuori di /boot. Poi legare il montaggio della directory:

# mount --bind esp/EFI/arch /boot

Dopo aver verificato il successo, modificare il vostro Fstab per rendere le modifiche persistenti:

/etc/fstab

esp/EFI/arch /boot none defaults,bind 0 0

Usare systemd

Systemd dispone di compiti attivati da eventi. In questo caso particolare, la capacità di rilevare un cambiamento nel percorso viene utilizzata per sincronizzare i file EFISTUB del kernel e initramfs quando vengono aggiornati in /boot/. Il file osservato per i cambiamenti è initramfs-linux-fallback.img poiché questo è l’ultimo file costruito da mkinitcpio, per assicurarsi che tutti i file siano stati costruiti prima di iniziare la copia. Il percorso di systemd e i file di servizio da creare sono:

/etc/systemd/system/efistub-update.path

Description=Copy EFISTUB Kernel to EFI system partitionPathChanged=/boot/initramfs-linux-fallback.imgWantedBy=multi-user.targetWantedBy=system-update.target

/etc/systemd/system/efistub-update.service

Description=Copy EFISTUB Kernel to EFI system partitionType=oneshotExecStart=/usr/bin/cp -af /boot/vmlinuz-linux esp/EFI/arch/ExecStart=/usr/bin/cp -af /boot/initramfs-linux.img esp/EFI/arch/ExecStart=/usr/bin/cp -af /boot/initramfs-linux-fallback.img esp/EFI/arch/

Attiva quindi e avvia efistub-update.path.

Suggerimento: Per il Secure Boot con le proprie chiavi, è possibile impostare il servizio per firmare anche l’immagine utilizzando sbsigntools:

ExecStart=/usr/bin/sbsign --key /path/to/db.key --cert /path/to/db.crt --output esp/EFI/arch/vmlinuz-linux /boot/vmlinuz-linux

Utilizzando gli eventi del filesystem

Gli eventi del filesystem possono essere utilizzati per eseguire uno script che sincronizza il kernel EFISTUB dopo gli aggiornamenti del kernel. Segue un esempio con incron.

/usr/local/bin/efistub-update

#!/bin/shcp -af /boot/vmlinuz-linux esp/EFI/arch/cp -af /boot/initramfs-linux.img esp/EFI/arch/cp -af /boot/initramfs-linux-fallback.img esp/EFI/arch/

Nota: Il primo parametro /boot/initramfs-linux-fallback.img è il file da guardare. Il secondo parametro IN_CLOSE_WRITE è l’azione da osservare. Il terzo parametro /usr/local/bin/efistub-update è lo script da eseguire.

/etc/incron.d/efistub-update.conf

/boot/initramfs-linux-fallback.img IN_CLOSE_WRITE /usr/local/bin/efistub-update

Per utilizzare questo metodo, abilitare il incrond.service.

Usare l’hook mkinitcpio

Mkinitcpio può generare un hook che non ha bisogno di un demone a livello di sistema per funzionare. Esso genera un processo in background che attende la generazione di vmlinuzinitramfs-linux.img, e initramfs-linux-fallback.img prima di copiare i file.

Aggiungi efistub-update alla lista degli hook in /etc/mkinitcpio.conf.

/etc/initcpio/install/efistub-update

#!/usr/bin/env bashbuild() {/usr/local/bin/efistub-copy $ &}help() {cat <<HELPEOFTQuesto hook attende che mkinitcpio finisca e copi il ramdisk finito e il kernel nell'ESPHELPEOF}

/usr/local/bin/efistub-copia

#!/usr/bin/env bashif ]thenwhile dosleep .5donefirsync -a /boot/ esp/echo "Synced /boot with ESP"

Usando il preset mkinitcpio

Come i preset in /etc/mkinitcpio.d/ supportano lo scripting di shell, il kernel e initramfs possono essere copiati semplicemente modificando i preset.

Riposizionare l’hook mkinitcpio di cui sopra

Modificare il file /etc/mkinitcpio.d/linux.preset:

/etc/mkinitcpio.d/linux.preset

# mkinitcpio preset file per il pacchetto 'linux'# Directory per copiare il kernel, l'initramfs...ESP_DIR="''esp''/EFI/arch "ALL_config="/etc/mkinitcpio.conf "ALL_kver="${ESP_DIR}/vmlinuz-linux "cp -af /boot/vmlinuz-linux "${ESP_DIR}/"] && cp -af /boot/intel-ucode.img "${ESP_DIR}/"] && cp -af /boot/amd-ucode.img "${ESP_DIR}/"PRESETS=('default' 'fallback')#default_config="/etc/mkinitcpio.conf "default_image="${ESP_DIR}/initramfs-linux.img "default_options=""#fallback_config="/etc/mkinitcpio.conf "fallback_image="${ESP_DIR}/initramfs-linux-fallback.img "fallback_options="-S autodetect"

Per testarlo, basta eseguire:

# rm /boot/initramfs-linux-fallback.img# rm /boot/initramfs-linux.img# mkinitcpio -p linux

Un altro esempio

/etc/mkinitcpio.d/linux.preset

ESP_DIR="esp/EFI/arch "cp -f "/boot/vmlinuz-linux$suffix" "$ESP_DIR/"ALL_config="/etc/mkinitcpio.conf "ALL_kver="$ESP_DIR/vmlinuz-linux$suffix "PRESETS=('default')default_config="/etc/mkinitcpio.conf "default_image="$ESP_DIR/initramfs-linux$suffix.img"

/etc/mkinitcpio.d/linux-zen.preset

suffix='-zen'source /etc/mkinitcpio.d/linux.preset

Utilizzando gli hook di pacman

Un’ultima opzione si basa sugli hook di pacman che vengono eseguiti alla fine della transazione.

Il primo file è un hook che controlla i file rilevanti, e viene eseguito se sono stati modificati nella transazione precedente.

/etc/pacman.d/hooks/999-kernel-efi-copy.hook

Type = PathOperation = InstallOperation = UpgradeTarget = usr/lib/modules/*/vmlinuzTarget = usr/lib/initcpio/*Target = boot/*-ucode.imgDescription = Copia linux e initramfs nella directory EFI...When = PostTransactionExec = /usr/local/bin/kernel-efi-copy.sh

Il secondo file è lo script stesso. Creare il file e renderlo eseguibile:

/usr/local/bin/kernel-efi-copy.sh

#!/usr/bin/env bash## Copia le immagini del kernel e di initramfs nella directory EFI#ESP_DIR="esp/EFI/arch "for file in /boot/vmlinuz*do cp -af "$file" "$ESP_DIR/$(nome base "$file").efi" ] && exit 1donefor file in /boot/initramfs*do cp -af "$file" "$ESP_DIR/" ] && exit 1done] && cp -af /boot/intel-ucode.img "$ESP_DIR/"] && cp -af /boot/amd-ucode.img "$ESP_DIR/"exit 0

Risoluzione dei problemi

ESP su RAID1 software

È possibile rendere l’ESP parte di un array RAID1, ma ciò comporta il rischio di corruzione dei dati, e ulteriori considerazioni devono essere fatte durante la creazione dell’ESP. Vedere e per i dettagli e UEFI booting e RAID1 per una guida approfondita con una soluzione.

La parte fondamentale è usare --metadata 1.0 per mantenere i metadati RAID alla fine della partizione, altrimenti il firmware non sarà in grado di accedervi:

# mdadm --create --verbose --level=1 --metadata=1.0 --raid-devices=2 /dev/md/ESP /dev/sdaX /dev/sdbY

Il firmware non vede la directory EFI

Se si dà al file system un nome di volume (con l’opzione -n), assicurarsi di dargli un nome diverso da “EFI”. Questo può innescare un bug in alcuni firmware (dovuto al fatto che il nome del volume corrisponde al nome della directory EFI) che farà sì che il firmware si comporti come se la directory EFI non esistesse.

Vedi anche

La partizione di sistema EFI e il comportamento di avvio predefinito
Multi Boot Linux With One Boot Partition | John Ramsden