Partition système EFI

La partition système EFI (également appelée ESP) est une partition indépendante du système d’exploitation qui sert de lieu de stockage pour les chargeurs de démarrage EFI, les applications et les pilotes à lancer par le micrologiciel UEFI. Elle est obligatoire pour le démarrage UEFI.

Cet article ou cette section est candidat au déplacement vers Unified Extensible Firmware Interface#UEFI drivers.

Notes : Les pilotes pour les systèmes de fichiers non-FAT sont hors de portée de cet article. (Discutez-en dans Talk:EFI system partition#)

La spécification UEFI rend obligatoire la prise en charge des systèmes de fichiers FAT12, FAT16 et FAT32 (voir la spécification UEFI version 2.8, section 13.3.1.1), mais tout fournisseur conforme peut éventuellement ajouter la prise en charge de systèmes de fichiers supplémentaires ; par exemple, le micrologiciel des Macs d’Apple prend en charge le système de fichiers HFS+.

Vérifier la présence d’une partition existante

Si vous installez Arch Linux sur un ordinateur compatible UEFI avec un système d’exploitation installé, comme Windows 10 par exemple, 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-le et vérifiez s’il contient un répertoire nommé EFI, si c’est le cas, il s’agit bien de l’ESP.

Conseil : Pour savoir s’il s’agit d’un système de fichiers FAT12, FAT16 ou FAT32, suivez FAT#Detecting FAT type.

Avertissement : Lors du double démarrage, évitez de reformater l’ESP, car il peut contenir des fichiers nécessaires au démarrage d’autres systèmes d’exploitation.

Si vous avez trouvé une partition système EFI existante, procédez simplement à #Mount the partition. Si vous n’en avez pas trouvé, vous devrez la créer, procédez à #Créer la partition.

Créer la partition

Les deux sections suivantes montrent comment créer une partition système EFI (ESP).

Avertissement : La partition système EFI doit être une partition physique dans la table de partition principale du disque, pas sous LVM ou RAID logiciel etc.

Note : Il est recommandé d’utiliser GPT car certains firmwares pourraient ne pas supporter le démarrage UEFI/MBR en raison de sa non prise en charge par Windows Setup. Voir également Partitionnement#Choisir entre GPT et MBR pour les avantages de GPT en général.

Pour fournir un espace adéquat pour le stockage des chargeurs de démarrage et d’autres fichiers nécessaires au démarrage, et pour éviter les problèmes d’interopérabilité avec d’autres systèmes d’exploitation, la partition doit être d’au moins 260 MiB. Pour les implémentations UEFI précoces et/ou boguées, la taille d’au moins 512 MiB pourrait être nécessaire.

Disques partitionnés GPT

La partition système UEFI 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 pour un disque partitionné GPT :

fdisk : Créer une partition avec le type de partition EFI System.
gdisk : Créer une partition avec le type de partition EF00.
GNU Parted : Créer une partition avec fat32 comme type de système de fichiers et définir le drapeau esp dessus.

Passer à la section #Format de la partition ci-dessous.

Disques partitionnés MBR

La partition système ESP sur une table de partition Master Boot Record est identifiée par l’ID de type de partition EF.

Choisissez l’une des méthodes suivantes pour créer une ESP pour un disque partitionné MBR :

fdisk : Créer une partition primaire avec le type de partition EFI (FAT-12/16/32).
GNU Parted : Créer une partition primaire avec fat32 comme type de système de fichiers et définir le drapeau esp sur celle-ci.

Passez à la section #Formatage de la partition ci-dessous.

Formatage de la partition

La spécification UEFI impose le support des systèmes de fichiers FAT12, FAT16 et FAT32. Pour éviter les problèmes potentiels avec d’autres systèmes d’exploitation et aussi parce que la spécification UEFI ne rend obligatoire que la prise en charge de FAT16 et FAT12 sur les supports amovibles, il est recommandé d’utiliser FAT32.

Après avoir créé la partition, formatez-la en FAT32. Pour utiliser l’utilitaire mkfs.fat, installez dosfstools.

# mkfs.fat -F32 /dev/sdxY

Si vous obtenez le message WARNING: Not enough clusters for a 32 bit FAT!, réduisez la taille du cluster avec mkfs.fat -s2 -F32 ... ou -s1 ; sinon la partition risque d’être illisible par l’UEFI. Voir mkfs.fat(8) pour les tailles de cluster supportées.

Monter la partition

Les noyaux, les fichiers initramfs et, dans la plupart des cas, le microcode du processeur, doivent être accessibles par le chargeur de démarrage 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 de démarrage limite les points de montage disponibles pour la partition système EFI.

Points de montage typiques

Les scénarios les plus simples pour monter la partition système EFI sont :

monter ESP sur /efi et utiliser un chargeur d’amorçage qui est capable d’accéder au(x) noyau(x) et à l’image(s) initramfs qui sont stockés ailleurs (typiquement /boot). Voir Arch boot process#Boot loader pour plus d’informations sur les exigences et les capacités du chargeur de démarrage.
monter ESP sur /boot. C’est la méthode préférée lors du démarrage direct d’un noyau EFISTUB à partir de l’UEFI ou de son démarrage 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’une ESP précédemment créée est trop petite pour contenir plusieurs chargeurs de démarrage et/ou noyaux, mais que l’ESP ne peut pas être facilement redimensionnée (comme lors de l’installation de Linux après Windows pour un double démarrage). Cette méthode est prise en charge par au moins systemd-boot.

Conseil :

/efi est un remplacement du point de montage ESP précédemment populaire (et peut-être encore utilisé par d’autres distributions Linux) /boot/efi.
Le répertoire /efi n’est pas disponible par défaut, vous devrez d’abord le créer avec mkdir(1) avant de monter l’ESP dessus.

Points de montage alternatifs

Si vous n’utilisez pas l’une des méthodes simples de #Points de montage typiques, vous devrez copier vos fichiers de démarrage sur ESP (désignés 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 : il se peut que vous deviez également copier le Microcode à l’emplacement de l’entrée de démarrage.

De plus, vous devrez maintenir les fichiers sur l’ESP à jour avec les mises à jour ultérieures du noyau. Si vous ne le faites pas, vous risquez d’avoir un système non amorçable. Les sections suivantes discutent de plusieurs mécanismes pour 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)). Faites-le toujours 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 ex.:

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

vfatnls_cp437nls_ascii

Utilisation de bind mount

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 bind mount (voir mount(8)). Cela permet à pacman de mettre à jour le noyau directement tout en gardant l’ESP organisé à votre goût.

Note : Cela nécessite un noyau et un chargeur de démarrage compatibles avec FAT32. Ce n’est pas un problème pour une installation Arch régulière, mais pourrait être problématique pour d’autres distributions (à savoir celles qui nécessitent des liens symboliques dans /boot/). Voir le post du forum .

Tout comme dans #Alternative mount points, copiez tous les fichiers de démarrage dans un répertoire sur votre ESP, mais montez l’ESP en dehors de /boot. Ensuite, fixez le montage du répertoire :

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

Après avoir vérifié le succès, modifiez votre Fstab pour rendre les changements persistants :

/etc/fstab

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

Utilisation de systemd

Systemd propose des tâches déclenchées par des événements. Dans ce cas particulier, la capacité à détecter un changement de chemin 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 puisque c’est le dernier fichier construit par mkinitcpio, pour s’assurer que tous les fichiers ont été construits avant de lancer la copie. Les fichiers de chemin et de service systemd à créer sont:

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

Description=Copier le noyau EFISTUB vers le système EFI 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/

Activez et démarrez ensuite efistub-update.path.

Conseil : Pour le démarrage sécurisé 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

Utilisation des é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. Voici un exemple avec 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/

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

Pour utiliser cette méthode, activez le incrond.service.

Utilisation du hook mkinitcpio

Mkinitcpio peut générer un hook qui n’a pas besoin d’un démon de niveau système pour fonctionner. Il génère un processus d’arrière-plan qui attend la génération de vmlinuzinitramfs-linux.img, et initramfs-linux-fallback.img avant de copier les fichiers.

Ajouter efistub-update à la liste des crochets dans /etc/mkinitcpio.conf.

/etc/initcpio/install/efistub-update

# !/usr/bin/env bashbuild() {/usr/local/bin/efistub-copy $ &}help() {cat <<HELPEOFTCe crochet attend que mkinitcpio se termine et copie le ramdisk et le noyau terminés dans le ESPHELPEOF}

/usr/local/bin/efistub-copy

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

Utilisation du préréglage mkinitcpio

Comme les préréglages de /etc/mkinitcpio.d/ supportent 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

Editer le fichier /etc/mkinitcpio.d/linux.preset:

/etc/mkinitcpio.d/linux.preset

# Fichier mkinitcpio preset pour le paquet 'linux'# Répertoire pour copier le noyau, 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"

Pour tester cela, il suffit de lancer:

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

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

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

Utilisation de pacman hook

Une dernière option s’appuie 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 il est exécuté s’ils ont été modifiés dans la transaction précédente.

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

Type = PathOperation = InstallOperation = UpgradeTarget = usr/lib/modules/*/vmlinuzTarget = usr/lib/initcpio/*Target = boot/*-ucode.imgDescription = Copier linux et initramfs dans le répertoire EFI...When = PostTransactionExec = /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

# !/usr/bin/env bash## Copier 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" ] && 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

Dépannage

ESP sur RAID1 logiciel

Il est possible de faire de l’ESP une partie d’une matrice RAID1, mais cela entraîne un risque de corruption des données, et des considérations supplémentaires doivent être prises lors de la création de l’ESP. Voir et pour plus de détails et Démarrage UEFI et RAID1 pour un guide approfondi avec une solution.

L’essentiel est d’utiliser --metadata 1.0 afin de conserver les métadonnées RAID à la fin de la partition, sinon le firmware ne pourra pas y accéder :

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

Le firmware ne voit pas le répertoire EFI

Si vous donnez un nom de volume au système de fichiers (avec l’option -n), veillez à 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
Multiboot Linux avec une partition de démarrage | John Ramsden