Pourquoi la plupart des distributions chaînent-elles UEFI et grub?

La plupart des distributions installent un chargeur de démarrage supplémentaire sur un système UEFI. UEFI lui-même est un chargeur de démarrage, il propose un menu pour sélectionner différents systèmes d'exploitation ou noyaux individuels. De plus, les paramètres UEFI peuvent facilement être modifiés avec des outils de l'espace utilisateur comme efibootmgr.

Les noyaux depuis 3.3 prennent en charge EFI_STUB, ce qui signifie que le noyau peut être chargé directement à partir de l'UEFI. Quelle est la raison pour laquelle les distributions décident d'utiliser un chargeur de démarrage supplémentaire? La plupart des didacticiels sur Linux / UEFI se concentrent principalement sur la façon de configurer le chargeur de démarrage supplémentaire (rEFInd, grub2, ELILO, etc.) au lieu de démarrer Linux avec EFI_STUB.

La seule chose qui manque dans les distributions est le support. Comme la plupart des distributions chaînent un deuxième chargeur de démarrage, le noyau n'est pas ajouté au menu de démarrage UEFI, ni copié sur la partition système EFI.

Trois scripts suffisent pour faire toute la magie. Celui qui copie les initramfs sur l'ESP. Un second copie le noyau dans l'ESP et crée une nouvelle entrée dans le menu de démarrage UEFI. Le troisième script supprime l'ancien noyau et initramfs de l'ESP et supprime l'entrée du menu de démarrage UEFI. Cela permet des mises à jour / purges entièrement automatisées du noyau / initramfs sans interaction de l'utilisateur. J'utilise cette approche depuis plus d'un an et elle a parfaitement fonctionné.

Pourquoi la plupart des distributions utilisent-elles grub au lieu de EFI_STUB?

Liens:

• Comment recréer la partition de démarrage EFI?

EDIT: Je ne parle pas de supprimer complètement le support de grub, mais d'offrir un choix à ceux qui souhaitent l'utiliser pour diverses raisons. Les distributions pourraient fournir un package grub-efipour ceux qui veulent chaîner UEFI et grub et un package efistub-bootcontenant les scripts que j'ai mentionnés ci-dessus.

Étant donné que l'UEFI n'a été défini qu'en 2005, il existe un tas d'équipements hérités qui ne prennent pas en charge la spécification. Pour ajouter UEFI à une distribution standard, il faudrait tester deux chemins de code au lieu d'un, et non seulement le code de démarrage est notoirement délicat, mais c'est l'un des bits de code les plus irritants à tester.

Les discothèques ont des ressources limitées et il ne peut y avoir aucune raison au-delà. Il peut être raisonnablement simple et sûr, mais peu importe ce qu'il nécessitera plus de travaux de maintenance car l'option grub doit être maintenue, ne serait-ce que pour les systèmes non UEFI.

Je suis sûr que tout le monde a une liste de fonctionnalités et d'options qu'ils aimeraient voir les distributions adopter (je vais vous donner quelques pages, lol), et sans aucun doute beaucoup d'entre elles seraient "totalement faciles, sans tracas, honnêtement. .. ". Cependant, il n'y a pas une quantité infinie d'heures-personnes pour les mettre en œuvre. Face à des décisions comme celle-ci ("Devons-nous mettre du travail dans cette fonctionnalité, par rapport à d'autres?"), Les questions principales doivent être:

• Est-ce nécessaire? (La réponse ici est non).
• Combien de personnes en bénéficieront et combien? (OMI: quelques-uns et pas beaucoup)
• Existe-t-il une alternative raisonnable par laquelle l'utilisateur peut s'adapter à lui-même sans que nous fassions quoi que ce soit? (Apparemment, il y en a un.)

La raison pour laquelle les gens utilisent des distributions est parce que tout le monde est soumis à des contraintes de ressources (sinon, embauchez simplement une équipe, achetez-leur de l'espace et du matériel et demandez-leur de faire tout pour vous exactement comme vous le souhaitez). La réalité est donc que les distributions reflètent les besoins généralisés de leurs utilisateurs.

Cela dit, je pense que cette option sera adoptée avec le temps et j'ai voté pour la question.

Cibler les chargeurs de démarrage UEFI en plus de grub compliquerait le contrôle qualité et le support. Les distributions ciblent grub plutôt que la spécification UEFI car grub est un logiciel libre, piratable, plus flexible et de haute qualité. Vous pouvez toujours obtenir un démarrage pur UEFI en suivant un didacticiel et en montant la partition UEFI /boot, car si vous faites cela, la maintenance est sur vous.

Le vrai problème est que les gens ne comprennent pas comment cela fonctionne. Par exemple, dans votre question, vous mentionnez que trois scripts sont tout ce qui est nécessaire, et la plupart des réponses ici concernent tout / tout entretien supplémentaire qui serait nécessaire pour le faire fonctionner - mais la vérité est que vous n'avez pas besoin de ces scripts ou tout travail supplémentaire.

Tout ce dont vous avez besoin est de lier le montage de l'ESP - ou partout où vous souhaitez conserver le noyau - /boot, ce que vous pouvez faire avec une seule ligne /etc/fstab. Faites cela et tous les scripts de mise à jour du noyau actuels continueront simplement de fonctionner.

Mon `/ etc / fstab 'ressemble à:

LABEL=ESP /esp vfat defaults 0 2
#
#^ i like a separate mount point - not necessary though
#
/esp/EFI/arch_root /boot none bind,defaults 0 2
#
#^ i keep separate installations in separate directories
#

Cependant, il y a un bon point sur les paramètres spécifiques au fabricant. UEFI explicitement ne pas spécifier l'interface pour un menu de démarrage. C'est à gagner et ne sera pas cohérent entre les machines. C'est ennuyeux, mais c'est vrai.

Et donc, alors qu'un chargeur tel que grubréellement ne fait que pour plus de travail, une application de menu - telle que rEFInd - égalise les différences et simplifie tout.

Ils enchaînent l'UEFI et GRUB en tant que solution de mise en œuvre temporaire.

À mesure que le support UEFI et les problèmes qui l'accompagnent (par exemple Secure Boot) sont résolus, de plus en plus de distributions l'utiliseront directement. En attendant, c'est encore très nouveau: Google Trends montre une adoption plutôt limitée: http://www.google.com/trends/explore?q=cannot+boot+uefi#q=uefi%2C%20%20efi%2C % 20% 20bios & cmpt = q

D'autres ont tous mentionné des pièges potentiels pour opter pour une solution UEFI pure et / ou prendre en charge simultanément des systèmes non UEFI et des systèmes UEFI purs. Un noyau UEFI peut fonctionner sur un système non UEFY, mais les outils de mise à jour du noyau doivent mettre à jour soit un menu GRUB OU un menu de démarrage UEFI OU les deux, etc. etc.

Il s'agit vraiment du contrôle de la qualité, comme mentionné: les problèmes avec ce code ont un impact important: lorsque l'ordinateur ne parvient pas à démarrer de nouveaux utilisateurs, c'est-à-dire des convertis potentiels de Linux, il les abandonnera comme des ordures et reviendra à quelque chose de "sûr".

Mais comme je l'ai dit, au fur et à mesure que la technologie gagne en popularité, elle deviendra la norme.

Un code supplémentaire est nécessaire pour contourner les bogues du micrologiciel

Lorsqu'elle ne chaîne pas grub, la distribution s'appuie davantage sur le firmware pour démarrer correctement. Comme tout logiciel aura des problèmes, le micrologiciel est également sujet à cela. Maintenant, les distributions Linux devront également écrire pour contourner ces bogues du micrologiciel.

Un cas réel comme exemple. La carte mère Asrock H81 pro BTC P1.80 permet la création d'entrées de menu de démarrage avec efibootmgr. Il peut y avoir plusieurs entrées de menu de démarrage créées, et l'ordre de démarrage peut être modifié à l'aide efibootmgr --bootorder XXXX,YYYY,ZZZZou une option de démarrage suivante temporaire peut être définie à l'aide efibootmgr --bootnext XXXX. Ces deux commandes renvoient une sortie qui vous donne l'idée que l'ordre de démarrage a changé ou que le prochain démarrage s'exécutera, par exemple BootNext: XXXX. Cependant, au redémarrage, le micrologiciel tenace ignore simplement l'option de démarrage nouvellement demandée et redémarre à la BootCurrent:valeur précédente . Un changement permanent d'ordre de démarrage ne peut être effectué qu'à partir de l'utilitaire de configuration du micrologiciel. Et un changement non permanent n'est pas disponible du tout.

Je pense que si le démarrage est effectué uniquement par EFI et que nous supprimons le chargeur de démarrage, cela sera difficile pour les fabricants de matériel informatique et les fabricants de systèmes d'exploitation. Le fournisseur HW aura plus de noyaux à tester tandis que pour les entreprises qui font des OS, ce sera comme si leur noyau est chargé par un FW différent.

De plus, avec le démarrage direct du noyau depuis EFI, où dans la pile le démarrage sécurisé conviendra-t-il? Dans le scénario actuel, une fois le contrôle envoyé au chargeur de démarrage du système d'exploitation, le chargeur de démarrage vérifie si le noyau est signé correctement ou non. Dans le cas où nous chargeons le noyau directement depuis EFI, je pense que cela ne créera de gâchis que lorsque la pile entière sera perturbée. Juste une opinion de ma compréhension.