web-dev-qa-db-fra.com

Changer l'ordre de démarrage sur un démarrage multiple sous Windows 10 - Ubuntu 15.10 - Fedora 23

Je rencontre un problème pour définir l'ordre de démarrage car je souhaite que ce soit sur mon ordinateur à démarrage multiple contenant Windows 10 - Ubuntu 15.10 - Fedora 23.

Voici ce que j'ai fait: Avant, je n'avais qu'un double démarrage avec Windows 10 et Ubuntu 15.10 qui fonctionnait comme prévu:

  • Je pourrais le configurer, et par exemple mettre en place un thème.
  • Je pourrais facilement démarrer sur une clé USB.

Comme je voulais essayer d'autres distributions Linux, j'ai installé Fedora 23.

Il est arrivé que Fedora prenne le pouvoir sur le démarrage. J'ai d'abord dû changer la configuration de démarrage de Fedora, en remplaçant linux et initrd par linuxefi et initrdefi pour pouvoir démarrer sur Ubuntu, comme expliqué ici .

Je peux alors accéder à tout le système d'exploitation installé sur mon ordinateur. Mais je veux rendre le pouvoir d’amorçage à Ubuntu.

J'ai donc d'abord essayé la réparation de démarrage lancée à partir d'Ubuntu, mais ce n'est pas efficace.

J'ai ensuite essayé d'utiliser efibootmgr:

$ Sudo efibootmgr 
Mot de passe [Sudo] pour xavier : 
BootCurrent: 0004
Timeout: 2 seconds
BootOrder: 0004,0006,0000,0007,0001,0002,0003
Boot0000* Windows Boot Manager
Boot0001* ubuntu
Boot0002  UEFI: IP4 Qualcomm Atheros PCIe Network Controller
Boot0003  UEFI: IP6 Qualcomm Atheros PCIe Network Controller
Boot0004* Fedora
Boot0006* grub
Boot0007* ubuntu

Ensuite, j'ai essayé à la fois sur Ubuntu et Fedora de modifier l'ordre:

$ Sudo efibootmgr --bootorder 0006,0004,0000,0001,0007,0002,0003
BootCurrent: 0004
Timeout: 2 seconds
BootOrder: 0006,0004,0000,0001,0007,0002,0003
Boot0000* Windows Boot Manager
Boot0001* ubuntu
Boot0002  UEFI: IP4 Qualcomm Atheros PCIe Network Controller
Boot0003  UEFI: IP6 Qualcomm Atheros PCIe Network Controller
Boot0004* Fedora
Boot0006* grub
Boot0007* ubuntu

Mais au redémarrage, les modifications que j'ai apportées avec efibootmgr ne s'appliquent pas, et si je redemande efibootmgr pour le bootorder, cela me donnera celui avec Fedora ...

Je pense que le problème peut provenir de différents paramètres que je ne comprends pas vraiment, tels que:

  • Quelle est la difference entre efi boot, grub et grub2
  • Quel est l'impact de secureboot?
  • Quelle est la botte héritée?

Merci à tous ceux qui peuvent me donner un peu d’aide pour obtenir une installation propre.

EDIT: La réponse de Rod Smith me fait comprendre que je peux obtenir plus d'informations avec l'argument -v:

$ Sudo efibootmgr -v
BootCurrent: 0004
Timeout: 2 seconds
BootOrder: 0004,0006,0000,0007,0001,0002,0003
Boot0000* Windows Boot Manager  HD(2,GPT,e0e2d47c-9086-47d6-b1e5-0ec248d9d6f0,0x12c800,0x96000)/File(\EFI\Microsoft\BOOT\BOOTMGFW.EFI)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...3................
Boot0001* ubuntu    HD(2,GPT,e0e2d47c-9086-47d6-b1e5-0ec248d9d6f0,0x12c800,0x96000)/File(\EFI\UBUNTU\SHIMX64.EFI)
Boot0002  UEFI: IP4 Qualcomm Atheros PCIe Network Controller    PciRoot(0x0)/Pci(0x1c,0x3)/Pci(0x0,0x0)/MAC(448a5b4783b6,0)/IPv4(0.0.0.0:0<->0.0.0.0:0,0,0)..BO
Boot0003  UEFI: IP6 Qualcomm Atheros PCIe Network Controller    PciRoot(0x0)/Pci(0x1c,0x3)/Pci(0x0,0x0)/MAC(448a5b4783b6,0)/IPv6([::]:<->[::]:,0,0)..BO
Boot0004* Fedora    HD(2,GPT,e0e2d47c-9086-47d6-b1e5-0ec248d9d6f0,0x12c800,0x96000)/File(\EFI\Fedora\SHIM.EFI)
Boot0006* grub  HD(2,GPT,e0e2d47c-9086-47d6-b1e5-0ec248d9d6f0,0x12c800,0x96000)/File(\EFI\GRUB\SHIMX64.EFI)
Boot0007* ubuntu    HD(2,GPT,e0e2d47c-9086-47d6-b1e5-0ec248d9d6f0,0x12c800,0x96000)/File(\EFI\UBUNTU\GRUBX64.EFI)

Grâce à cela post de Rod Smith, j'ai bien compris le rôle des deux entrées ubuntu. Mais le vers, semble être indésirable car le fichier n'existe pas:

$ ls -a
.  ..  Boot  Fedora  Microsoft  MSI  ubuntu

Je devrais peut-être l'effacer?

J'ai ensuite essayé un ordre différent:

$ Sudo efibootmgr --bootorder 0001,0004,0000,0006,0007,0002,0003

Mais malheureusement, les changements ne fonctionnent pas.

Alors si je comprends bien la réponse de Rod Smith, la solution unique consiste à effacer l’entrée Fedora? Cela poserait peut-être quelques problèmes si je voulais un jour ne garder que Fedora, mais avant cela, cela me permettrait de démarrer sur USBLive?

Merci encore !

bootdual-bootgrub2uefifedora
1
Xavier C.

J'ai enfin, grâce à l'aide de Rod Smith, trouvé une solution pour choisir l'ordre de démarrage que je veux.

Comme il l'a mentionné pour désactiver le démarrage sécurisé, j'ai accédé aux paramètres du bios et, comme prévu, le démarrage sécurisé était déjà désactivé, mais j'ai saisi l'opportunité d'être dans les paramètres du bios/uefi pour changer sans l'ordre de démarrage de efibootmgr. .

Ensuite, j'ai choisi de démarrer d'abord sur un périphérique USB, puis j'ai établi un ordre pour le démarrage sur le disque dur, avec Ubuntu en premier, et tout fonctionne!

Je pense donc clairement que lorsque efibootmgr n’est pas en mesure, pour une raison quelconque, de modifier l’ordre, entrer directement dans les paramètres bios/uefi peut constituer la meilleure option, sans être vraiment difficile.

J'espère que cela pourrait aider les autres.

Merci encore pour votre aide.

Xavier

0
Xavier C.

Je commencerai par répondre aux questions à la fin de votre message:

  • Le démarrage en mode EFI utilise le mode de démarrage natif du microprogramme, tandis que le démarrage en mode BIOS/CSM/legacy utilise le module de support de compatibilité, qui permet de démarrer des chargeurs de démarrage en mode BIOS plus anciens. Voir cette question et ma réponse sur superuser.com pour plus d'informations à ce sujet.
  • GRUB est l’un des plusieurs chargeurs de démarrage en mode EFI pour Linux. (Il existe également des versions de GRUB pour le BIOS et d’autres types de microprogrammes.) GRUB Legacy, alias GRUB 1, n’a jamais été officiellement prise en charge pour EFI, bien que Fedora ait une version fortement corrigée qui est maintenant abandonnée. Ainsi, la plupart des références à GRUB dans un contexte EFI font référence à GRUB 2.
  • Secure Boot est une fonctionnalité EFI en option destinée à améliorer la sécurité du système en empêchant une EFI de lancer des fichiers binaires non signés de manière cryptographique par une autorité de confiance. En principe, cette autorité pourrait être vous; ou ce pourrait être quelqu'un d'autre. En pratique, Microsoft détient les seules clés couramment disponibles pour Secure Boot et contrôle donc le processus. Heureusement, Microsoft signera des fichiers binaires tiers et Ubuntu l’a utilisé pour faire signer à Microsoft un fichier binaire appelé Shim , qui inclut à son tour la clé de Canonical, utilisée pour signer GRUB et le noyau Linux dans Ubuntu. Notez que, lors du double amorçage de deux distributions Linux, Shim de l'une des deux distributions n'inclura pas la clé de l'autre distribution. Ainsi, vous devez enregistrer la clé de l'autre distribution avec la liste MOK (Machine Owner Key), que vous pouvez utiliser avec l'utilitaire MokManager.efi sous EFI. Je pense que l'utilitaire sb-updatevar peut le faire sous Linux également, mais j'ai moins d'expérience. Voir ici pour plusieurs clés dans un endroit pratique; vous aurez besoin des touches .cer ou .der. Voir ma page sur Secure Boot ​​pour plus d'informations à ce sujet.

En ce qui concerne votre problème principal, la commande efibootmgr -o (ou efibootmgr --bootorder) devrait donner le contrôle sur le programme d’amorçage que vous spécifiez. Notez cependant que vous vouliez probablement donner le contrôle à Boot0001 ou Boot0007, pas Boot0006 - Ubuntu utilise le nom ubuntu, pas grub, décrire ses propres entrées de démarrage. Vous pouvez mieux identifier chacun d'eux en tapant Sudo efibootmgr -v, ce qui produit des chemins d'accès complets aux entrées de démarrage (identifiées à l'aide d'identifiants de chemin EFI, longs et complexes, et faisant notamment référence aux partitions GUID nombres que vous pouvez obtenir avec gdisk ou certaines versions de blkid). Ainsi, avant de faire quoi que ce soit, vous voudrez peut-être essayer de modifier l'ordre de démarrage pour lui attribuer la valeur correcte plutôt que de Boot0004.

En pratique, les modifications de efibootmgr échouent parfois à cause de EFI erronés ou de données corrompues dans la NVRAM de la machine (c'est là que sont stockées les données affichées par efibootmgr. Trois solutions à ces problèmes sont couramment utilisées:

  • Effacer les entrées non désirées - La suppression parfois d'une entrée non désirée ou en double, comme dans Sudo efibootmgr -b 0004 -B pour supprimer Boot0004 corrigera un problème. (Vous pouvez ou non vouloir réellement supprimer cette entrée, cependant.) Parfois, vous devrez peut-être supprimer plusieurs entrées de démarrage pour que le système fonctionne à nouveau. Ne supprimez pas les entrées à démarrer. De plus, la plupart des ordinateurs ont des entrées créées par le microprogramme, comme les deux entrées Network Controller de votre sortie. La suppression de ces entrées est généralement déconseillée.
  • Réinitialiser le microprogramme à ses valeurs par défaut - La plupart des EFI offrent la possibilité de réinitialiser tous les paramètres à leurs valeurs par défaut dans l'utilitaire de configuration du microprogramme. (Ce que certaines personnes appellent les "écrans de configuration du BIOS" ou quelque chose de similaire - bien que les EFI ne soient techniquement pas des BIOS, bien que beaucoup de personnes, et même de fabricants, se réfèrent souvent à eux en tant que tels.) L'inconvénient de cette approche est susceptible d'effacer toutes toutes les entrées EFI, ce qui rend le système impossible à démarrer jusqu'à ce que vous utilisiez un disque d'urgence pour restaurer au moins une entrée active.
  • Piggyback votre chargeur de démarrage sur une autre entrée - Cette approche implique de copier ou de déplacer/renommer votre chargeur de démarrage souhaité pour utiliser le nom de fichier de tout ce que l'EFI insiste pour le lancer. Il est généralement utilisé lorsqu'un EFI refuse de lancer autre chose que le chargeur de démarrage Windows. Cela ne devrait donc pas être nécessaire dans votre cas.

Reculant un peu plus loin, je dirai que peu importe le type de GRUB que vous utilisez (celui de Fedora ou celui d'Ubuntu); ce sont essentiellement les mêmes logiciels. Si vous rencontrez des problèmes pour configurer le GRUB de Fedora afin de faire ce que vous voulez, vous pouvez toujours modifier ses paramètres - mais la configuration de OTOH, GRUB 2 est notoirement difficile une fois que vous dépassez des éléments fondamentaux. Pour cette raison, de nombreuses personnes amorçant plusieurs distributions Linux à amorçage double préfèrent disposer d'un chargeur d'amorçage indépendant de la distribution - soit leur propre GRUB, soit quelque chose d'autre. Mon propre gestionnaire de démarrage rEFInd présente plusieurs avantages pour ce type de configuration, tels que l'absence de confiance dans les fichiers de configuration pour détecter les mises à jour du noyau et son indépendance par rapport aux scripts de configuration du système d'exploitation. Cela dit, si vous ne parvenez pas à obtenir efibootmgr de passer d’un GRUB à un autre, vous risquez également d’avoir du mal à lancer rEFInd (ou tout autre chargeur d’amorçage). De plus, si vous utilisez Secure Boot, vous devrez peut-être enregistrer au moins une clé Secure Boot auprès de votre MOK pour que la fonction rEFInd fonctionne. D'ailleurs, si vous voulez passer à GRUB d'Ubuntu parce que GRUB de Fedora ne lancera pas les noyaux d'Ubuntu, le problème est probablement le démarrage sécurisé; l'ajout de la clé de démarrage sécurisé pour Canonical/Ubuntu devrait permettre de résoudre ce problème.

EDIT:

Boot0001 est l'entrée qui est la plus susceptible de faire ce que vous voulez, elle doit donc être placée au début de votre liste de démarrage. mais il semble que cela ne fonctionne pas pour vous.

Si vous parvenez à laisser Fedora en charge du processus de démarrage, il serait peut-être préférable de le faire, sinon vous risqueriez de créer une cascade de nouveaux problèmes. Certes, supprimer complètement l'entrée de Fedora est risqué, car si vous ne pouvez plus rien faire fonctionner, vous risquez de ne plus pouvoir démarrer.

Vous pouvez essayer en désactivant Secure Boot, en supposant qu’elle est actuellement activée, car cette fonctionnalité peut poser des problèmes, en particulier pour les configurations complexes.

1
Rod Smith