El problema
Tengo una máquina que arranca en Arch Linux desde un volumen Btrfs RAID10 de ocho discos. Recientemente, reinicié y aparecí en este mensaje de rescate de GRUB:
No estoy seguro de qué desencadenó esto exactamente. Desde el último inicio, instalé actualizaciones ( pacman -Syu) al menos dos veces y es posible que haya realizado otros cambios en el sistema, incluida la reinstalación de GRUB.Puedo iniciar el sistema si agrego un disco de arranque dedicado.
La teoría
Mientras solucionaba problemas con un útil miembro del canal IRC #archlinux, me encontré conesta nota en la wiki de Arch:
Desplazamiento de partición
El problema de compensación puede ocurrir cuando intenta incrustar core.img en un disco particionado. Significa que está bien incrustar core.img de grub en un grupo Btrfs en un disco sin particiones (por ejemplo, /dev/sdX) directamente. GRUB puede iniciar particiones Btrfs, sin embargo, el módulo puede ser más grande que otros sistemas de archivos. Y es posible que el archivo core.img creado por grub-install no quepa en los primeros 63 sectores (31,5 KB) de la unidad entre el MBR y la primera partición. Las herramientas de partición actualizadas, como fdisk y gdisk, evitan este problema al compensar la primera partición en aproximadamente 1 MiB o 2 MiB.
Esto parece decir que puede haber problemas al instalar GRUB en archivos particionados.ydiscos sin partición que las nuevas herramientas de partición mitigan (por ahora) dejando espacio adicional al principio del disco.
La página wiki de GRUB es más directa.:
Instalar en partición o disco sin partición
Advertencia:COMIDAdesaconseja fuertementeinstalación en un sector de arranque de partición o en un disco sin particiones como lo hace GRUB Legacy o Syslinux. Esta configuración es propensa a fallar, especialmente durante las actualizaciones, y esNo soportadopor los desarrolladores de Arch.
Bueno, caray.
Por si sirve de algo, grub-install -vincluye esta línea en su salida:
grub-install: info: the total module size is 0xa07c.
Eso es ~41K, sólidamente por encima del límite de 31,5KiB mencionado anteriormente, pero no conozco GRUB lo suficientemente bien como para estar seguro de que esta es la causa de mis problemas.
Las preguntas
Si estoesEl problema, ¿cómo puedo probarlo y,
grub-installde ser así, por qué no falla estrepitosamente?¿Cuál es la forma correcta de formatear discos Btrfs de arranque en el futuro? ¿MBR? GPT? – un disco de arranque dedicado es tentador, pero me gusta tener un gestor de arranque redundante en cada dispositivo del volumen.
¿Existe una forma mejor de migrar cada disco a una tabla de particiones que borrar y ejecutar
btrfs replacecada disco?
Respuesta1
En el pasado, crear una tabla de particiones MBR con, por ejemplo, fdisk, dejaría por defecto los primeros 63 sectores intactos. Ahí es donde se podrían instalar GRUB y otros gestores de arranque.
Si avanzamos rápidamente hasta la actualidad, la misma herramienta (fdisk) deja más espacio sin utilizar; suficiente para que GRUB2 instale su etapa 1 con soporte BTRFS. Creo que el desplazamiento es de aproximadamente 1 MB, de forma predeterminada; lo que sea que eso signifique en los sectores.
No sé por qué grub-installno falla, pero supongo que no verifica el tamaño del sector de arranque; y sin particiones como podría.
No veo ningún problema en tener gestores de arranque redundantes. Tienes que gestionarlo manualmente, pero la etapa 1 de GRUB2 no cambia con frecuencia. Pero significa que necesitarías particiones.
No conozco ninguna herramienta que pueda migrar el disco para agregar una tabla de particiones. El problema es que el sistema de archivos está vinculado a sectores del disco y agregar una tabla de particiones cambia esos sectores. Si sus sistemas de archivos BTRFS estuvieran en LVM, entonces sí, podría mover cosas porque el sistema de archivos estaría vinculado a "sectores virtuales". No digo que debas hacer eso, solo ilustra cuál es el problema.