EFI system partition (Français)

État de la traduction:
Cet article est la version francophone de
EFI system partition
. Date de la dernière traduction: 2022-07-28. Vous pouvez aider à synchroniser la traduction s'il y a eu des
changements
dans la version anglaise.
Related articles
Unified Extensible Firmware Interface
Chargeur d'amorçage
L'
ESP
, pour
EFI system partition
en anglais, est une partition indépendante du système d'exploitation qui sert de lieu de stockage pour les chargeurs d'amorçage EFI, les applications et les pilotes à lancer par le microprogramme UEFI. Elle est obligatoire pour le démarrage UEFI.
Vérifier s'il y a une partition existante
Si vous installez Arch Linux sur un ordinateur avec UEFI et un système d'exploitation installé, comme par exemple
Windows
10, il est très probable que vous ayez déjà une partition système EFI.
Pour connaître le schéma de partition du disque et la partition système, utilisez
fdisk
en tant que root sur le disque à partir duquel vous voulez démarrer :
# fdisk -l /dev/sd
x
La commande renvoie :
La table de partition du disque : elle indique
Disklabel type : gpt
si la table de partition est
GPT
ou
Disklabel type : dos
si elle est
MBR
.
La liste des partitions sur le disque : Recherchez la partition système EFI dans la liste, elle fait généralement au moins 100 MiB et a le type
EFI System
ou
EFI (FAT-12/16/32)
. Pour confirmer qu'il s'agit bien de l'ESP, montez-la et vérifiez si elle contient un répertoire nommé
EFI
: si c'est le cas, il s'agit bien de l'ESP.
Astuce
Pour savoir s'il s'agit d'un système de fichiers FAT12, FAT16 ou FAT32, consultez
FAT#Detecting FAT type
.
Attention
Lors d'un
dual-boot
, évitez de reformater l'ESP, car il peut contenir des fichiers nécessaires au démarrage des autres systèmes d'exploitation.
Si vous avez trouvé une partition système EFI existante, passez simplement à
#Monter la partition
. Si vous n'en avez pas trouvé, vous devrez la créer, allez à
#Créer la partition
.
Créer la partition
Les deux sections suivantes montrent comment créer une partition système EFI (ESP).
Attention
La partition système EFI doit être une partition physique dans la table de partition principale du disque, pas sous LVM ni RAID logiciel etc...
La taille de la partition doit fournir un espace suffisant pour stocker les chargeurs d'amorçage et les autres fichiers nécessaires au démarrage.
Pour éviter les problèmes d'interopérabilité avec d'autres systèmes d'exploitation
[1]
[2]
, il est recommandé de lui allouer au moins 300 MiB. Pour les anciennes implémentations UEFI et/ou celles boguées, une taille d'au moins 512 MiB peut être nécessaire.
[3]
Si aucun de ces problèmes ne vous concerne, la taille de la partition peut être aussi petite que 2 MiB, auquel cas elle ne pourra rien contenir de plus qu'un chargeur d'amorçage.
Disques partitionnés en GPT
La partition système EFI sur une
Table de partition GUID
est identifiée par le
type de partition GUID
C12A7328-F81F-11D2-BA4B-00A0C93EC93B
.
Choisissez l'une des méthodes suivantes pour créer un ESP sur un disque partitionné GPT :
fdisk
: Créez une partition avec le type de partition
EFI System
.
gdisk
: Crée une partition avec le type de partition
EF00
.
GNU Parted
: Créez une partition avec
fat32
comme type de système de fichiers et activez l'indicateur
esp
sur celle-ci.
Après avoir créé la partition, elle doit être formatée avec un système de fichiers. Passez à la section
#Formater la partition
ci-dessous.
Disques partitionnés en MBR
Note
Il est recommandé d'utiliser
GPT
car certains firmwares peuvent ne pas prendre en charge le démarrage UEFI/MBR car il n'est pas pris en charge par
l'installateur de Windows
.
bootctl
ne prends pas en charge l'installation de
systemd-boot
sur un disque partitionné MBR ; voir
le ticket 1125 systemd
.
Voir également
Choisir entre GPT et MBR
pour les avantages de GPT en général.
La partition système EFI sur une table de partition
Master Boot Record
est identifiée par le
l'identifiant de type partition
EF
.
Choisissez l'une
des méthodes suivantes pour créer un ESP pour un disque partitionné MBR :
fdisk
: Créez une partition primaire avec le type de partition
EFI (FAT-12/16/32)
.
GNU Parted
: Crée une partition primaire avec
fat32
comme type de système de fichiers et active l'indicateur
esp
sur celle-ci.
Après avoir créé la partition, elle doit être formatée avec un système de fichiers. Passez à la section
#Formater la partition
ci-dessous.
Formater la partition
La spécification UEFI impose la prise en charge des systèmes de fichiers FAT12, FAT16 et FAT32 (voir
UEFI specification version 2.9, section 13.3.1.1
), mais tout fournisseur conforme peut ajouter facultativement la prise en charge de systèmes de fichiers supplémentaires ; par exemple, le microprogramme des
Macs
Apple prend en charge le système de fichiers HFS+.
Pour éviter les problèmes potentiels avec d'autres systèmes d'exploitation et puisque la spécification UEFI dit que l'UEFI "englobe l'utilisation de FAT32 pour une partition système, et FAT12 ou FAT16 pour les supports amovibles"
[4]
, il est recommandé d'utiliser
FAT32
. Utilisez l'utilitaire
mkfs.fat(8)
de
dosfstools
:
# mkfs.fat -F 32 /dev/sd
xY
Si vous obtenez le message
WARNING : Not enough clusters for a 32 bit FAT!
, réduisez la taille des clusters avec
mkfs.fat -s2 -F32 ...
ou
-s1
; sinon la partition peut être illisible par UEFI. Consultez
mkfs.fat(8)
pour les tailles de cluster prises en charge.
Pour les partitions inférieures à 32 MiB, l'utilisation de FAT32 peut ne pas être possible. Dans ce cas, formatez-la en FAT16 ou même en FAT12. Par exemple, un ESP de 2 MiB ne pourra prendre en charge que la FAT12 :
# mkfs.fat -F 12 /dev/sd
xY
Monter la partition
Les noyaux, les fichiers initramfs et dans la plupart des cas le
microcode
du processeur doivent être accessibles par le
chargeur d'amorçage
ou l'UEFI lui-même pour réussir à démarrer le système. Ainsi, si vous voulez garder la configuration simple, votre choix de chargeur d'amorçage limite les points de montage disponibles pour la partition système EFI.
Points de montage habituels
Les scénarios les plus simples pour monter une partition système EFI sont :
monter
ESP sur
/efi
et utiliser un
chargeur d'amorçage
capable d'accéder au(x) noyau(x) et aux image(s) initramfs qui sont stocké(s) ailleurs (habituellement
/boot
). Consulter
chargeur d'amorçage
pour plus d'informations sur les exigences et les capacités du chargeur d'amorçage.
monter
ESP vers
/boot
. C'est la méthode préférée pour démarrer directement un noyau
EFISTUB
depuis l'UEFI ou via un gestionnaire d'amorçage comme
systemd-boot
.
monter
ESP sur
/efi
et monter en plus une "partition de chargeur d'amorçage étendu" (XBOOTLDR) sur
/boot
. Cela peut être utile lorsqu'un ESP précédemment créé est trop petit pour contenir plusieurs chargeurs d'amorçage et/ou noyaux, mais que l'ESP ne peut pas être facilement redimensionné (comme lors de l'installation de Linux après Windows pour le
dual-boot
). Cette méthode est prise en charge par au moins
systemd-boot
.
Astuce
/efi
est un remplacement
[5]
pour le point de montage ESP
/boot/efi
précédemment populaire (et peut-être encore utilisé par d'autres distributions Linux).
Le répertoire
/efi
n'est pas disponible par défaut, vous devrez d'abord le créer avec
mkdir(1)
avant d'y monter l'ESP.
Points de montage alternatifs
Si vous n'utilisez pas l'une des méthodes simples de
#Points de montage habituels
, vous devrez copier vos fichiers de démarrage sur l'ESP (désigné ci-après par
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/
Note
Vous devrez peut-être aussi copier le
Microcode
à l'emplacement de l'entrée de démarrage.
En outre, vous devrez maintenir les fichiers sur l'ESP à jour avec les dernières mises à jour du noyau. Si vous ne le faites pas, vous risquez d'avoir un système non démarrable. Les sections suivantes abordent plusieurs mécanismes permettant de l'automatiser.
Note
Si l'ESP n'est pas monté sur
/boot
, veillez à ne pas vous fier au mécanisme de
montage automatique de systemd
(y compris celui de
systemd-gpt-auto-generator(8)
). Il faut toujours le monter manuellement avant toute mise à jour du système ou du noyau, sinon vous risquez de ne plus pouvoir le monter après la mise à jour, ce qui vous enfermera dans le noyau en cours d'exécution sans possibilité de mettre à jour la copie du noyau sur ESP.
Alternativement,
préchargez les modules du noyau requis au démarrage
, par exemple :
/etc/modules-load.d/vfat.conf
vfat
nls_cp437
nls_ascii
Avec un
bind
Au lieu de monter l'ESP lui-même sur
/boot
, vous pouvez monter un répertoire de l'ESP sur
/boot
en utilisant un
mount
lié (
bind
en anglais, voir
mount(8)
). Cela permet à
pacman
de mettre à jour le noyau directement tout en conservant l'ESP organisé à votre convenance.
Note
Ceci nécessite un
noyau
et un
chargeur d'amorçage
compatible avec FAT32. Ce n'est pas un problème pour une installation ordinaire d'Arch, mais cela peut être problématique pour d'autres distributions (notamment celles qui nécessitent des liens symboliques dans
/boot/
). Voir le post du forum
[6]
.
Comme dans
#Points de montage alternatifs
, copiez tous les fichiers de démarrage dans un répertoire sur votre ESP, mais montez l'ESP
en dehors
de
/boot
. Ensuite, montez le répertoire en le liant :
# mount --bind
esp
/EFI/arch /boot
Après avoir vérifié le succès, éditez votre
Fstab
pour rendre les changements persistants :
/etc/fstab
esp
/EFI/arch /boot none defaults,bind 0 0
Avec systemd
Systemd
permet d'effectuer des tâches déclenchées par des événements. Dans ce cas particulier, la capacité à détecter un changement dans un répertoire est utilisée pour synchroniser les fichiers du noyau EFISTUB et initramfs lorsqu'ils sont mis à jour dans
/boot/
. Le fichier surveillé pour les changements est
initramfs-linux-fallback.img
car c'est le dernier fichier construit par mkinitcpio, pour s'assurer que tous les fichiers ont été construits avant de commencer la copie. Le
chemin systemd
et les fichiers de service à créer sont :
/etc/systemd/system/efistub-update.path
[Unit]
Description=Copie le noyau EFISTUB sur la partition système EFI

[Path]
PathChanged=/boot/initramfs-linux-fallback.img

[Install]
WantedBy=multi-user.target
WantedBy=system-update.target
/etc/systemd/system/efistub-update.service
[Unit]
Description=Copie le noyau EFISTUB sur la partition système EFI

[Service]
Type=oneshot
ExecStart=/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/
Puis
activez
et
démarrez
efistub-update.path
.
Astuce
Pour
Secure Boot
avec vos propres clés, vous pouvez configurer le service pour qu'il signe également l'image en utilisant
sbsigntools
:
ExecStart=/usr/bin/sbsign --key
/path/to/db.key
--cert
/path/to/db.crt
--output
esp
/EFI/arch/vmlinuz-linux /boot/vmlinuz-linux
Avec les événements du système de fichiers
Les événements du système de fichiers
peuvent être utilisés pour exécuter un script synchronisant le noyau EFISTUB après les mises à jour du noyau. Ci-après un exemple avec
incron
.
/usr/local/bin/efistub-update
#!/bin/sh
cp -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/
Note
Le premier paramètre
/boot/initramfs-linux-fallback.img
est le fichier à surveiller. Le deuxième paramètre
IN_CLOSE_WRITE
est l'action à surveiller. Le troisième paramètre
/usr/local/bin/efistub-update
est le script à exécuter.
/etc/incron.d/efistub-update.conf
/boot/initramfs-linux-fallback.img IN_CLOSE_WRITE /usr/local/bin/efistub-update
Afin d'utiliser cette méthode,
activez
le
incrond.service
.
Avec un
hook
de mkinitcpio
Mkinitcpio
peut générer un
hook
qui n'a pas besoin d'un daemon au niveau du système pour fonctionner. Il génère un processus d'arrière-plan qui attend la génération de
vmlinuz
,
initramfs-linux.img
, et
initramfs-linux-fallback.img
avant de copier les fichiers.
Ajoutez
efistub-update
à la liste des hooks dans
/etc/mkinitcpio.conf
.
/etc/initcpio/install/efistub-update
#!/usr/bin/env bash
build() {
	/usr/local/bin/efistub-copy $$ &
}

help() {
	cat <<HELPEOF
Ce hook attend que mkinitcpio se termine et copie le ramdisk et le noyau terminés dans l'ESP.
HELPEOF
}
/usr/local/bin/efistub-copy
#!/bin/sh

if [ "$1" -gt 0 ]
alors
	while [ -e /proc/"$1" ]
	do
		sleep .5
	done
fi

rsync -a /boot/
esp
/

echo "/boot synchronisé avec l'ESP"
Avec un pré-réglage mkinitcpio
Comme les
presets
dans
/etc/mkinitcpio.d/
gèrent les scripts shell, le noyau et les initramfs peuvent être copiés en éditant simplement les pré-réglages.
Remplacer le
hook
mkinitcpio ci-dessus
Editez le fichier
/etc/mkinitcpio.d/linux.preset
:
/etc/mkinitcpio.d/linux.preset
# Fichier de pré-réglage mkinitcpio pour le paquet 'linux'.

# Répertoire pour copier le noyau, les initramfs...
ESP_DIR="
esp
/EFI/arch"

ALL_config="/etc/mkinitcpio.conf"
ALL_kver="${ESP_DIR}/vmlinuz-linux"
cp -af /boot/vmlinuz-linux "${ESP_DIR}/"
[[ -e /boot/intel-ucode.img ]] && cp -af /boot/intel-ucode.img "${ESP_DIR}/"
[[ -e /boot/amd-ucode.img ]] && 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"
Pour tester, il suffit de lancer :
# rm /boot/initramfs-linux-fallback.img /boot/initramfs-linux.img
# mkinitcpio -p linux
Un autre exemple
/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
suffixe='-zen'
source /etc/mkinitcpio.d/linux.preset
Avec un
hook
pacman
Une dernière option repose sur les
hooks de pacman
qui sont exécutés à la fin de la transaction.
Le premier fichier est un
hook
qui surveille les fichiers pertinents et est exécuté s'ils ont été modifiés lors de la transaction précédente.
/etc/pacman.d/hooks/999-kernel-efi-copy.hook
[Trigger]
Type = Path
Operation = Install
Operation = Upgrade
Target = usr/lib/modules/*/vmlinuz
Target = usr/lib/initcpio/*
Target = boot/*-ucode.img

[Action]
Description = Copier linux et initramfs dans le répertoire EFI...
When = PostTransaction
Exec = /usr/local/bin/kernel-efi-copy.sh
Le deuxième fichier est le script lui-même. Créez le fichier et rendez-le
exécutable
:
/usr/local/bin/kernel-efi-copy.sh
#!/bin/sh
#
# Copie les images du noyau et des initramfs dans le répertoire EFI
#

ESP_DIR="
esp
/EFI/arch"

for file in /boot/vmlinuz*
do
        cp -af "$file" "$ESP_DIR/$(basename '$file').efi"
        [ $ ? -ne 0 ] && exit 1
done

for file in /boot/initramfs*
do
        cp -af "$file" "$ESP_DIR/"
        [ $ ? -ne 0 ] && exit 1
done

[ -e /boot/intel-ucode.img ] && cp -af /boot/intel-ucode.img "$ESP_DIR/"
[ -e /boot/amd-ucode.img ] && cp -af /boot/amd-ucode.img "$ESP_DIR/"

exit 0
Dépannage
ESP sur RAID1 logiciel
Il est possible d'intégrer l'ESP à un RAID1, mais cela entraîne un risque de corruption des données et il faut prendre d'autres précautions lors de la création de l'ESP. Voir
[7]
et
[8]
pour plus de détails ainsi que
UEFI booting and RAID1
pour un guide détaillé avec une solution.
La partie la plus importante est d'utiliser
--metadata 1.0
afin de garder les métadonnées RAID à la fin de la partition, sinon le firmware ne sera pas capable d'y accéder :
# mdadm --create --verbose --level=1
--metadata=1.0
--raid-devices=2 /dev/md/ESP /dev/sda
X
/dev/sdb
Y
Le microprogramme ne voit pas le répertoire EFI
Si vous donnez au système de fichiers FAT un
nom de volume (i.e. un label de système de fichier)
, assurez-vous de le nommer autrement que
EFI
. Cela peut déclencher un bogue dans certains firmwares (dû au fait que le nom du volume correspond au nom du répertoire EFI) qui fera que le firmware agira comme si le répertoire EFI n'existait pas.
Voir aussi
La partition système EFI et le comportement de démarrage par défaut
Multi Boot Linux avec une partition de démarrage | John Ramsden
[
dead link
2023-10-29—HTTP 404]