¿Cómo verificar en qué unidades grub2 ha instalado realmente un MBR?

Estoy en un sistema Debian / Squeeze (con un historial que se remonta al menos a Woody) que se actualizó a grub2 como parte de la actualización de Squeeze. Todo funciona bien, pero estoy a punto de meterme con la configuración del disco.

Actualmente, la máquina funciona con 2 unidades de 80 GB con particiones RAID1-ed /, / home y / boot (hay otro par de unidades con un "/ data" RAID1-ed y un par de intercambios, en caso de que alguien se preguntara dónde está el intercambio , pero no estoy tocando esos).

Agregué 2 SSD de 130 GB, los particioné para que sean al menos tan grandes como las particiones de las unidades de 80 GB, y tengo la intención de cambiar a las nuevas unidades SSD haciendo crecer los RAID1 para incluirlos, esperando la sincronización y luego eliminando los viejos unidades de los arreglos, por lo que solo quedan los SSD (y luego el crecimiento de los sistemas de archivos). Pero la disputa mdadm / ext3 no es de lo que se trata esta pregunta ...

Eso me dejará con 2 unidades obsoletas de 80GB (IDE) que quiero eliminar de la máquina. Mi preocupación es que eliminarlos llevará un MBR crucial con ellos. ¿Cómo me aseguro de que la máquina siga siendo de arranque?

Más específicamente:

• Cuando realicé la actualización de Squeeze, recuerdo que se presentaron algunas opciones sobre a qué unidades se debe instalar grub2 (elegí la predeterminada, que era todas las unidades). Sin embargo, los SSD no estaban en la máquina en ese momento; ¿Cómo puedo volver a ejecutar esto para que Grub se instale en los SSR MBR? (Supongo que es una reconfiguración dpkg de algún paquete).

• ¿Cómo puedo encontrar en qué unidades cree que está instalado grub2? ¡Qué pena que haya casi 200 archivos en / boot / grub / en estos días! Donde mirar Además, parece un poco extraño que /boot/grub/device.map.auto solo enumere 3 unidades actualmente (2 de los 80 GB pero solo uno del otro par de unidades, y ninguna de las SSD). ¿Cómo lo actualizo? ( Actualización: que era un arenque rojo; device.map.auto parece ser una reliquia de hace años; device.map parecía razonable en una actualización de grub-mkdevicemap. Creo que mi paranoia en esta área se origina en un BIOS de mobo antiguo que podría reordenar el orden del dispositivo visto por GRUB por capricho).

Resultado: todo salió bien y ahora tengo las dos antiguas unidades IDE de 80 GB listas para usar, y un sistema de arranque rápido y rápido que funciona con SSD RAID1 ed con todos los sistemas de archivos redimensionados a sus nuevos tamaños de partición. La otra "pieza faltante del rompecabezas de Grub" que estaba buscando era dpkg-reconfigure grub-pcqué indica qué discos mantener un MBR. La respuesta de Aaron realmente hizo más para asegurarme que esto estaba funcionando como se esperaba, por lo tanto, aceptó esa respuesta.

El MBR es de 512 bytes, por lo que es una forma rápida de ver si GRUB está allí ...

dd if=/dev/sda bs=512 count=1 | xxd

Eso arroja el MBR, veo "GRUB" en el mío en el byte 0x17F = 383.

dd if=/dev/sda bs=1 count=4 skip=383

Cuando hago eso, imprime ' GRUB' seguido de la ddsalida.

Puede envolverlo en un forbucle bash o algo para pasar por más unidades. si no quieres hacerlo manualmente.

Hay varios pasos en el proceso de arranque (estoy describiendo un BIOS de PC tradicional):

1. El BIOS lee el primer sector (512 bytes) del disco de arranque.
2. El código en este primer sector lee más datos y código en una ubicación fija a través de la interfaz del BIOS. Esta interfaz de BIOS solo expone dos discos duros: el disco 0 es donde se leyó el primer sector, y el disco 1 es otro disco que no es fácilmente predecible si tiene más de dos. El sector de arranque contiene un byte que indica en qué disco duro están los datos adicionales; Este es el disco que contiene /boot/grub.
3. El código cargado en la etapa anterior comprende particiones, sistemas de archivos y otras nociones de alto nivel. Los datos incluyen una ubicación del sistema de archivos (es decir, una cadena similar (hd0)/boot/grub) que determina dónde encontrar grub.cfgy más módulos Grub.
4. grub.cfg se ejecuta, generalmente para mostrar un menú y arrancar un sistema operativo.

El sector de arranque es generado por grub-setup, normalmente invocado a través de grub-install. El sector de arranque termina en cualquier disco que haya especificado (en la sintaxis de Linux) en la línea de comando grub-installo grub-setup. Puede verificar que tiene un sector de arranque en un disco ejecutando file -s /dev/sda. Como está agregando un nuevo disco y desea arrancar desde él, debe ejecutarlo grub-installen el nuevo disco. Ejecutar grub-installvarias veces en el mismo disco es inofensivo.

La parte difícil está en el paso 2 anterior. Si es posible, coloque Grub (es decir, el /boot/grubdirectorio) en el disco de arranque del BIOS (o, acercándose a esto desde la otra dirección, dígale a su BIOS que arranque desde el disco donde /boot/grubestá). Aquí es donde device.mapentra en juego. Asegúrese de que (hd0)esté asignado al disco que contiene /boot/grub, luego ejecútelo grub-installen ese disco.

Si sus dos discos están en una configuración RAID-1 de software, tendrá sectores de arranque idénticos. Este es el comportamiento deseable: si el disco que es el disco de arranque del BIOS falla, el arranque desde el otro simplemente funcionará (ya que contienen los mismos bytes en las mismas ubicaciones relevantes). Si solo ha reflejado ciertas particiones, la instalación de un sector de arranque solo afecta a uno de los discos. Debe ejecutar grub-installnuevamente en el segundo disco, después de cambiar device.mappara asociarlo (hd0)con el disco que contiene la segunda copia reflejada de /boot/grub.

El paso 3 es bastante complejo, pero generalmente funciona fuera de la caja. En el paso 4, Grub localiza los sistemas de archivos por UUID o busca archivos con nombre, por lo que ya no necesita preocuparse por las diversas formas de designar discos.