¿Por qué la mayoría de las distribuciones encadenan UEFI y grub?

31

La mayoría de las distribuciones instalan un cargador de arranque adicional en un sistema UEFI. UEFI es un gestor de arranque, ofrece un menú para seleccionar diferentes sistemas operativos o núcleos individuales. Además, la configuración de UEFI se puede modificar fácilmente con herramientas de espacio de usuario como efibootmgr.

Los núcleos desde 3.3 son compatibles con EFI_STUB, lo que significa que el núcleo se puede cargar directamente desde la UEFI. ¿Por qué las distribuciones deciden usar un cargador de arranque adicional? La mayoría de los tutoriales sobre Linux / UEFI se centran principalmente en cómo configurar el cargador de arranque adicional (rEFInd, grub2, ELILO, etc.) en lugar de arrancar Linux con EFI_STUB.

Lo único que falta en las distribuciones es el soporte. Como la mayoría de las distribuciones encadenan un segundo cargador de arranque, el kernel no se agrega al menú de arranque UEFI, ni se copia a la partición del sistema EFI.

Tres guiones son suficientes para hacer toda la magia. Uno que copia los initramfs al ESP. Un segundo copia el kernel al ESP y crea una nueva entrada en el menú de arranque UEFI. El tercer script elimina el núcleo antiguo y los initramfs del ESP y elimina la entrada del menú de arranque UEFI. Esto permite actualizaciones / purgas de kernel / initramfs totalmente automatizadas sin interacción del usuario. Estoy usando este enfoque desde hace más de un año y ha funcionado perfectamente.

¿Por qué la mayoría de las distribuciones usan grub en lugar de EFI_STUB?

Campo de golf:

EDITAR: No estoy hablando de eliminar el soporte de grub por completo, sino de ofrecer una opción para aquellos que quieran usarlo por varias razones. Las distribuciones podrían proporcionar un paquete grub-efipara aquellos que desean encadenar UEFI y grub y un paquete efistub-bootque contenga los scripts que mencioné anteriormente.

boot grub2 boot-loader uefi Marco
fuente
44
¿Por qué deberían ellos? Ya han establecido métodos para tratar / generar archivos de configuración de grub. Además, ayuda si todos los sistemas (no UEFI y UEFI) se comportan igual.
Ulrich Dangel
Suena bien. Pero dado que de acuerdo con ese enlace, puede hacerlo si lo desea, tal vez sea un atolladero potencial para que las distribuciones lo hagan por usted automáticamente. Betcha algunos eventualmente te dará la opción aunque.
Ricitos de Oro
1
@Bakuriu Un sistema más fácil de entender, una secuencia de arranque más simple, un código menos ejecutado y un tiempo de arranque un poco más rápido, por ejemplo.
Marco
44
Esta pregunta debe posponerse, ya que la razón de retención dada es incorrecta. La pregunta tiene una respuesta simple e incontestable: UEFI no proporciona un menú de arranque. Algunas implementaciones lo hacen. Algunos no lo hacen, porque para alcanzar su tiempo de arranque objetivo para Windows 8, el BIOS ni siquiera inicializa los dispositivos de entrada . Y mucho menos esperar para ver si el usuario presiona una tecla. Entonces tendrías que pasar por Windows para llegar a Linux, o viceversa. El primero funciona en algunos sistemas, pero dudo que la especificación lo garantice. Este último no funciona (puede ingresar a la configuración UEFI desde GRUB, pero no desde Linux).
sourcejedi
1
@sourcejedi Usted afirma que no coincide con sus fuentes. UEFI proporciona un menú de arranque (la interfaz de usuario no es coherente entre los proveedores). mjg59 significa que no puede acceder al menú de arranque sin compromiso filosófico (aceptando W8 EULA). Pero este problema será el mismo para los instaladores con gestores de arranque que no sean EFISTUB. Por lo tanto, tampoco responde por qué preferiríamos grub sobre EFISTUB.
Lingzhu Xiang

Respuestas:

10

Dado que UEFI solo se definió en 2005, hay un montón de equipos heredados que no son compatibles con la especificación. Agregar UEFI a una distribución estándar requeriría probar dos rutas de código en lugar de una, y no solo el código de arranque es notoriamente meticuloso, es uno de los bits de código más irritantes que consume mucho tiempo para probar.

msw
fuente
55
La prueba no solo es irritantemente lenta, sino que es el código más irritante que posiblemente salga mal. Considere: ¿qué prefiere, algún tipo de problema mientras el sistema está funcionando y funcionando normalmente, o no puede ni siquiera arrancar el sistema? El cargador de arranque es definitivamente una de las piezas de software que más me gusta de no tocar a menos que sea necesario.
un CVn
El comentario anterior de @ MichaelKjörling debería estar en una respuesta. Cambiar a un nuevo cargador de arranque es muy arriesgado. Los creadores de distribuciones quieren que sus usuarios tengan una buena experiencia, pero más que eso, quieren que cada nuevo usuario potencial tenga una experiencia perfecta por primera vez. Lamento haber llamado "distribución" a la distribución, pero me pareció bien en conjunto con los creadores.
Johan
@Johan msw es libre de editar ese punto en la respuesta, no me importa. (No es suficiente ser una respuesta por sí solo, OMI). Tanto Tobu como goldlilocks también tocan el tema.
un CVn
3

Las distribuciones tienen recursos limitados y puede que no haya ninguna razón más allá de eso. Puede ser razonablemente simple y seguro, pero no importa lo que requiera más trabajo de mantenimiento porque la opción grub debe mantenerse, aunque solo sea para sistemas que no sean UEFI.

Estoy seguro de que todos tienen una lista de características y opciones que les gustaría ver que adopten las distribuciones (te daré algunas páginas, risas), y sin duda muchas de ellas serían "totalmente fáciles, sin problemas, sinceramente". .. ". Sin embargo, no hay una cantidad infinita de horas de persona para implementarlas. Cuando nos enfrentamos a decisiones como esta ("¿Ponemos trabajo en esta característica, en comparación con alguna otra?") Las preguntas principales deberían ser:

  • ¿Es necesario? (La respuesta aquí es no).
  • ¿Cuántas personas se beneficiarán y cuánto? (OMI: unos pocos, y no mucho)
  • ¿Existe una alternativa razonable mediante la cual el usuario pueda acomodarse a sí mismo sin que hagamos nada? (Aparentemente lo hay)

La razón por la que las personas usan las distribuciones es porque todos están sujetos a limitaciones de recursos (de lo contrario, solo contrata a un equipo, cómprales un poco de espacio y equipo, y haz que hagan todo por ti exactamente como quieras). Entonces, la realidad es que las distribuciones reflejan las necesidades generalizadas de sus usuarios.

Dicho esto, creo que con el tiempo esto se adoptará como una opción, y voté por la pregunta.

encerrada dorada
fuente
2

Dirigirse a gestores de arranque UEFI además de grub complicaría el control de calidad y el soporte. Las distribuciones apuntan a grub en lugar de las especificaciones UEFI porque grub es software libre, pirateable, más flexible y de alta calidad. Todavía puede obtener un arranque UEFI puro siguiendo un tutorial y montando la partición UEFI /boot, porque si lo hace, el mantenimiento es suya.

Tobu
fuente
su afirmación de calidad es discutible, pero creo que la razón por la que está dirigida no tiene nada que ver con eso de todos modos. ya tienen miles de líneas de script de shell mal escritas para manejarlo, entonces ¿por qué querrían 20 buenas?
mikeserv
1

El verdadero problema es que las personas no entienden cómo funciona. Por ejemplo, en su pregunta, menciona que tres scripts son todo lo que se necesita, y la mayoría de las respuestas aquí son sobre todo / cualquier mantenimiento adicional que se requeriría para que funcione, pero la verdad es que no necesita esos scripts o cualquier trabajo adicional.

Todo lo que necesita es unir el montaje del ESP, o donde desee mantener el núcleo /boot, lo que puede hacer con una sola línea /etc/fstab. Haga eso y todos los scripts de actualización del núcleo actuales simplemente seguirán funcionando.

Mi `/ etc / fstab 'se ve así:

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
#

Sin embargo, aquí se hace un buen comentario sobre la configuración específica del fabricante. UEFI explícitamente qué no se especifica la interfaz para un menú de arranque. Eso está en juego y no será consistente entre máquinas. Es molesto, pero cierto.

Y así, mientras que un cargador como en grubrealidad solo requiere más trabajo, una aplicación de menú, como rEFInd, iguala las diferencias y simplifica todo.

mikeserv
fuente
1
No entiendo cómo podría funcionar esto. Tenga en cuenta que los nombres de archivo de kernel e initramfs incluyen la versión. Si no hay scripts, arrancará su kernel anterior después de instalar uno nuevo. O dicho de otra manera: ¿Cómo se cambia el kernel predeterminado para que apunte al nuevo? (Mis scripts se utilizan efobootmgrpara actualizar el orden de arranque y cambiar el kernel predeterminado).
Marco
@Marco: bueno, la ruta de inicio predeterminada es, \EFI\BOOT\BOOTX64.efipor lo que podría llamarse así. la UEFI no puede (por especificación) manejar argumentos al núcleo en primer lugar, por lo que la imagen initramfs / kernel debe estar unida en ese caso. pero no sé a qué te refieres con el nombre de la versión: creo que solo los debianos hacen eso, y de todos modos lo considero improductivo. El nombre convencional para su núcleo es vmlinuz. De todos modos, la forma correcta de hacerlo es con un administrador de arranque, no un cargador . Use una aplicación EFI que encuentre su kernel y pase su nombre al EFI para que arranque, como lo hace rEFInd.
mikeserv
Uso Debian y el nombre del kernel es, por ejemplo, el vmlinuz-4.2.0-1-amd64que dejo tal como está y luego lo uso efibootmgrpara agregarlo a la lista de arranque y hacerlo predeterminado. Veo que nombrar el núcleo BOOTX64.efipodría ser una solución. Pero de cualquier manera, necesitaría tener un script para hacerlo y, además, eso no permite mantener fácilmente múltiples núcleos si todos se llaman igual.
Marco
@Marco: no necesita una secuencia de comandos completamente separada; su administrador de paquetes, probablemente apto, ejecutará alguna secuencia de comandos de todos modos cuando se instale un núcleo para construir initramfs. probablemente esté haciendo cientos de cosas allí para calcular el nombre de su kernel, pero solo una línea adicional hará el cambio de nombre a lo que quiera. y puede mantener fácilmente tantos núcleos como desee si mantiene un árbol de arranque . rEFInd lo maneja haciendo que la imagen de arranque predeterminada sea la imagen del kernel modificada más recientemente en sus rutas de búsqueda.
mikeserv
Modificar scripts de stock instalados por el administrador de paquetes es una mala idea. Pueden actualizarse, lo que a su vez borra sus cambios y, en este caso particular, incluso puede dar como resultado un sistema no arrancable. Hay directorios para los scripts de usuario que se invocan después de una instalación kernel / initramfs y que están destinados a ser utilizados exactamente para un propósito como este. Por cierto: estás sugiriendo editar scripts en tus comentarios. Sin embargo, en su respuesta usted declara "no necesita esos scripts ni ningún trabajo adicional", lo cual no es cierto (al menos para Debian).
Marco
0

Encadenan UEFI y GRUB como una solución de implementación temporal.

A medida que se resuelve el soporte de UEFI y los problemas que lo acompañan (por ejemplo, Arranque seguro), cada vez más distribuciones lo usarán directamente. Mientras tanto, esto todavía es muy nuevo: Google Trends muestra una adopción bastante limitada: http://www.google.com/trends/explore?q=cannot+boot+uefi#q=uefi%2C%20%20efi%2C % 20% 20bios & cmpt = q

Otros han mencionado las posibles dificultades de buscar una solución UEFI pura y / o admitir sistemas UEFI puros y no UEFI simultáneamente. Un núcleo UEFI podría funcionar en un sistema que no sea UEFY, pero las herramientas de actualización del núcleo necesitan actualizar un menú GRUB O un menú de arranque UEFI O ambos, etc.

Realmente se trata del control de calidad como se mencionó: lo importante es que los problemas con este código tienen un alto impacto: cuando la computadora no puede iniciar nuevos usuarios, es decir, posibles conversiones de Linux, la abandonará como basura y volverá a algo "seguro".

Pero como dije a medida que la tecnología obtiene más adopción, se convertirá en el estándar.

Johan
fuente
Espero que no, pero eso se debe principalmente a que tengo graves preocupaciones sobre los modos de bloqueo de UEFI y la "promesa" de Microsoft de asegurarme de que siempre habrá una imagen firmada para que Linux use ...
Shadur
0

El código adicional es necesario para evitar errores de firmware

Cuando no se encadena grub, la distribución se basa más en el firmware para arrancar correctamente. Como cualquier software tendrá problemas, el firmware también es propenso a eso. Ahora las distribuciones de Linux también tendrán que escribir para solucionar estos errores de firmware.

Un caso de la vida real como ejemplo. La placa base Asrock H81 pro BTC P1.80 permite la creación de entradas de menú de arranque con efibootmgr. Puede haber múltiples entradas de menú de inicio creadas, y el orden de inicio puede cambiarse usando efibootmgr --bootorder XXXX,YYYY,ZZZZo una opción de siguiente inicio temporal puede establecerse usando efibootmgr --bootnext XXXX. Ambos comandos devuelven la salida que le da la idea de que el orden de inicio ha cambiado o se ejecutará el siguiente inicio, por ejemplo BootNext: XXXX. Sin embargo, al reiniciar, el obstinado firmware simplemente ignora la opción de inicio recién solicitada y se reinicia en el BootCurrent:valor anterior . Un cambio de orden de arranque permanente solo se puede hacer desde la utilidad de configuración de firmware. Y un cambio no permanente no está disponible en absoluto.

Pro Backup
fuente
-2

Creo que si EFI solo se encarga del arranque y eliminamos el gestor de arranque, será difícil tanto para el proveedor de hardware como para los fabricantes de sistemas operativos. El proveedor de HW tendrá más núcleos para probar, mientras que para las empresas que fabrican SO, será como si su kernel está cargado por diferentes FW.

Además, con el arranque directo del kernel desde EFI, ¿dónde encajará en la pila el arranque seguro? En el escenario actual, una vez que el control va al gestor de arranque del sistema operativo, el gestor de arranque comprueba si el núcleo está firmado correctamente o no. En caso de que carguemos el kernel directamente desde EFI, creo que creará desorden solo ya que toda la pila se verá afectada. Solo una opinión de lo que tengo entendido.

shubham
fuente
Eso es tonto. La razón por la que el gestor de arranque comprueba la clave es porque el UEFI no lo hace. la carga en cadena es redundante para el arranque seguro de un kernel firmado. Simplemente verifique la clave en el firmware, la forma en que debería funcionar.
mikeserv