Entrées de démarrage UEFI et état de Secure Boot sous Linux et Windows

Objectif

Inspecter et, si nécessaire, réparer la liste des entrées de démarrage du micrologiciel UEFI, puis vérifier l'état de Secure Boot sur un système Linux ou Windows qui ne démarre pas depuis le disque ou le chargeur attendu.

Prérequis

Micrologiciel UEFI (pas BIOS hérité) ; accès root sous Linux ou invite de commandes avec élévation de privilèges sous Windows, depuis le système en cours d'exécution, un support de secours ou l'écran de configuration du micrologiciel ; sous Linux, efivarfs doit être monté (c'est le cas normal sur un système démarré en UEFI).

Étapes

1. Lister les entrées sous Linux : efibootmgr -v affiche pour chaque entrée son numéro, son libellé et son chemin de périphérique, ainsi que BootOrder, l'ordre suivi par le micrologiciel, et BootCurrent, l'entrée utilisée pour ce démarrage. Créer une entrée avec efibootmgr -c -d <disk> -p <partition> -L "<label>" -l '\EFI\<dir>\shimx64.efi' (-c ajoute aussi la nouvelle entrée à BootOrder, normalement en première position), en supprimer une avec efibootmgr -b <bootnum> -B, modifier l'ordre avec -o <bootnum>,<bootnum>,.... Chaque modification écrit immédiatement dans les variables du micrologiciel ; il n'y a pas d'étape d'application distincte. Il faut d'abord noter la sortie de -v afin de pouvoir rétablir l'ancien ordre avec -o.
2. Pour tester une nouvelle entrée une seule fois sans changer l'ordre, utiliser efibootmgr -n <bootnum> (BootNext) : le micrologiciel ne s'en sert que pour le prochain démarrage, puis revient à BootOrder.
3. Sous Windows, bcdedit /enum firmware liste les entrées du gestionnaire de démarrage du micrologiciel (à distinguer des entrées de chargeur de système d'exploitation d'un simple bcdedit /enum) ; dans PowerShell, il faut mettre entre guillemets les identifiants tels que '{fwbootmgr}'. Windows recrée normalement sa propre entrée avec bcdboot <drive>:\Windows (avec élévation) plutôt que par modification directe.
4. Si le système démarre sur la configuration du micrologiciel ou sur le mauvais système d'exploitation après une réinstallation du chargeur de démarrage, la cause habituelle est une entrée manquante ou qui n'est pas en tête de l'ordre ; on corrige avec efibootmgr -o ou avec le réglage de l'ordre de démarrage du micrologiciel.
5. Vérifier Secure Boot avant de l'incriminer lors d'une erreur « not trusted » : mokutil --sb-state sous Linux ; sous Windows, Confirm-SecureBootUEFI dans un PowerShell avec élévation renvoie $True ou $False, et affiche « Cmdlet not supported on this platform » sur un BIOS ou un micrologiciel non pris en charge.
6. Avec Secure Boot activé, la chaîne de confiance Linux est la suivante : le micrologiciel fait confiance à un shim signé, et shim fait aussi confiance aux Machine Owner Keys (MOK). mokutil --import <key.der> demande un mot de passe à usage unique et ne fait que préparer la clé ; au démarrage suivant, MokManager de shim demande sur la console de confirmer l'enrôlement avec ce mot de passe, donc quelqu'un doit être présent à la console. Cet article ne couvre ni la génération ni la signature des clés.
7. Après toute modification, redémarrer et vérifier avec efibootmgr -v ou bcdedit /enum firmware que l'ordre a bien été pris en compte.

Résultat attendu

L'entrée voulue est présente et en première position dans BootOrder ; l'état de Secure Boot signalé correspond aux besoins de la charge de travail, de préférence activé, avec la clé d'un module tiers enrôlée via MOK plutôt que Secure Boot désactivé.

Limites et base de vérification

efibootmgr modifie directement la NVRAM : la suppression d'une mauvaise entrée prend effet immédiatement, il faut donc vérifier les numéros d'entrée dans la sortie de -v avant d'utiliser -B. Les implémentations de micrologiciel diffèrent dans leur traitement des entrées ajoutées ou mal formées (certaines les suppriment ou les réordonnent) ; le comportement doit donc être confirmé sur le matériel réel.