Ainsi, la dernière fois que j'ai utilisé mon installation Ubuntu, c'était hier soir. Aujourd'hui, alors que je l'ai démarré, il m'a dit que démarrer grubx64.efi n'est pas autorisé. Assez facile. Je sais comment le réactiver à partir de mon BIOS.
Après l'avoir réactivé, j'essaie de redémarrer et j'obtiens le message d'erreur suivant:
erreur: Secure Boot interdit le chargement du module à partir de (hd0, gpt7) /boot/grub/normal.mod
Et puis il y a cette sorte de "demande de règlement" l'invite CL en dessous de cette erreur. Je ne l'ai jamais compris, sauf que ls
est une commande valide. Utiliser ls
affiche divers fichiers/répertoires/lecteurs (hdx , *)
.
Notez que, comme je n’ai jamais pu charger Windows 8 de GRUB malgré divers tutoriels, j’utilise rEFInd pour basculer entre le chargement GRUB (qui, à mon tour, permet de charger Ubuntu) et Windows 8.
Comment réactiver GRUB (et accéder à Ubuntu) et est-ce que quelqu'un sait ce qui vient de causer ce problème? Je me souviens d'avoir installé les mises à jour Ubuntu hier soir, mais je ne me souviens pas s'il y avait quoi que ce soit qui soit en rapport avec quelque chose de spécifique à UEFI.
Je n'ai pas trouvé de solution exacte à cela, mais j'ai réussi à revenir à Ubuntu par une solution plus "générale" (faute d'un meilleur terme).
J'examinais mon BIOS lorsque j'ai remarqué une option permettant de désactiver le démarrage sécurisé (je me demandais pourquoi je ne l'avais jamais remarqué auparavant alors que j'avais des problèmes pour effectuer un double démarrage de Win8 et de Precise). Je l'ai désactivé et le tour est joué, GRUB se charge. De plus, je peux maintenant charger Windows 8 à partir de GRUB; Je n'ai plus besoin de retrouver comme intermédiaire. Choisir Win8 dans GRUB affiche une erreur (que je peux contourner en appuyant simplement sur la touche n'importe laquelle). J'examinerai cela à un autre moment, à moins que je sache que c'est quelque chose de très risqué.
Comme vous l'avez découvert, la désactivation de Secure Boot corrige le problème. Mon intuition est que vous l'aviez déjà désactivé auparavant et que vous l'aviez activé par mégarde ou que vous utilisiez une version de GRUB activée pour le démarrage sécurisé et qu'une mise à jour logicielle a installé un GRUB non signé ou modifié. le chemin d’amorçage d’une manière qui contourne le programme shim (c’est ce que Ubuntu utilise pour prendre en charge le démarrage sécurisé).
Une autre option consiste à ajouter le support Secure Boot de manière plus générale. Si votre premier chargeur de démarrage est rEFInd, vous pouvez lire documentation de Secure Boot de rEFInd pour obtenir des détails sur la manière de le faire fonctionner avec Secure Boot. Malheureusement, Ubuntu n'étant pas encore livré avec une version de shim compatible MOK, vous devez donc installer une autre version de shim et ajouter la clé publique d'Ubuntu à votre liste de MOK. C'est possible, et ce n'est même pas si difficile, mais cela implique d'utiliser plusieurs outils de ligne de commande et de suivre les instructions avec précision. Notez que Ubuntu a ajouté le support Secure Boot avec la version 12.10. J'ai remarqué une étiquette 12.04 sur votre question, donc si vous utilisez 12.04, vos noyaux ne sont presque certainement pas signés, ce qui compliquera cette utilisation plus complète de Secure Boot. Globalement, il est probablement préférable de laisser Secure Boot désactivé. Je mentionne cette alternative au cas où vous auriez des raisons de l'activer.
le problème auquel vous êtes confronté pourrait être dû au fait que certains processeurs obligatoires (arm) et non aussi (intel) portent le logo Windows 8. Il s'agit en majorité du démarrage sécurisé. pour la présence d'une signature cryptographique sur tout programme EFI qu'il exécute ". Pour résoudre ce problème, vous devrez probablement désactiver le démarrage sécurisé. Jetez un coup d'œil à cet article pour un aperçu de l'histoire et de ce que vous devez savoir pour que le travail soit effectué: