Partition système EFI – ArchWiki
La partition système EFI (également appelée ESP) est une partition indépendante du système d'exploitation servant de lieu de stockage pour les chargeurs de démarrage EFI, les applications et les pilotes devant être lancés par le microprogramme UEFI. Il est obligatoire pour le démarrage UEFI.
La spécification UEFI impose la prise en charge des systèmes de fichiers FAT12, FAT16 et FAT32 (voir Spécification UEFI version 2.7, section 13.3.1.1), mais tout fournisseur conforme peut éventuellement ajouter une prise en charge de systèmes de fichiers supplémentaires. Par exemple, le micrologiciel des Macs Apple prend en charge le système de fichiers HFS +.
Contenus
Rechercher une partition existante
Si vous installez Arch Linux sur un ordinateur compatible UEFI doté d'un système d'exploitation, tel que Windows 10 par exemple, il est très probable que vous disposiez déjà d'une partition système EFI.
Pour connaître le schéma de partition de disque et la partition système, utilisez fdisk en tant que racine sur le disque à partir duquel vous souhaitez démarrer:
# fdisk -l / dev / sdX
La commande retourne:
- La table de partition du disque: elle indique
Type de label: gpt
si la table de partition est GPT ouType de label: dos
si c'est MBR. - La liste des partitions sur le disque: Recherchez la partition système EFI dans la liste. Il s’agit d’une petite partition (généralement environ 100–550 Mio) de type
Système EFI
ouEFI (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 tel est le cas, il s’agit bien de l’ESP.
minfo
de mtools.
# minfo -i / dev / sdxY :: | grep 'type de disque'
Attention: 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, passez simplement à # Monter la partition. Si vous n'en avez pas trouvé, vous devrez le créer, passez à #Créez 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 située dans la table de partitions principale du disque, et non sous LVM ou RAID logiciel, etc.
Fournir un espace suffisant pour stocker les chargeurs de démarrage et les autres fichiers requis pour le démarrage, et éviter les problèmes d'interopérabilité avec d'autres systèmes d'exploitation[1] la partition doit être d'au moins 260 Mio. Pour les implémentations UEFI précoces et / ou boguées, une taille d'au moins 512 Mio peut être nécessaire.[2]
Disques partitionnés 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-en un des méthodes suivantes pour créer un ESP pour un disque partitionné GPT:
- fdisk: crée une partition avec un type de partition
Système EFI
. - gdisk: crée une partition avec un type de partition
EF00
. - GNU Parted: Créez une partition avec
fat32
en tant que type de système de fichiers et définissez leesp
drapeau dessus.
Passez à #Format la section de partition ci-dessous.
Disques partitionnés MBR
La partition système EFI d'une table de partition Master Boot Record est identifiée par l'ID du type de partition. EF
.
Choisissez-en un des méthodes suivantes pour créer un ESP pour un disque partitionné MBR:
- fdisk: crée une partition principale avec un type de partition
EFI (FAT-12/16/32)
. - GNU Parted: Créez une partition primaire avec
fat32
en tant que type de système de fichiers et définissez leesp
drapeau dessus.
Passez à #Format la section de partition ci-dessous.
Formater la partition
La spécification UEFI impose la prise en charge des systèmes de fichiers FAT12, FAT16 et FAT32.[3]. Pour éviter les problèmes potentiels avec d'autres systèmes d'exploitation et également, la spécification UEFI n'imposant que la prise en charge de FAT16 et FAT12 sur un support amovible[4], il est recommandé d’utiliser FAT32.
Après avoir créé la partition, formatez-la en FAT32. Pour utiliser le mkfs.fat
utilitaire, installer dosfstools.
# mkfs.fat -F32 / dev / sdxY
Si vous recevez le message AVERTISSEMENT: Pas assez de grappes pour un FAT 32 bits!
, réduisez la taille de la grappe avec mkfs.fat -s2 -F32 ...
ou -s1
; sinon la partition peut être illisible par UEFI. Voir mkfs.fat (8) pour les tailles de cluster prises en charge.
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 par l'UEFI lui-même pour pouvoir initialiser le système. Ainsi, si vous souhaitez conserver une configuration simple, le choix de votre chargeur d’amorçage limite les points de montage disponibles pour la partition système EFI.
Les scénarios les plus simples pour monter une partition système EFI sont les suivants:
- monter l'ESP à
/ efi
et utilisez un chargeur de démarrage doté d'un pilote pour votre système de fichiers racine (par exemple, GRUB, rEFInd). - monter l'ESP à
/démarrage
. Cette méthode est recommandée lorsque vous démarrez directement un noyau EFISTUB à partir de UEFI.
/ efi
est un remplacement[5] pour le point de montage ESP, qui était auparavant très populaire (et peut-être encore utilisé par d'autres distributions Linux)/ boot / efi
.- le
/ efi
répertoire n’est pas disponible par défaut, vous devrez d’abord le créer avec mkdir (1) avant de monter l'ESP à elle.
Points de montage alternatifs
Si vous n’utilisez pas l’une des méthodes simples de #Mount la partition, vous devrez copier vos fichiers de démarrage sur 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 /
De plus, vous devrez maintenir les fichiers sur l'ESP à jour avec les mises à jour ultérieures du noyau. Sinon, le système pourrait ne plus démarrer. Les sections suivantes décrivent plusieurs mécanismes permettant de l’automatiser.
/démarrage
, veillez à ne pas utiliser le mécanisme systemd automount (y compris celui de systemd-gpt-auto-generator (8)). Faites-le toujours monter manuellement avant toute mise à jour de système ou de noyau, sinon vous ne pourrez peut-être pas le monter après la mise à jour, ce qui vous verrouille dans le noyau en cours d'exécution sans possibilité de mettre à jour la copie du noyau sur ESP.
Vous pouvez également précharger les modules de noyau requis au démarrage, par exemple:
/etc/modules-load.d/vfat.conf
vfat nls_cp437 nls_iso8859-1
Utiliser bind mount
Au lieu de monter l'ESP lui-même pour /démarrage
, vous pouvez monter un répertoire de l’ESP pour /démarrage
en utilisant un montage bind (voir monture (8)). Cela permet à pacman de mettre à jour le noyau directement tout en maintenant l’ESP organisé à votre goût.
- Cela nécessite un noyau et un chargeur de démarrage compatibles avec FAT32. Ce n’est pas un problème pour une installation régulière d’Arch, mais pourrait poser problème pour d’autres distributions (notamment celles qui nécessitent des liens
/démarrage/
). Voir le post du forum ici. - Vous doit Utilisez le
root =
paramètre du noyau afin de démarrer en utilisant cette méthode.
Comme dans les points de montage alternatifs, copiez tous les fichiers de démarrage dans un répertoire de votre ESP, mais montez-le. à l'extérieur /démarrage
. Liez ensuite le répertoire:
# mount --bind esp/ EFI / arch / boot
Après avoir vérifié le succès, éditez votre Fstab pour que les modifications soient persistantes:
/ etc / fstab
esp/ EFI / arch / boot aucune valeur par défaut, bind 0 0
Utiliser systemd
Systemd propose des tâches déclenchées par des événements. Dans ce cas particulier, la possibilité de détecter un changement de chemin est utilisée pour synchroniser les fichiers du noyau EFISTUB et initramfs lorsqu'ils sont mis à jour dans /démarrage/
. Le fichier surveillé pour les changements est initramfs-linux-fallback.img
Comme il s’agit du dernier fichier créé par mkinitcpio, assurez-vous que tous les fichiers ont été créés avant de lancer la copie. le systemd Les fichiers de chemin et de service à créer sont:
/etc/systemd/system/efistub-update.path
[Unit] Description = Copier 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 = Copier le noyau EFISTUB sur la partition système EFI [Service] Type = coup unique 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 --sortie esp/ EFI / arch / vmlinuz-linux / boot / vmlinuz-linux
Utiliser les événements du système de fichiers
Les événements de système de fichiers peuvent être utilisés pour exécuter un script synchronisant le noyau EFISTUB après les mises à jour du noyau. Un exemple avec incron suit.
/ 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 /
Remarque: Le premier paramètre /boot/initramfs-linux-fallback.img
est le fichier à regarder. Le second 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 crochet mkinitcpio
Mkinitcpio peut générer un hook ne nécessitant pas de démon de niveau système pour fonctionner. Il engendre un processus en arrière-plan qui attend la génération de vmlinuz
, initramfs-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 bash construire() { / usr / local / bin / efistub-copy $$ & } Aidez-moi() { chat << HELPEOF Ce crochet attend que mkinitcpio se termine et copie le disque mémoire et le noyau finis sur l'ESP. HELPEOF }
/ usr / local / bin / efistub-copy
#! / usr / bin / env bash si [[ $1 -gt 0 ]]puis tandis que [ -e /proc/$1 ] faire dormir .5 terminé Fi rsync -a / boot / esp/ echo "Synced / boot avec ESP"
Utilisation du crochet mkinitcpio (2)
Un autre alternative Aux solutions ci-dessus, c'est potentiellement plus propre car il y a moins de copies et n'a pas besoin d'un démon de niveau système pour fonctionner. La logique est inversée, le initramfs est directement stocké dans la partition EFI, pas copié dans /démarrage/
. Ensuite, le noyau et tous les autres fichiers supplémentaires sont copiés sur la partition ESP, grâce à un hook mkinitcpio.
Éditer le fichier /etc/mkinitcpio.d/linux.preset
:
/etc/mkinitcpio.d/linux.preset
# mkinitcpio fichier prédéfini pour le paquet 'linux' # Répertoire pour copier le noyau, les initramfs ... ESP_DIR = "esp/ EFI / arch " ALL_config = "/ etc / mkinitcpio.conf" ALL_kver = "/ boot / vmlinuz-linux" PRESETS = ('default' 'fallback') #default_config = "/ etc / mkinitcpio.conf" default_image = "$ {ESP_DIR} /initramfs-linux.img" default_options = "- Un esp-update-linux" #fallback_config = "/ etc / mkinitcpio.conf" fallback_image = "$ {ESP_DIR} /initramfs-linux-fallback.img" fallback_options = "- S autodétection"
Puis créez le fichier / etc / initcpio / install / esp-update-linux
qui doivent être exécutables:
/ etc / initcpio / install / esp-update-linux
# Répertoire pour copier le noyau, les initramfs ... ESP_DIR = "esp/ EFI / arch " construire() { 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} /" } Aidez-moi() { chat << HELPEOF Ce hook copie le noyau sur la partition ESP HELPEOF }
Pour tester cela, lancez simplement:
# rm /boot/initramfs-linux-fallback.img # rm /boot/initramfs-linux.img # mkinitcpio -p linux
Utiliser le préréglage mkinitcpio
Comme les presets dans /etc/mkinitcpio.d/
supporte les scripts shell, le noyau et initramfs peuvent être copiés en éditant simplement les presets.
/etc/mkinitcpio.d/0.preset
ESP_DIR = "esp/ EFI / arch " cp -af "/ boot / vmlinuz-linux $ {suffixe}" "$ ESP_DIR /" ALL_config = "/ etc / mkinitcpio.conf" ALL_kver = "$ ESP_DIR / vmlinuz-linux $ {suffixe}" PRESETS = ('default') default_config = "/ etc / mkinitcpio.conf" default_image = "$ ESP_DIR / initramfs-linux $ {suffixe} .img"
/etc/mkinitcpio.d/linux.preset
source /etc/mkinitcpio.d/0.preset
/etc/mkinitcpio.d/linux-zen.preset
suffixe = '- zen' source /etc/mkinitcpio.d/0.preset
Utilisation de pacman hook
Une dernière option repose sur les hooks pacman 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 dans la transaction précédente.
/etc/pacman.d/hooks/999-kernel-efi-copy.hook
[Trigger] Type = Fichier Opération = Installer Opération = mise à niveau Cible = boot / vmlinuz * Cible = usr / lib / initcpio / * Cible = boot / * - ucode.img [Action] Description = Copier Linux et initramfs dans le répertoire EFI ... Quand = 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
#! / usr / bin / env bash # # Copier les images du noyau et initramfs dans le répertoire EFI # ESP_DIR = "esp/ EFI / arch " pour le fichier dans / boot / vmlinuz * faire cp -af "$ fichier" "$ ESP_DIR / $ (nom de base" $ fichier "). efi" [[ $? -ne 0 ]]&& sortie 1 terminé pour le fichier dans / boot / initramfs * faire cp -af "$ fichier" "$ ESP_DIR /" [[ $? -ne 0 ]]&& sortie 1 terminé [[ -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 /" sortie 0
Problèmes connus
ESP sur RAID
Il est possible d'intégrer l'ESP à une matrice RAID1, mais cela risquerait de corrompre les données et de prendre en compte d'autres considérations lors de la création de l'ESP. Voir [6] et [7] pour plus de détails.
Voir Démarrage UEFI et RAID1 pour un guide détaillé.
La partie clé est d'utiliser --metadata 1.0
afin de conserver les métadonnées RAID à la fin de la partition, sinon le micrologiciel ne pourra pas y accéder:
# mdadm --create --verbose --level = 1 --metadata = 1.0 --raid-devices = 2 / dev / md / ESP / dev / sdaX / dev / sdbY
Commentaires
Laisser un commentaire