[efibootmgr] Comment ça fonctionne ?

[Stdrome1209]

Bonjour à tous, je voudrais tester efibootmgr seulement sur le wiki (https://wiki.archlinux.org/index.php/EF ... ng_EFISTUB) je peu lire cette phrase :

UEFI is designed to remove the need for an intermediate bootloader such as GRUB. If your motherboard has a good UEFI implementation, it is possible to embed the kernel parameters within a UEFI boot entry and for the motherboard to boot Arch directly. You can use efibootmgr to modify your motherboard's boot entries from within Arch.

Cela veux dire que ça modifie des paramètres directement sur la carte mère (la mémoire rom ?!?) ? Dans ce cas une fausse manipulation peut-elle mener à de gros problèmes difficiles à corriger voir irréversible et rendre la machine inutilisable ? Mes connaissances en Anglais ne sont pas extraordinaire donc il se peu que je n´ai pas bien compris.

[benjarobin]

Bonjour,
Les cartes mères UEFI possèdent une mémoire en lecture/écriture qui contiennent les entrées de boot.
Il n'y a aucun risque à modifier via efibootmgr cette mémoire, c'est prévu par la carte mère. Windows quand il s’installe en UEFI procède de la même façon.

[Stdrome1209]

Ok ça me rassure, mais dans l´éventualité ou je modifie cette mémoire c´est elle qui vas définir sur quoi le PC vas booter c´est cela ? Dans ce cas imaginons que je désire par la suite repasser à Grub ou Gummiboot, les réglages contenus dans cette mémoire ne vont pas rentrer en conflit avec le bootloader installé sur le disque ? En passant en priorité par exemple.

Et si je désire remettre cette mémoire en "sortie d´usine" pour une raison X ou Y c´est possible ?

[benjarobin]

Je ne suis pas sur de comprendre tes questions...
efibootmgr permet de supprimer toutes les entrées, donc oui cela sera équivalent à une mémoire "sortie d'usine", après tu as toujours l'interface de ton BIOS pour modifier aussi les entrées.
la mémoire NVRAM contient juste la liste des applications EFI installées dans la partition ESP ainsi que l'ordre de préférence

[Stdrome1209]

Moi même je ne comprend pas trop le fonctionnement de ce genre de système, donc effectivement j´ai bien peur de ne pas poser les bonnes questions

Bon je vais faire quelque recherche sur le fonctionnement de l´EFI histoire de mieux comprendre avant de reposer des question sans aucun sens, désolé.

Et merci pour tes réponses et ta patience envers un débutant

[Moviuro]

Tu as un microgiciel fourni par le fabriquant dans ta machine qui respecte les specs EFI. Ce micogiciel sait lire le FAT32 et la mémoire NVRAM de ta CM. Tu peux taper dans la NVRAM pour donner des instructions au microgiciel (boote sur cet équipement réseau avec tel fichier EFI / charge tel fichier EFI et balance lui les options suivantes / etc.). Ce microgiciel, tu peux intéragir avec soit avec efibootmgr, soit en tapant F2/whatever au boot.

C'est tout facile, non?

Et oui, le paramètre d'usinage, c'est "pas de menu de boot dans le microgiciel", auquel cas, par défaut, il va chercher toutes les partitions EFI, puis lancer /boot/boot<architecturemachine>.efi

[Stdrome1209]

Ok je comprend mieux, mais dans ce cas imaginons que je décide d´utiliser efibootmgr pour booter, puis que par la suite (dans quelque jours/semaines) je décide de reformater complètement ma machine pour la réinstaller et que cette fois je choisisse de repasser sous Grub ou Gummiboot, dans ce cas je dois d´abord vider la NVRAM pour que les instructions de boot que j´y aurais inscrites ne rentre pas en conflit avec mon nouveau bootloader, c´est bien cela ?

[benjarobin]

Elle ne rentreront pas en conflit, tu risque juste d'avoir des duplications. Donc en effet il est conseillé de vider la mémoire NVRAM avant une nouvelle installation de bootloader

[Moviuro]

La seule chose qu'il y a dans ta NVRAM, c'est un menu défini dans les specs EFI et universellement compréhensible.
C'est tout.

Quand tu dis "utiliser efibootmgr pour booter", ça n'a pas de sens. C'est ton microgiciel qui sert à démarrer. C'est lui le bootloader, c'est lui qui sait comment on "lance" un fichier .efi
Grub et gummiboot ne sont que de vulgaires fichiers EFI, interchangeables, installables côte à côte : ils deviennent des boot managers, des trucs "en bonus" du menu EFI de ta NVRAM (qui est pas franchement ergonomique) pour proposer des zolis menus et des zolies images (et un shell, dans le cas de GRUB)

Exemple de menu :
Boot0001 charger \efi\vmlinuz et lui passer les options "root=UUID=machin initrd=machin"
Boot0002 Lancer gummiboot : \efi\boot\gummiboot\gummibootx64.efi (qui lui pourra vivre sa vie et lancer linux ou windows ou un EFIShell, ou n'importe)
Boot0003 Lancer un Boot Legacy sur le CD

Ce menu est paramétrable et éditable à souhait. (en plus, le comportement par défaut, de mémoire, c'est "je tente jusqu'à ce que ça fonctionne")

[Xorg]

La seule chose que tu dois savoir avec la commande efibootmgr, c'est que tu ne peux pas créer plus d'une entrée de boot par noyau. Si tu essayes, tu verras au boot qu'il ne restera plus qu'une. Mais je parle d'une entrée par noyau, donc tu peux avoir autant d'entrées que de noyaux et que d'OS.
C'est juste une commande permettant de manipuler la séquence de boot de l'UEFI, et non un bootloader. Le principe de l'EFI Boot Stub (tu peux aussi lire la page française, les informations présentes dedans sont toujours d'actualité), c'est de booter sans l'intermédiaire d'un bootloader.
Dans le schéma classique, on avait :

Code : Tout sélectionner

BIOS -> Bootloader -> OS

Mais avec un UEFI, on peut trouver aussi ceci :

Code : Tout sélectionner

UEFI -> OS

Pour la faire courte.

C'est vachement bourrin de "vider la NVRAM".
Tu lances efibootmgr (sans argument) pour lister toutes les entrées de boot actuelles, ensuite pour supprimer tu dois faire efibootmgr -B -b XXXX (où XXXX est est un nombre en hexadécimal correspondant à l'entrée que tu désires supprimer ; ce nombre est obtenu avec la première commande), et c'est tout.

Un petit exemple si tu veux un peu d'explication sur la création manuelle d'une entrée de boot (utile dans le cas d'un boot dit stub) :

Code : Tout sélectionner

echo "initrd=\EFI\archlinux\intel-ucode.img"\
	"initrd=\EFI\archlinux\initramfs-linux-ck.img"\
	"root=UUID=16a650d7-aad2-4173-85f8-16dbf286432a"\
	"rw quiet gpt rootfstype=ext4 efi_no_storage_paranoia cgroup_disable=memory"\
	"raid=noautodetect radeon.audio=0 fbcon=scrollback:256k" \
 | iconv -f ascii -t ucs2 | efibootmgr -c -g -d /dev/sda -p 1 -L "ArchLinux (linux-ck)" -l '\EFI\archlinux\vmlinuz-linux-ck.efi' --append-binary-args -

Bien entendu, tu comprendras que c'est ma configuration donc ne prends pas ce code tel quel.
Dans le echo, tu mets la ligne de boot du noyau en gros (avec les options que tu veux, ce n'est pas nécessaire d'écrire cette chaîne de caractères sur plusieurs lignes bien entendu).
Laisse la partie iconv comme ça.
Adapte la partie efibootmgr : -d c'est le disque qui contient l'ESP (donc la partition FAT32 dédiée à l'EFI), -p le numéro de partition (j'ai mis 1 car chez moi l'ESP est /dev/sda1), -L est le label que tu veux donner à cette entrée de boot et -l désigne le noyau à charger (la chemin est absolu à la partition d'ESP, attention aux anti-slashs dans l’arborescence).

Finalement, la commande efibootmgr est un jeu d'enfant avec 2-3 scripts à porté de main.

[Moviuro]

Code : Tout sélectionner

echo "initrd=\EFI\archlinux\intel-ucode.img"\
	"initrd=\EFI\archlinux\initramfs-linux-ck.img"\
	"root=UUID=16a650d7-aad2-4173-85f8-16dbf286432a"\
	"rw quiet gpt rootfstype=ext4 efi_no_storage_paranoia cgroup_disable=memory"\
	"raid=noautodetect radeon.audio=0 fbcon=scrollback:256k" \
 | iconv -f ascii -t ucs2 | efibootmgr -c -g -d /dev/sda -p 1 -L "ArchLinux (linux-ck)" -l '\EFI\archlinux\vmlinuz-linux-ck.efi' --append-binary-args -

C'est dans le wiki quelque part ce gros machin? Parce que j'avais cherché il y a quelques mois, j'avais fait chou blanc. Si non, tu pourrais l'y mettre (avec deux ou trois explications) ? Siiiiteupléééé !

[benjarobin]

@Moviuro https://wiki.archlinux.fr/EFI_Boot_Stub ... ns_au_boot

[Xorg]

Waouw, ça fait deux ans déjà que j'ai créé cette page de Wiki, je ne pensais pas que c'était si vieux que ça.
En fait, j'ai juste raconté de tête ce qui est déjà écrit dans Création de l'entrée. Et avec l'autre morceau qu'a donné Benjarobin, tu as tout ce qu'il faut pour créer tes propres entrées de boot.
Hormis certaines options dont je ne suis toujours pas certain de l'utilité, ce que j'ai posté est similaire à ce qui vient du wiki, vu que je l'avais directement pompé du wiki puis modifié.

Mais oui, à la limite dès que j'aurais le temps je ferrai un tour de page voir s'il y a des choses à ajouter ou modifier. Tiens-nous au courant si tu as des suggestions.

[Stdrome1209]

Et bien merci de votre aide à tous, je comprend mieux comment ça fonctionne (en tout cas bien mieux que suite à ma lecture de la page Wikipedia), et surtout je suis rassuré quand au fait qu´une fausse manip ne risque pas "d´endommager" ma carte mère ou tout du moins de me conduire à une situation compliqué à rétablir.

Je continuerais mes tests demains sur VirtualBox histoire de voire quel méthode pour booter en UEFI me conviens le mieux sans réinstaller ma machine 15 fois (c´est un SSD donc je préfère éviter les copies inutiles).

Par contre je me demande si il est possible en reformatant simplement ma partition EFI et en régénérant le Kernel et les Initramfs grâce à la commande

Code : Tout sélectionner

mkinitcpio -p linux

de changer de bootloader sans réinstaller le système ? À priori mes maigres connaissances me disent que oui.

[jean_no]

Salut

En UEFI, tu ne peux pas changer de bootloader car c'est l'UEFI qui se charge de lancer ce qu'il trouve dans la NVRAM ( déjà dit et expliqué). En revanche, tu peux installer autant de boot manager que tu veux, en inscrivant pour chaque une entrèe dans la NVRAM grâce à efibootmgr.
Il est donc de ce fait totalement inutile de formater la partition ESP.
Les tests que tu feras dans VBox ne seront pas pertinents car pas de NVRAM dans VBox.

A+

[Xorg]

Il n'a pas tout à faire tord Jean_no, l'expérience EFI dans VirtualBox est moyenne je trouve.

Comme on l'a déjà dit 50 fois, du stub ce n'est pas un bootloader... Ça permet à l'UEFI de charger directement le kernel lui-même. Donc non, on ne formate pas un ESP, Non, réinstaller le système pour booter en stub est complètement inutile. Régénérer l'initramfs ça va rien changer non plus.
Il faut juste utiliser la commande efibootmgr correctement comme dit plus haut, et dans le pire des cas, tu auras juste une entrée de boot erronée (donc elle ne fonctionnera pas), mais bien entendu que non ça ne permet pas de modifier délibérément le firmware, et heureusement d'ailleurs.

Donc tu peux très bien garder ton bootloader (comme Grub par exemple) tout en créant une entrée de boot dite stub. Ça ne posera absolument pas de problème.

[Stdrome1209]

et dans le pire des cas, tu auras juste une entrée de boot erronée (donc elle ne fonctionnera pas)

Mais ces entrée erronée ne ralentisse pas le démarrage du système ?

[benjarobin]

Pourquoi elles impacteraient le démarrage ?
Si on simplifie énormément, tu peux voir la NVRAM comme un fichier texte, avec pour chaque ligne une entrée de boot, la première étant celle utilisée.

[Xorg]

Non, ça va même vite fait faire une jolie erreur si tu essayes de l'utiliser alors qu'elle est erronée. Mais normalement, si tu prends les précautions qu'il faut, ça n'arrive pas.

Toutes les entrées de boot dans la NVRAM sont indépendantes. Ce n'est pas comme le MBR où quand tu l'écrases (accidentellement), tu ne peux plus booter sur le disque concerné.