EFI system partition (Français)
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 ouDisklabel 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
ouEFI (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.
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).
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'indicateuresp
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
- 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'indicateuresp
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.
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/
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.
/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.
/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
.
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/
/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.