¿GRUB es la mejor solución de carga de arranque? ¿Hay una alternativa más fácil?

He tenido algunas experiencias bastante malas con GRUB2. Podría decir (y he dicho) algunas cosas desagradables sobre su proceso de diseño y desarrollo. Me disgusta especialmente su medio de actualización: por cualquier razón, debe actualizar semiautomáticamente varios scripts, uno indirectamente a través de otro en una cadena, para cada actualización del kernel, o muchas otras alteraciones de configuración menores (y aparentemente no relacionadas) .

Esto se contrasta directamente con las experiencias previas que tuve LILO, a las que estoy considerando seriamente revertir, ya que nunca tuve problemas con él, y su configuración fue bastante simple. Por un lado, como lo recuerdo, solo tuve que actualizar (o, mejor dicho, solo se actualizó) un solo archivo de texto de configuración administrado de manera simple por actualización de kernel.

Entonces, ¿cómo funciona LILO en el hardware moderno con los núcleos actuales? ¿Cómo funciona GRUB? ¿Cómo funcionan otros cargadores de arranque? ¿Tengo que cumplir alguna condición previa, o solo se trata de escribir el archivo de configuración y ejecutar el lilocomando como lo recuerdo con cariño en los viejos tiempos? ¿La actualización del paquete del núcleo (Debian / Ubuntu) actualiza LILO como lo hace con GRUB2?

ELILO

Gestión de cargadores de arranque EFI para Linux: uso de ELILO

Es realmente difícil para mí decidir qué parte de eso copiar + pegar porque todo es realmente bueno, así que solo les pediré que lo lean.

Rod Smith

Creado y mantiene ambos gdisky rEFInd.

Pero antes de hacerlo, me gustaría comentar un poco al respecto. El enlace de ELILO anterior es una de las muchas páginas sobre arranque UEFI que encontrará en rodsbooks.com escrito por Rod Smith. Es un escritor técnico consumado, y si alguna vez buscó en Google el tema del arranque de UEFI y terminó sin leer algo suyo, probablemente fue porque se saltó los primeros resultados.

Arranque UEFI Linux

Básicamente, el núcleo de Linux puede ser ejecutado directamente por el firmware.

En el enlace anterior, menciona el cargador de código auxiliar EFI del kernel de Linux : en mi opinión, esto es lo que debería usar, ya que permite que el firmware llame directamente al kernel de Linux. Independientemente de lo que esté haciendo, el firmware está ejecutando algo , y parece que algo lo está haciendo grub. Si el firmware puede cargar directamente su kernel os, ¿de qué sirve un gestor de arranque? El firmware UEFI monta una partición GPT con formato FAT marcada especialmente por la tabla de particiones y ejecuta una ruta allí que ha guardado como una variable de arranque UEFI en un módulo de memoria flash integrado. Entonces, una cosa que puede hacer es colocar el kernel de Linux en esa partición FAT y almacenar su ruta en esa variable de arranque. De repente, el núcleo es propio. cargador de arranque

Cargadores de arranque

En los sistemas UEFI, los gestores de arranque son redundantes, incluido ELILO.

El problema que los cargadores de arranque fueron diseñados para resolver fue que los sistemas BIOS solo leen en el primer sector de la partición marcada de arranque y la ejecutan. Es un poco difícil hacer algo significativo con un núcleo de 512 bytes, por lo que lo más común es escribir una pequeña utilidad que pueda montar un sistema de archivos donde guarde el núcleo real y cargarlo en cadena.

De hecho, los 512 bytes a menudo no eran suficientes incluso para los gestores de arranque. grub, por ejemplo, en realidad se carga en cadena antes de cargar en cadena su kernel, ya que encaja en su segunda etapa en el espacio vacío entre el sector de arranque y el primer sector de su sistema de archivos. Es una especie de truco sucio, pero funcionó.

Administradores de arranque

Sin embargo, en aras de una configuración fácil, algunos intermediarios pueden ser útiles.

Lo que hace rEFInd de Rod Smith es lanzarlo como una aplicación EFI : este es un concepto relativamente nuevo. Es un programa que se ejecuta desde el disco por, y que vuelve a, el firmware. Lo que hace rEFInd es permitirle administrar los menús de arranque y luego devolver su selección de arranque al firmware para ejecutar. Viene con controladores de sistema de archivos UEFI , por lo que, por ejemplo, puede usar el cargador EFI-stub del núcleo en una partición que no sea FAT (como su actual /boot). Es muy simple de administrar, si es que tal cosa es necesaria, y agrega la simplicidad de un núcleo del sistema ejecutable a la conveniencia de un administrador de arranque configurable.

Indirección Atómica

El núcleo no necesita enlaces simbólicos, puede mount --bind.

Si hay algún camino en su lugar /donde no debe permitir la simbología, es /boot. Un enlace simbólico huérfano no/boot es el tipo de problema que debería tener que solucionar. Aún así, es una práctica lo suficientemente común como para configurar indirectas elaboradas por varias distribuciones, incluso si es una idea horrible, para manejar actualizaciones de kernel in situ y / o configuraciones de kernel múltiples./boot

Este es un problema para los sistemas EFI no configurados para cargar controladores de sistema de archivos (como los que se proporcionan con el paquete rEFInd) porque FAT es un sistema de archivos bastante estúpido en general, y no los comprende.

No utilizo personalmente los controladores del sistema de archivos UEFI provistos con rEFInd, aunque la mayoría de las distribuciones incluyen un paquete rEFInd que se puede instalar a través del administrador de paquetes y olvidar solo usar su propia /bootconfiguración de enlaces simbólicos y los controladores del sistema de archivos UEFI empaquetados de rEFInd.

Mi config

Una vez escribí un conjunto de instrucciones y lo publiqué aquí , pero parece que:

% grep esp /etc/fstab && 
> ls /esp/EFI

LABEL=ESP          /esp  vfat defaults      0 1
/esp/EFI/arch_root /boot none bind,defaults 0 0 

arch_root/  arch_sqsh/  arch_xbmc/  BOOT/  ipxe/

Así que solo puse esas dos líneas en mi /etc/fstabseñalador a una carpeta que pretendo contener las nuevas instalaciones de Linux /booty casi termino de preocuparme por todo. También tengo que hacer:

cat /boot/refind_linux.conf 

"Arch" "root=LABEL=data rootflags=subvol=arch_root,rw,ssd,compress-force=lzo,space_cache,relatime"

Además de instalar el refind-efipaquete a través pacmandel primero, eso es todo lo que se requiere para configurar tantas instalaciones / configuraciones separadas como desee. Tenga en cuenta que la mayoría de esa cadena de arriba consta de opciones de montaje específicas de btrfs especificadas como parámetros del núcleo. Un más típico /boot/refind_linux.confprobablemente se vería así:

"Menu Entry" "root=/dev/sda2"

Y eso es todo lo que se necesita.

rodsbooks.com

Si aún desea ELILO, puede encontrar las instrucciones de instalación en el enlace de arriba. Si quieres rEFInd encontrarás enlaces a él en el primer párrafo allí. Básicamente, si desea realizar cualquier configuración de arranque UEFI, lea primero rodsbooks.com .

Yo uso LILO en lugar de GRUB2. Para ser honesto, no fue mi elección: la instalación de GRUB2 falló en el instalador de Debian Live CD, pero luego fue la opción de instalar LILO que tuvo éxito. Tengo una laptop de 2 años con Debian Stable. LILO funciona perfectamente para mí.

LILO todavía es utilizable, incluso con BIOS UEFI. UEFI puede cargar el kernel de Linux directamente, generalmente. Sin embargo, esto depende de la UEFI misma.

Sin embargo, si necesita una pantalla de selección de inicio, por ejemplo, si está iniciando en varios sistemas operativos en una máquina, entonces un pequeño gestor de arranque puede ser útil.

Sin embargo, consideraría usar EXTLINUX en su lugar. Es una variante de SYSLINUX, pero reside en extparticiones de tipo.

La belleza de EXTLINUX es que, si bien es más ampliable y tiene muchas más opciones que LILO, puede ser igual de simple y se mantiene activamente.

No recuerdo ningún equivalente de update-grub. Sin embargo, hay un sistema más antiguo que todavía es compatible con Debian. (Se usa para uboot en mi servidor ARM).

El kernel más reciente está enlazado /boot/vmlinuze initrd a /boot/initrd.img. Es actualizado por el paquete del núcleo. El gestor de arranque apunta a esos y desreferencia el enlace simbólico en cada arranque.

Por lo tanto, es posible que no obtenga una opción de recuperación. En cualquier caso, esta no será la opción más ampliamente probada, por lo que es aún más recomendable mantener un disco de arranque que funcione :-).

Actualización: Si su objetivo es algo más que ejecutar literalmente LILO en una computadora moderna, probablemente haya mejores alternativas, como se describe en las otras respuestas aquí :).

Lo anterior solo tiene sentido para la versión original de LILO basada en BIOS. El hardware moderno proporciona compatibilidad de BIOS además de EFI, si no desea un arranque seguro o arrancar Windows 8 desde el mismo menú. Teóricamente, podría hacer que ELILO funcione, pero no admite el arranque seguro o la carga de Windows 8. ELILO ya no tiene sentido en general, por lo que supongo que no hay mucha comunidad detrás.