Instalando GRUB2 en una partición GPT dedicada

English version:Install GRUB2 on GPT disk with dedicated partition


Cuando se va a iniciar la configuración de una máquina x86 desde cero, deben tomarse en consideración las siguientes cuestiones:

• ¿Que uso le vamos a dar al equipo?
• ¿Soporta BIOS UEFI?
• ¿Va a estar dedicada a un solo sistema Operativo, o se pretende alojar múltiples S.Os?
• ¿Que gestor de arranque se quiere utilizar?.
• ¿Como asignar el espacio en disco?.
  
  

En mi último portátil para pruebas, preparé una tabla de particiones GPT con tamaños homogéneos y a continuación instalé GRUB2 como bootloader independiente. Esta configuración me permite una gran flexibilidad a la hora de asignar espacio de almacenamiento y aísla los diferentes S.Os instalados.

La elección de GRUB2 casi resulta obvia, es el bootloader por defecto de una gran cantidad de distribuciones Linux, gestiona prácticamente todos los sistemas de archivos, puedes arrancar directamente casi todos los S.Os, o bien, encadenar otro bootloader que arranque el S.O -esta es mi opción preferida-.

Vamos a revisar el proceso de puesta en marcha que he realizado. 

Selecciona una Distribución

Para comenzar es necesario disponer de una imagen iso de vuestra distribución linux favorita que lleve GRUB2 -casi todas- En mi caso yo me decanto por ArchLinux

 

Revisa la BIOS

Otra cuestión que hay que considerar es si el ordenador que se pretende configurar tiene una BIOS clásica o UEFI. Es conveniente antes de comenzar a instalar familiarizarse con la BIOS y tener claras las características de la misma.

Asegúrate de disponer de la última actualización de firmware, las BIOS UEFI están plagadas de problemas.

Para instalar la versión de GRUB2 que arranca en modo UEFI es necesario iniciar Linux desde un bootloader en modo UEFI, por tanto hay que verificar que el arranque UEFI está habilitado en BIOS y que desde el menú de arranque se detecta correctamente en el medio de instalación -CD o USB- la ubicación por defecto del bootloader EFI/BOOT/bootx64.efi.

Para comprobar que el kernel de linux está iniciado con soporte UEFI se ejecuta: 

# modprobe efivars
# ls -la /sys/firmware/efi/efivars

Si no existe el directorio, Linux no ha arrancado en modo UEFI.

En mi caso he descartado el modo UEFI por los bugs encontrados en la BIOS de mi portátil y la falta de actualizaciones en la web.

Tampoco me resulta problemática esta renuncia: pues en mi caso el interés en emplear el modo UEFI radica en poder arrancar desde el disco con particiones GPT, cosa que puedo hacer con GRUB2 sin necesidad de emplear el modo UEFI.

Definiendo las Particiones

Una vez arrancado Linux e iniciado una shell procedemos a generar las particiones GPT; para ello puede utilizarse parted o gdisk, personalmente yo utilizo gdisk.

Para definir la tabla de particiones he seguido los siguientes criterios:

1. Generar todas las particiones antes de empezar a instalar los S.Os.
2. Asignar una partición por S.O, donde situamos los directorios estándar , y si es preciso, utilizar particiones adicionales para datos.
3. Utilizar particiones de tamaño homogéneo, para S.O y datos. Caso aparte son las particiones “especiales” que procuro situar al principio o al final del disco.
4. Alinear las particiones en limites de 4 KB. En la actualidad los discos utilizan sectores físicos de 4 KB aunque a nivel lógico aún se representan a los S.O como sectores de 512 bytes.
5. Dejar “burbujas” de 128 MB de tamaño, como espacio sin asignar, entre las particiones dedicadas a S.O y/o datos.

Para un estudio en mayor detalle de como generar particiones GPT recomiendo este sitio.

Yo utilizo este esquema de particiones:

 

Tabla de particiones GPT

  
Vamos a revisar la tabla GPT: 

• Partición 1: Está definida como “BIOS Boot Partition” que es utilizada por GRUB2 para albergar su segunda etapa en instalaciones BIOS con soporte para particiones GPT. Alternativamente si se realiza una instalación UEFI, a la primera partición se le asignan unos 200-256 MB, se formatea como FAT32 y se configura como ESP.

• Partición 2: Está definida como partición Linux y formateada como ext2. Alberga la instalación GRUB2 independiente y algunas herramientas de diagnóstico que pueden ser lanzadas desde el menú de GRUB2, en cierto modo realiza una función similar a la partición ESP en instalaciones UEFI.
• Partición 3: Esta es una partición reservada por Microsoft que he dejado reparada para futuras pruebas.
• Partición 4: He reservado esta partición para futuras pruebas, para S.O de Microsoft.
• Partición 5-9: Dedicadas para instalar distintos S.Os o datos.
• Partición 11: Partición swap para linux.
• Partición 12-17: Dedicadas para instalar distintos S.O, o datos.
• Partición 18: Está reservada como partición de datos formateada como NTFS, destinada para compartir información entre los distintos S.O, y almacén de datos.
• Partición 19: Esta es un área auxiliar para almacenar imágenes ISO, o scripts para automatizar instalaciones.

Partición swap

La Partición swap requiere unas consideraciones adicionales; tradicionalmente la situación y tamaño del swap eran decisiones que tenían bastante relevancia a la hora de instalar un S.O como UNIX/Linux. Hoy en día esto ya no es así, pues con las grandes cantidades de RAM disponible y posibilidad de definir archivos de paginación dentro de los sistemas de ficheros se puede incluso prescindir de su uso. 


Incluir una partición swap a mitad del disco no resulta muy estético, pues rompe la armonía de las particiones de tamaño homogéneo, pero tiene sus ventajas:

• Las primeras 7 particiones conviene reservarlas para los gestores de arranque y/o S.Os que requieren estar en posiciones muy especificas de la tabla de particiones -Windows, Solaris,etc-. 
• Por otra parte se reduce, en promedio, la distancia que los cabezales del disco tienen que viajar desde/a la partición activa a la partición swap.
• Por último, el situar el swap al final del disco penaliza los tiempos de acceso, pues esta suele ser la zona “mas lenta” del disco por lo que debe evitarse.

 
Tamaño de las particiones

Con el propósito de mantener la homogeneidad de los tamaños de partición, podía haber configurado un swap de 32 GB, lo cual me parece a todas luces un desperdicio de espacio -mi portátil tiene 4 Gb de RAM ampliables a 8 GB-.
También podía utilizar particiones homogéneas de tamaño inferior – por ej: 8 GB-, pero esta decisión me complicaría innecesariamente la gestión del almacenamiento, creo que 32 GB es un buen compromiso para tener un S.O que resulte “funcional”.

 

Instalando GRUB2

Una vez definida la tabla de particiones, poniendo especial cuidado en definir la  “BIOS Boot Partition”, el siguiente paso es instalar GRUB2; para ello efectuamos los siguientes pasos:

1. Formateamos la partición donde va a residir GRUB2. 
   # mkfs.ext2 /dev/sda2

2. Montamos el filesystem en /mnt. 
   # mount /dev/sda2 /mnt

3. Ejecutamos el comando grub-install con las siguientes opciones:

# modprobe dm-mod 
# grub-install --target=i386-pc --root-directory=/mnt --recheck --debug /dev/sda

4. Generamos el archivo grub.cfg. 
   # grub-mkconfig -o /mnt/boot/grub/grub.cfg

5. Desmontamos y reiniciamos.
   # umount /mnt
   # shutdown -r now

Llegados a este punto si al arrancar aparece el menú de GRUB2 ya podemos comenzar a instalar S.Os.

Menú de Arranque de GRUB2

Aquí os dejo un fragmento de mi actual grub.cfg. Tengo que decir que aunque lo recomendado es actualizar el fichero grub.cfg con grub-mkconfig, yo simplemente edito el fichero para añadir las nuevas entradas.

// COMIENZA EL FRAGMENTO

### END /etc/grub.d/41_custom ###

menuentry "ubuntu 12.10 Home Work" {

search --no-floppy --fs-uuid --set=root 619329d2-78bb-4e2a-b834-81d25c847552

chainloader +1

}

menuentry "LinuxArch desarrollo" {

search --no-floppy --fs-uuid --set=root a83902d4-e64b-4704-9015-5432acd53474

chainloader +1

}

menuentry "FreeBSD 9" {

search --no-floppy --fs-uuid --set=root e68f8f2993d44252

kfreebsd /ROOT/r243825/@/boot/zfsloader

}

menuentry "Memory test (memtest86+)" {

linux16 /boot/memtest86+.bin

}

// FIN DE FRAGMENTO

En principio esta configuración no tiene ningún misterio, mi enfoque es utilizar la instalación independiente de GRUB2 para seleccionar el S.O que pretendo iniciar y transferir el control al loader correspondiente instalado en cada partición junto con el S.O.

Mas detalles sobre GRUB2 en este sitio.

 

Consideraciones sobre los S.Os instalados

Todos los S.Os instalados utilizan el método de UUIDs para identificar sus particiones en el arranque y la especificación de los puntos de montaje en el fichero /etc/fstab. Es un método altamente recomendable al desvincular la identificación de una partición de su posición en la tabla de particiones; esto permite, por ejemplo,reordenar las particiones sin que afecte al proceso de arranque.

 

Ubuntu

Como es bien sabido su bootloader por defecto es el propio GRUB2, así que parece un tanto redundante en este caso el enfoque adoptado. Siempre se puede añadir las opciones de arranque del fichero grub.cfg de Ubuntu al grub.cfg principal -a la larga requiere mayor esfuerzo de administración-. Alternativamente se puede sustituir el comando chainloader +1 por el comando configfile /boot/grub/grub.cfg. Este enfoque permite mantener la simplicidad del archivo grub.cfg principal y al mismo tiempo se accede a las opciones generadas durante la instalación de Ubuntu.


ArchLinux
Con esta distribución utilizo syslinux como loader por su simplicidad y robustez. A continuación muestro un fragmento del fichero de configuración /boot/syslinux/syslinux.cfg donde se muestra la nomenclatura para utilizar UUID:

// COMIENZA EL FRAGMENTO

LABEL arch

MENU LABEL Arch Linux

KERNEL ../vmlinuz-linux

APPEND root=UUID=a83902d4-e64b-4704-9015-5432acd53474 ro

INITRD ../initramfs-linux.img

//FIN DE FRAGMENTO

Mas detalles sobre syslinux en este sitio .

 

FreeBSD

Esta instalación de FreeBSD utiliza ZFS para el root filesystem sobre disco GPT. El gestor de Arranque propio de FreeBSD tiene 3 componentes; su propio “protective MBR”, gptzfsboot que requiere una partición independiente al estilo de la "BIOS Boot Partition" de GRUB2 y por último zfsloader que carga el kernel de freeBSD. La función de los dos primeros componentes la asume GRUB2 que invoca directamente a zfsloader y éste gestiona la carga de freeBSD. También puede realizarse la carga de freeBSD desde GRUB2, aunque encuentro el primer método mas conciso y limpio. Para una discusión de ambos métodos podéis visitar este sitio.

Como apunte final para FreeBSD sobre ZFS el comando blkid muestra incorrectamente el UUID de la partición, por tanto se debe obtener el UUID desde de linea de comandos de GRUB2 con el comando ls.

UUID de la partición bajo ZFS reportado desde blkid

UUID de la partición bajo ZFS tal y como se ve desde GRUB2