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

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:

• ¿Cómo recrear la partición de arranque EFI?

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.

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.

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.

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.

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.

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.

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.

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.