Efibootmgr

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Efibootmgr and the translation is 47% complete.
Outdated translations are marked like this.

efibootmgr est un outil permettant de gérer les entrées de démarrage UEFI.

Ce n'est pas un bootloader. C'est un outil intéragissant avec le microcode EFI du système, lui-même agissant comme un gestionnaire de démarrage. Avec efibootmgr, des entrées de démarrage peuvent être créées, modifiées ou supprimées.

Installation

Noyau

CONFIG_EFIVAR_FS support needs to be enabled.

Remarque
Il n'est pas possible d'utiliser efivarfs sans les service EFI, qui peuvent êtra activés (dans le cas où ils ont été désactivés par défaut, par exemple CONFIG_EFI_DISABLE_RUNTIME=y) avec l'option kernel efi=runtime.

Emerge

Le paquet sys-boot/efibootmgr ne possède pas de USE flags. Tout ce qui est nécessaire pour son installation est :

root #emerge --ask sys-boot/efibootmgr

Configuration

Variables EFI

Afin d'utiliser efibootmgr correctement, les variables EFI doivent être accessibles. Ce qui requiert le système d'avoir démarré en mode EFI (et non via en MBR), sinon, les variables EFI ne seront pas utilisables. Si le système est en mode MBR, redémarrez et assurez-vous de bien démarrer en mode EFI. Souvent, il ne s'agit que d'une option à sélectionner dans les paramètres du microcode ou choisir une entrée de démarrage dans le menu d'amorçage.

Lorsque le système est en mode EFI, exécutez la commande suivante afin d'attester l'existence des efivarfs :

root #mount | grep efivars
efivarfs on /sys/firmware/efi/efivars type efivarfs (ro,relatime)

It is mounted read-only (ro) through the sysfs init script), so it needs to be remounted read-write (rw) manually using the following command:

root #mount -o remount,rw -t efivarfs efivarfs /sys/firmware/efi/efivars

Prérequis

Si une partition système EFI (ESP) n'existe pas, elle doit être créée, voir EFI System Partition

Usage

Lister les entrées de démarrage

Pour lister les entrées de démarrage, utilisez la commande suivante : --verbose or -v

root #efibootmgr -v
BootCurrent: 0002
Timeout: 3 seconds
BootOrder: 0003,0003,0002,0000,0004
Boot0000* CD/DVD Drive  BIOS(3,0,00)
Boot0001* Hard Drive    BIOS(2,0,00)
Boot0002* Gentoo        HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d)File(\EFI\boot\bootx64.efi)
Boot0003* Hard Drive    BIOS(2,0,00)P0: ST1500DM003-9YN16G

Créer des entrées de démarrage

Pour créer des entrées de démarrage EFI, plusieurs arguments doivent être passés à efibootmgr :

  • --create or -c pour créer une nouvelle entrée;
  • --part or -p suivit du numéro de partition sur laquelle réside la EFI System Partition ;
  • --disk or -d suivit du disque sur lequel est la partition système EFI;
  • --label or -L suivit du label à utiliser pour l'entrée de démarrage;
  • --loader or -l suivit du chemin d'accès à l'image EFI à démarrer
Important
Le chemin vers l'image EFI à exécuter doit utiliser \ (backslash) au lieu de / (slash) comme séparateur.
Important
De plus, si la partition ESP a déjà été créée par un autre système d'exploitation, elle peut être onnéem différement que /boot/efi. Si la partition ESP a été créée par un autre système d'exploitation, utilisez le même début répertoire pour créer les entrées de démarrage, c'est à dire tout ce qui suit /boot.

Si c'est cette structure de fichier

root #tree /boot/ -L 3
/boot/
└── EFI
    ├── Grub
    │   └── grubx64.efi
    └── Gentoo
        └── bzImage-4.14.83.efi

alors le chemin de chargement sera :

root #efibootmgr -c -L "Grub" -l '\EFI\Grub\grubx64.efi'
root #efibootmgr -c -L "Gentoo" -l '\EFI\Gentoo\bzImage-4.14.83.efi'

Par exemple :

root #efibootmgr -c -d /dev/sda -p 2 -L "Gentoo" -l '\efi\boot\bootx64.efi'

C'est aussi possible d'ajouter des paramètres à la ligne de commande kernel - parfois pas supporté par toutes les implémentations UEFI not supported[1]:

root #efibootmgr -c -d /dev/sda -p 2 -L "Gentoo" -l '\efi\boot\bootx64.efi' -u 'root=/dev/sda3 initrd=\efi\boot\initramfs.img quiet'

Optionally, additional kernels can be installed and made known to the UEFI firmware. This is especially useful when wanting to test more kernels or to dual-boot with another operating system. These will be shown in the boot selection prompt, normally after a keyboard hotkey is pressed at the right time during system initialization. The latest added entry always gets highest boot priority, so it will be default. If the hotkey combination is unknown, search for official documentation from the computer manufacturer. This information is usually not difficult to find.

Supprimer une entrée de démarrage

Avant de supprimer une entrée, vous devez déterminer son identifiant (ID).

To delete the Gentoo entry as shown above (which has Boot0002 as the identifier), ask efibootmgr to delete the entry with id 2, passing the arguments --bootnum or -b with the identifier, and --delete-bootnum or -B to delete the entry:

root #efibootmgr -b 2 -B 2

Removable media

EFI bootloaders on removable media are not configured as boot entries, so tools like efibootmgr are not required. Instead the computer firmware identifies removable boot options by looking for a predefined file name unique to the system architecture in use, in a predefined path.[2]

Some (U)EFI implementations support the use of the removable media boot path as a fallback on internal drives.[3] This is against specification and should be avoided, but may help on a system with a buggy (U)EFI. Only one such fallback bootloader is possible on a specific system (i.e. architecture), due to the standardized boot path and file names.

Architecture Abbreviation File name PE executable machine type
x86 32-bit IA-32 \efi\boot\bootia32.efi 0x14c
x86-64 x64 \efi\boot\bootx64.efi 0x8664
Itanium IA-64 \efi\boot\bootia64.efi 0x200
ARM 32-bit AArch32 \efi\boot\bootarm.efi 0x01c2
ARM 64-bit AArch64 \efi\boot\bootaa64.efi 0xAA64
RISC-V 32-bit \efi\boot\bootriscv32.efi 0x5032
RISC-V 64-bit \efi\boot\bootriscv64.efi 0x5064
RISC-V 128-bit \efi\boot\bootriscv128.efi 0x5128
Loongson 32-bit LoongArch32 \efi\boot\bootloongarch32.efi 0x6232
Loongson 64-bit LoongArch64 \efi\boot\bootloongarch64.efi 0x6264
Remarque
To boot from removable media, the firmware has to look for compatible bootloaders on supported devices, which can be configured in the firmware setup. Like most firmwares, (U)EFI provides a hotkey to show a boot selection (formally known as "BIOS Boot Selection" or BBS), otherwise (U)EFI will use the configured default boot entry. However, a buggy (U)EFI may default to the removable media boot path even on internal drives.

To use the removable media boot path it is sufficient to copy the EFI bootloader to the required path and file name. Should the firmware make use of this fallback, this may also remove the ability to select between configured boot entries, meaning that boot options (as listed with efibootmgr) through (U)EFI will not work. Even though every EFI bootloader can be used as fallback, it may be advisable to use a boot manager that itself has the ability to select between boot options, such as GRUB. From the above example for x64 (amd64):

root #cp /efi/EFI/Grub/grubx64.efi /efi/EFI/boot/bootx64.efi
Remarque
The FAT file system of the EFI System Partition is not case-sensitive, but case-preserving (VFAT), while Unix and Linux is strictly case-sensitive at all times. Because of this, the path /efi/EFI/boot/bootx64.efi may not work on all systems, as it could be using capital letters, e.g. /efi/EFI/BOOT or /efi/EFI/Boot; the same goes for bootx64.efi. Running tree -L 3 /efi, when the ESP is mounted under /efi, will show the names in use on the individual system, to which the above command has to be changed accordingly.
Important
The fallback bootloader is not automatically updated! Every time e.g. GRUB is re-installed (like after a version update, which may contain security fixes), it has to be copied to the fallback boot path again, overwriting (updating) the previous version!

The boot manager included in systemd, systemd-boot (formally Gummiboot), will automatically install to the removable media boot path. When sys-apps/systemd with the boot USE flag is updated, it is necessary to run bootctl again in order to update both bootloader files.

root #bootctl update

Suppression

Unmerge

root #emerge --ask --depclean --verbose sys-boot/efibootmgr

Voir aussi

Références