EFI system partition (Français)

From ArchWiki
É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

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/sdx

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:

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/sdxY

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/sdxY

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/sdaX /dev/sdbY

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