Modification de l'ordre de démarrage efi lors de la mise à niveau du paquet
De temps en temps, après la mise à niveau de mon système, l'ordre de démarrage efi est modifié et le système ne démarre pas. Je dois aller au bios et resélectionner l'entrée Ubuntu efi. Je suppose que c'est l'un de ces paquets (au moins, ça arrive toujours quand je vois un de ceux qui sont en train d'être mis à jour):
grub-common grub-efi grub-efi-AMD64 grub-efi-AMD64-bin grub-efi-AMD64-
signed grub2-common shim shim-signed
Quand je lance efibootmgr, je reçois ceci:
efibootmgr
No BootOrder is set; firmware will attempt recovery
J'ai couru:
[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
UEFI
Je suis incapable de trouver des réponses à efibootgmr ne fonctionnant pas. S'il vous plaît aider. Merci!
Mise à jour:
J'ai essayé d'ajouter une variable de démarrage EFI avec:
efibootmgr --create --disk /dev/sda --part 1 --label "Ubuntu" --loader
\\EFI\\ubuntu\\grubx64.efi
Qui retourne:
BootOrder: 0000
Boot0000* Ubuntu
Au redémarrage, le système ne démarre pas.
Maintenant, l'entrée de travail est appelée Ubuntu. Quand je le sélectionne, Ubuntu démarre. Après avoir exécuté efibootmgr à nouveau, j'obtiens le même résultat qu'auparavant:
efibootmgr
No BootOrder is set; firmware will attempt recover
Au cas où cela serait pertinent, shim et signature signé ont également été mis à jour lorsque la commande de démarrage a été modifiée par la mise à jour.
Mise à jour:
L'ordinateur est un gigaoctet Brix GB-BXBT-1900 avec la dernière révision de bios.
Je pense que ma question initiale était pourquoi efigootmgr ne fonctionne pas et cela a été répondu. Merci pour votre participation.
Vous rencontrez ce que j'appelle un "coup d'amorce". J'ai écrit une page sur ce sujet. voir ici pour plus de détails. Cela dit, votre problème semble un peu inhabituel, mais il est probablement lié à ceci:
efibootmgr
No BootOrder is set; firmware will attempt recovery
Ordinairement, un ordinateur basé sur EFI a un jeu de variables BootOrder. Les cas I ont personnellement vu où ils ne sont pas configurés en raison d'un microprogramme défectueux qui refuse simplement d'accepter cette variable. Sur ces ordinateurs, la seule chance de démarrer est via un nom de fichier de secours (généralement EFI/BOOT/bootx64.efi sur l'ESP, bien que EFI/Microsoft/Boot/bootmgfw.efi fonctionne parfois aussi). Cela dit, j'ai entendu parler de cas où la variable BootOrder est vide mais peut être définie. Dans ce cas, l'ajout d'une variable de démarrage EFI, comme décrit ici, peut résoudre le problème.
Si votre ordinateur est simplement gravement défectueux et doit démarrer à l'aide d'un nom de fichier de secours, vous devez copier ou déplacer/renommer le chargeur de démarrage sous le nom approprié, et éventuellement prendre en charge des fichiers tels que les fichiers de configuration.
Étant donné que vous avez parlé de "l'entrée ubuntu efi", je pense que vous avez des variables d'amorçage, mais la variable BootOrder est en train de disparaître. Il s’agit probablement d’un bogue du micrologiciel, bien qu’il puisse indiquer un matériel NVRAM défectueux. La mise à niveau du micrologiciel peut résoudre le problème, s'il s'agit d'un bogue. Contactez le fabricant pour savoir si une telle mise à niveau existe. Si cela ne vous aide pas, vous pouvez copier GRUB dans le nom de fichier de secours, où il doit être appelé si/lorsque la variable BootOrder est à nouveau perdue. Le ESP est normalement monté sur /boot/efi, et les commandes normales du système de fichiers Linux fonctionnent dessus, vous pouvez donc:
Sudo cp -r /boot/efi/EFI/ubuntu /boot/efi/EFI/BOOT
Sudo mv /boot/efi/EFI/BOOT/shimx64.efi /boot/efi/EFI/BOOT/bootx64.efi
Ceci copie Shim dans le nom de fichier de secours. Si vous êtes certain que votre ordinateur n'utilise pas Secure Boot, vous pouvez renommer grubx64.efi, plutôt que shimx64.efi, en bootx64.efi.