GPT vs MBR: Si eliges mal romperás el arranque — Elige bien con esta regla

febrero 11, 2026 • febrero 11, 2026 • Lectura: 25 min • Views: 0

¿Te fue útil?

Hay pocas sensaciones en operaciones tan puras como la de ver una máquina reiniciarse y quedarse en pantalla negra porque alguien “simplemente redimensionó una partición”. Los datos están bien. Los discos están bien. El sistema no arranca porque elegiste el esquema de particionado equivocado para el firmware y la ruta de arranque.

Este es el tipo de fallo que parece un problema de almacenamiento, se siente como un problema de cargador de arranque y, en realidad, es un problema de decisión. La buena noticia: puedes dejar de adivinar. Hay una regla simple para elegir GPT vs MBR que evita la mayoría de los desastres de arranque—y además un conjunto de comprobaciones que te dicen exactamente con qué estás tratando antes de tocar nada.

La regla: no «elijas», empareja firmware y modo de arranque

Regla práctica que te mantiene fuera de problemas:

Si la máquina arranca en modo UEFI, usa GPT. Crea una partición del Sistema EFI (ESP) e instala el cargador allí.
Si la máquina arranca en modo BIOS heredado, usa MBR. O usa GPT con una partición de arranque BIOS si sabes exactamente por qué lo haces (más abajo hay más detalles).

Esta regla no es ideología. Se trata de hacer coincidir el primer código ejecutable que el firmware espera encontrar con la disposición en disco. Cuando eso no coincide, no recibes “una advertencia.” Obtienes “no hay dispositivo de arranque”, GRUB rescue, o un aviso de recuperación de Windows que finge no haber conocido nunca tu SO.

Hay una restricción adicional que importa aún más que la preferencia personal: si el disco es mayor de 2 TB y necesitas usar todo en un único disco, MBR no sirve. Aún puedes arrancar BIOS desde un disco GPT, pero debe hacerse intencionalmente.

Verdad seca y graciosa: las tablas de particiones son como paracaídas—la mayoría del tiempo solo las notas cuando fallan.

Qué se rompe realmente cuando eliges mal

“Arranque” no es una sola cosa. Es una cadena. Se rompen distintos eslabones según la combinación de firmware, esquema de particiones, SO y cargador de arranque.

MBR: lo que espera

El arranque MBR típicamente espera:

Que el LBA0 del disco contenga un MBR válido con código de arranque ejecutable y una tabla de particiones.
Una partición marcada como “activa/bootable” (para flujos clásicos de BIOS).
Código de arranque que cargue una segunda etapa desde una ubicación conocida (por ejemplo, archivos de GRUB o el gestor de arranque de Windows).

Si imágenes un disco GPT a uno MBR (o viceversa) y olvidas el código de arranque, puedes copiar el 100% de tus archivos perfectamente y aún así tener una cadena de arranque muerta.

GPT: lo que espera

El arranque GPT depende del firmware:

UEFI + GPT: el firmware lee GPT, encuentra la ESP (FAT32), carga un ejecutable EFI desde una ruta registrada en NVRAM o mediante rutas de reserva.
BIOS + GPT: el BIOS no puede leer particiones GPT de la misma manera; GRUB usa una pequeña partición BIOS boot para almacenar datos de su imagen core.

Si eliges mal no obtienes “ligera degradación.” Obtienes “el firmware no puede encontrar el cargador,” lo que parece corrupción de almacenamiento para quien no vigila la cadena de arranque cuidadosamente.

Una cita para mantener la honestidad: “La esperanza no es una estrategia.” — General Gordon R. Sullivan. No es originalmente una cita de operaciones, pero es exacta en operaciones todos los días.

Hechos e historia interesantes para tomar decisiones reales

Esto no es trivia de noche de bar. Explican por qué las herramientas actúan como lo hacen y por qué existen algunas particiones “raras”.

MBR data de la era temprana del PC y usa direccionamiento de 32 bits para el recuento de sectores, por eso el límite clásico está alrededor de 2 TB con sectores de 512 bytes.
GPT se definió como parte de la especificación UEFI para reemplazar MBR, no solo “extenderlo.” Está pensado para firmware moderno y discos grandes.
GPT mantiene un encabezado y un array de particiones de respaldo al final del disco. Eso no es teórico. Cuando el encabezado primario se corrompe por un clon malo, a menudo puedes recuperar desde el respaldo.
GPT incluye CRCs para sus encabezados y entradas de partición. Las herramientas pueden detectar corrupción en lugar de continuar silenciosamente con datos absurdos.
El “MBR protector” existe en discos GPT para que utilidades solo MBR no vean el disco como “vacío” y lo sobrescriban. Es una mina de compatibilidad y a la vez una característica de seguridad.
UEFI no “arranca una partición”, arranca un ejecutable EFI. Por eso puedes tener múltiples cargadores de SO en una ESP sin depender de una bandera “activa”.
Windows históricamente usó una pequeña partición “System Reserved” en instalaciones BIOS/MBR para almacenar archivos de arranque y metadatos de BitLocker, lo que confunde la clonación y el depurado de “¿por qué C: no arranca?”.
Muchos sistemas se envían con firmware UEFI configurado para compatibilidad “Legacy/CSM”. La misma máquina puede arrancar en dos modos incompatibles según un solo ajuste del firmware.
“Partición BIOS boot” es un tipo de partición GPT usada principalmente por GRUB en sistemas BIOS. Es pequeña (a menudo 1–2 MiB) y parece inútil hasta que la necesitas.

Modelos de arranque que importan: BIOS+MBR, BIOS+GPT, UEFI+GPT, UEFI+MBR

UEFI + GPT (el valor por defecto moderno que deberías preferir)

Esta es la combinación que genera menos drama cuando se hace correctamente.

Esquema de particiones: GPT
Debe tener: partición del Sistema EFI (FAT32), típicamente 100–550 MiB según costumbres de distro/vendedor
Ubicación del cargador: \EFI\…\*.efi en la ESP
Estado del firmware: modo UEFI (no legacy)

Modo de fallo: clonaste la partición del SO pero no la ESP, o recreaste la ESP pero no restauraste las entradas NVRAM. El disco “parece bien”, pero el firmware no sabe qué cargar.

BIOS + MBR (todavía común en appliances y flotas antiguas)

Esta es la combinación que eliges cuando lidias con firmware más viejo, algunos hipervisores configurados para arranque legacy, o imágenes corporativas que nunca evolucionaron.

Esquema de particiones: MBR
Debe tener: código de arranque en el MBR, una partición activa en muchos setups
Limitaciones: direccionamiento de ~2 TB en disco único, 4 particiones primarias a menos que uses particiones extendidas/lógicas

Modo de fallo: alguien convierte a GPT “por modernizar” y olvida que BIOS no puede arrancarlo sin el enfoque BIOS boot de GRUB.

BIOS + GPT (funciona, pero tienes que hacerlo con intención)

BIOS no entiende GPT de forma nativa como lo hace UEFI. Pero cargadores como GRUB pueden hacerlo funcionar con una partición pequeña de arranque BIOS dedicada.

Esquema de particiones: GPT
Debe tener: una pequeña partición BIOS boot (tipo EF02 en términos de gdisk), usualmente 1–2 MiB, sin formatear
Caso de uso: arrancar sistemas BIOS desde discos >2 TB, o mantener herramientas GPT consistentes en la flota

Modo de fallo: falta la partición BIOS boot, o un disco sin espacio posterior al MBR para que GRUB incruste su imagen core.

UEFI + MBR (posible, pero tiende a ser una trampa)

Algunos firmwares UEFI pueden arrancar desde MBR, pero el comportamiento entre fabricantes es inconsistente. Si quieres comportamiento predecible: no lo hagas.

Esquema de particiones: MBR
Debe tener: puede existir una partición FAT tipo ESP, pero no es estándar de la misma manera
Mejor práctica: si estás en modo UEFI, comprométete con GPT

Broma corta secundaria, y luego volvemos al trabajo: UEFI+MBR es como llevar corbata con pantalones de deporte—técnicamente ropa, prácticamente una señal de alerta.

Tareas prácticas: 12+ comandos, salidas y decisiones

Estos son chequeos reales que puedes ejecutar en servidores Linux y entornos de rescate. Cada tarea incluye: el comando, qué significa la salida y la decisión que tomas a partir de ella.

Tarea 1: Comprobar si arrancaste en modo UEFI (Linux)

cr0x@server:~$ test -d /sys/firmware/efi && echo UEFI || echo BIOS
UEFI

Significado: Si ves UEFI, el kernel se inició vía UEFI. Si ves BIOS, estás en modo legacy.

Decisión: En modo UEFI, orienta a GPT y asegura que exista una ESP y esté montada en /boot/efi (o el equivalente de la distro). En modo BIOS, no asumas que GPT arrancará a menos que lo hayas preparado como BIOS+GPT.

Tarea 2: Identificar el tipo de tabla de particiones en un disco

cr0x@server:~$ sudo parted -s /dev/sda print | sed -n '1,12p'
Model: ATA Samsung SSD (scsi)
Disk /dev/sda: 1024GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Significado: Partition Table: gpt o msdos (parted llama MBR “msdos”).

Decisión: Compara esto con el modo de arranque. UEFI+msdos es sospechoso. BIOS+gpt requiere verificar una partición BIOS boot y el método de instalación de GRUB.

Tarea 3: Inspeccionar dispositivos de bloque y puntos de montaje de un vistazo

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,FSVER,PARTTYPENAME,MOUNTPOINTS /dev/sda
NAME   SIZE TYPE FSTYPE FSVER PARTTYPENAME                  MOUNTPOINTS
sda    953G disk
├─sda1  512M part vfat   FAT32 EFI System                   /boot/efi
├─sda2    1G part ext4         Linux filesystem             /boot
└─sda3  952G part ext4         Linux filesystem             /

Significado: Puedes ver una ESP (vfat, “EFI System”), además de particiones Linux normales.

Decisión: Si se espera UEFI y no ves una ESP montada, arregla eso antes de tocar cualquier otra cosa.

Tarea 4: Confirmar que la ESP sea realmente FAT32 y tenga archivos EFI

cr0x@server:~$ sudo find /boot/efi/EFI -maxdepth 2 -type f -name '*.efi' | head
/boot/efi/EFI/ubuntu/grubx64.efi
/boot/efi/EFI/ubuntu/shimx64.efi

Significado: Existen ejecutables EFI. Si este directorio está vacío o faltante, probablemente clonaste solo el sistema de archivos raíz, no la ruta de arranque.

Decisión: Si falta, reconstruye el contenido de la ESP (reinstala el cargador) en lugar de reinstalar kernels sin fin.

Tarea 5: Comprobar entradas de arranque NVRAM UEFI

cr0x@server:~$ sudo efibootmgr -v
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0001,0002
Boot0001* UEFI: Built-in EFI Shell	...
Boot0002* UEFI: PXE IPv4 Intel(R)	...
Boot0003* ubuntu	HD(1,GPT,7b2c...,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)

Significado: El firmware sabe dónde está tu cargador en disco. Si falta la entrada de tu SO, el firmware puede recurrir a PXE o a un shell.

Decisión: Entrada faltante: reinstala el cargador o crea una nueva entrada. También verifica que el GUID de la partición coincida con tu disco actual (los clones lo cambian).

Tarea 6: Detectar “encabezado GPT no en el final del disco” después de clonar a un disco más grande

cr0x@server:~$ sudo sgdisk -v /dev/sda
Problem: The secondary header's self-pointer indicates that it doesn't reside at the end of the disk.
Problem: The secondary header is placed too early on the disk.
No problems found. 1000 free sectors (500.0 KiB) available in 1 segments, the largest of which is 1000 (500.0 KiB) in size.

Significado: Común después de clonar disco a disco: el encabezado GPT de respaldo aún está en el final del disco antiguo.

Decisión: Arregla los metadatos GPT antes de redimensionar particiones/sistemas de archivos. La solución habitual es reubicar el encabezado de respaldo con sgdisk -e.

Tarea 7: Reparar la ubicación del encabezado de respaldo GPT

cr0x@server:~$ sudo sgdisk -e /dev/sda
The operation has completed successfully.

Significado: El encabezado secundario GPT se movió al final real del disco.

Decisión: Vuelve a ejecutar sgdisk -v para verificar estado limpio, luego procede con las operaciones de redimensionado.

Tarea 8: Comprobar si existe partición BIOS boot en BIOS+GPT

cr0x@server:~$ sudo parted -s /dev/sda print
Model: ATA ST4000NM000 (scsi)
Disk /dev/sda: 4001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  3146kB  2097kB               grub  bios_grub
 2      3146kB  1077MB  1074MB  ext4               boot
 3      1077MB  4001GB  4000GB  ext4               root

Significado: La bandera bios_grub indica la partición BIOS boot que GRUB necesita para BIOS-on-GPT.

Decisión: Si estás arrancando por BIOS un disco GPT y falta esta partición, créala antes de reinstalar GRUB o seguirás “instalando” en el aire.

Tarea 9: Confirmar en qué disco GRUB cree que está instalado (Linux)

cr0x@server:~$ sudo grub-probe -t device /boot
/dev/sda2

Significado: Esto muestra qué dispositivo de bloque respalda /boot.

Decisión: Si pretendías arrancar desde /dev/nvme0n1 pero esto informa /dev/sda, probablemente montaste el root/boot equivocado en rescate, o el sistema fue clonado y no actualizado.

Tarea 10: Reinstalar GRUB para sistemas BIOS (con cuidado)

cr0x@server:~$ sudo grub-install --target=i386-pc /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.

Significado: GRUB instalado en modo BIOS/MBR al disco. En BIOS+GPT, esto aún usa la partición BIOS boot si está presente.

Decisión: Haz esto solo después de confirmar el modo de arranque. Instalar i386-pc en un sistema UEFI no producirá una entrada UEFI funcional.

Tarea 11: Reinstalar GRUB para sistemas UEFI

cr0x@server:~$ sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu
Installing for x86_64-efi platform.
Installation finished. No error reported.

Significado: Los binarios EFI de GRUB se instalan en la ESP y típicamente se crea una entrada en NVRAM.

Decisión: Si efibootmgr aún no muestra una entrada después, el firmware puede bloquear escrituras (común en algunas plataformas virtuales) o la NVRAM está llena; usa la estrategia de ruta de reserva o limpia entradas antiguas.

Tarea 12: Validar limitaciones de MBR en discos grandes

cr0x@server:~$ sudo fdisk -l /dev/sdb | sed -n '1,12p'
Disk /dev/sdb: 3.64 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: ST4000DM004
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x2a3b4c5d

Significado: El disco tiene ~3.64 TiB pero la tabla de particiones es “dos” (MBR). No puedes direccionar todo el disco con el particionado MBR clásico.

Decisión: Convierte a GPT si necesitas todo el disco. Si es disco de arranque, también asegúrate de que el firmware/modo de arranque soporte el método objetivo.

Tarea 13: Comprobar la bandera “active” en setups MBR

cr0x@server:~$ sudo fdisk -l /dev/sda | sed -n '1,25p'
Disklabel type: dos

Device     Boot Start       End   Sectors  Size Id Type
/dev/sda1  *     2048   1050623   1048576  512M 83 Linux
/dev/sda2     1050624 500118191 499067568  238G 83 Linux

Significado: El * indica la partición activa. Algunos caminos de código de BIOS lo esperan.

Decisión: Si un sistema BIOS/MBR dice “no hay dispositivo de arranque” después de editar particiones, verifica que la bandera de arranque no se haya borrado.

Tarea 14: Ver qué referencia tu initramfs/config de arranque (coincidencias de UUID después de clonar)

cr0x@server:~$ grep -E 'UUID=|PARTUUID=' /etc/fstab
UUID=9f2e8d1a-0e2b-4c3a-9c36-2d2a3d0c1f1b / ext4 defaults 0 1
UUID=1A2B-3C4D /boot/efi vfat umask=0077 0 1

Significado: Root y ESP se montan por UUID. Después de clonar, los UUID pueden cambiar si se recrearon los sistemas de archivos, o permanecer si se clonó a nivel de bloque.

Decisión: Si el arranque cae en initramfs quejándose de que no encuentra root, compara estos UUID con la salida de blkid y corrige /etc/fstab o regenera initramfs.

Tarea 15: Confirmar UUIDs de sistemas de archivos e identificadores de partición

cr0x@server:~$ sudo blkid /dev/sda1 /dev/sda2 /dev/sda3
/dev/sda1: UUID="1A2B-3C4D" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="7b2c..."
/dev/sda2: UUID="d0c1..." BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="2f10..."
/dev/sda3: UUID="9f2e..." BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="8aa1..."

Significado: Confirma lo que el sistema debería montar y lo que GRUB/kernel podrían referenciar.

Decisión: Si /etc/fstab hace referencia a un UUID antiguo, actualízalo. Si GRUB referencia un UUID equivocado, regenera la configuración y reinstala.

Tarea 16: Detectar desajuste “legacy vs UEFI” dentro de la configuración de GRUB

cr0x@server:~$ sudo file /boot/grub/i386-pc/core.img
/boot/grub/i386-pc/core.img: GRUB2 core image, i386-pc, ...

Significado: Esto indica que existen artefactos GRUB dirigidos a BIOS. En una configuración puramente UEFI, esperarías binarios EFI en la ESP en lugar de depender de i386-pc.

Decisión: Si el firmware es UEFI pero tu sistema se instaló en modo BIOS, decide si vas a convertir el modo de arranque (reparticionar/crear ESP) o mantener el modo legacy. Mezclar es la forma de conseguir páginas a las 2 a. m.

Guía rápida de diagnóstico: qué revisar primero/segundo/tercero

Cuando un sistema no arranca tras un cambio de disco, puedes perder horas hurgando en el sistema de archivos. No lo hagas. Comienza por la cadena de arranque y avanza hacia arriba. Tu objetivo es identificar qué capa falla en menos de 10 minutos.

Primero: confirma modo de arranque y alineación de tabla de particiones

Comprobar modo de arranque: ¿existe /sys/firmware/efi?
Comprobar tabla de particiones: ¿GPT o MBR?
Comprobar existencia de ESP (UEFI) o partición activa / partición BIOS boot (escenarios legacy).

Razón: Si UEFI está habilitado pero el disco es MBR sin ESP, o BIOS está habilitado pero el disco es GPT sin partición BIOS boot, tu “reparación de sistema de archivos” es teatro.

Segundo: valida la presencia del cargador donde el firmware lo espera

UEFI: ¿la ESP contiene \EFI\...\*.efi?
UEFI: ¿efibootmgr -v muestra una entrada apuntando a ese archivo?
BIOS: ¿GRUB está instalado en el disco correcto (no solo en una partición)? ¿Está presente el código MBR?

Tercero: valida la transferencia al SO (kernel + identificación de root)

¿Initramfs se queja de root faltante? Eso es desajuste UUID/PARTUUID o drivers faltantes.
¿Caes en GRUB rescue? Normalmente es /boot faltante, disco equivocado o incrustación rota.
¿El gestor de arranque de Windows inicia pero el SO no? Eso son problemas BCD/rutas de dispositivo y a veces cambios en el modo del controlador de almacenamiento.

Identificación rápida del cuello de botella

Si tienes que resumir:

No hay dispositivo de arranque / pantalla del firmware: el firmware no encuentra el cargador (ESP/NVRAM/código de arranque desajustado).
Prompt/rescate de GRUB: el cargador arrancó, no encuentra su configuración o módulos (IDs de partición incorrectos, /boot faltante).
Kernel panic / shell de initramfs: el SO arrancó, no puede montar root (desajuste UUID, drivers faltantes, mapeos RAID/LVM rotos).

Tres mini-historias corporativas (y qué enseñan)

Mini-historia 1: el incidente causado por una suposición equivocada

Un equipo migró un servicio interno pequeño de un servidor RAID antiguo a una caja nueva con NVMe. La construcción estaba automatizada, la imagen del SO era consistente y todos se sentían responsables. Entonces hicieron un “simple” clonado de disco del sistema antiguo al nuevo para mantener la configuración idéntica.

El host antiguo arrancaba en modo BIOS heredado, MBR. El host nuevo llegó con UEFI habilitado por defecto. El clon copió particiones y sistemas de archivos perfectamente. También copió una cadena de arranque que asumía un MBR y una partición activa, sobre un sistema cuyo firmware buscaba una ESP y un ejecutable EFI.

Al reiniciar: directo al firmware. Sin entrada de arranque. Sin errores obvios. El on-call comenzó a revisar salud de RAID y SMART porque “no ve el disco”. El disco estaba bien. El firmware no sabía qué hacer con él.

La solución fue vergonzantemente simple: o cambiar el firmware a arranque legacy/CSM (no ideal), o hacer la ruta correcta UEFI+GPT—tabla GPT, crear ESP, reinstalar cargador, crear entrada NVRAM. Eligieron la segunda opción y estandarizaron su pipeline de construcción para detectar modo de arranque y particionar en consecuencia.

Lección: Nunca asumas que el modo de arranque se mantiene entre generaciones de hardware. Valídalo explícitamente y añádelo a la automatización.

Mini-historia 2: la optimización que salió mal

Un grupo de plataforma quiso acelerar el aprovisionamiento. Decidieron preconstruir imágenes golden como imágenes crudas de disco y grabarlas directamente en los discos de arranque de nuevos servidores. Era rápido. También incrustó silenciosamente un layout de particiones y configuración de arranque que solo funcionaba bajo una configuración de firmware específica.

La optimización fue “usaremos GPT en todas partes porque es moderno.” Buena intuición. El problema fue que parte de su flota—unidades de rack más antiguas y algunos appliances de borde—aún arrancaban en modo BIOS, y no todas tenían una historia BIOS+GPT fiable. Algunas necesitaban una partición BIOS boot. Algunas tenían peculiaridades de firmware. Otras arrancaban solo cuando el disco tenía un MBR con un layout particular.

Desplegaron el nuevo proceso de imagen a una flota de hardware mixto. Las fallas no fueron inmediatas. Aparecieron durante una ventana de reinicio de parches rutinaria. Algunos sistemas volvieron. Otros no. Parecía aleatorio porque el hardware era aleatorio.

“Lo arreglaron” creando múltiples imágenes y dejando que los técnicos eligieran la correcta. Eso hizo el proceso más lento y todavía propenso a errores. La solución real fue dejar de tratar el modo de arranque como un detalle: interrogar la plataforma (UEFI vs BIOS), seleccionar la receta correcta de particionado/cargador, y generar layouts de disco dinámicamente. La imagen golden se convirtió en un artefacto a nivel de sistema de archivos, no en un blob a nivel de disco.

Lección: Las imágenes de disco son rápidas hasta que no lo son. Si tu flota no es homogénea, los blobs estáticos de disco son un impuesto a la fiabilidad.

Mini-historia 3: la práctica aburrida pero correcta que salvó el día

Un equipo cercano a finanzas tenía una política que molestaba a todos: antes de cualquier migración o redimensionado de disco, capturaban un pequeño “paquete de hechos de arranque”—modo de arranque, tipo de tabla de particiones, lsblk, y (para UEFI) efibootmgr -v. Tomaba dos minutos y parecía papeleo.

Un trimestre, movieron cargas de trabajo de SSDs envejecidos a discos nuevos. Una herramienta del proveedor realizó el clon y redimensionó la última partición. La partición del SO parecía bien, pero tras reiniciar el sistema cayó en GRUB rescue. El pánico empezó porque la ventana de cambio era corta y el sistema era “algo crítico”.

Ese paquete pre-cambio mostró algo sutil: el disco viejo tenía una ESP montada en /boot/efi con una ruta de proveedor específica, y la entrada de arranque referenciaba un GUID de partición particular. Tras clonar, la ESP existía pero no estaba montada; la herramienta de clonación había alterado los GUID de partición. El firmware seguía una entrada NVRAM obsoleta y no encontraba nada útil.

Con la evidencia, la recuperación fue limpia: montar la ESP, reinstalar el cargador, recrear la entrada NVRAM y verificar la ruta de reserva. Sin adivinanzas. Sin limpieza de sistema de archivos. El sistema volvió dentro de la ventana.

Lección: La recolección aburrida de evidencia vence la depuración heroica. Siempre.

Errores comunes: síntoma → causa raíz → solución

Esta es la sección que buscas a las 2 a. m. Está bien. La escribí para ese momento.

1) Síntoma: “No hay dispositivo de arranque” inmediatamente después de clonar disco

Causa raíz: Cambió el modo de arranque del firmware (UEFI vs BIOS) o el esquema del disco no coincide con lo que el firmware espera (UEFI intentando arrancar un disco MBR sin ESP/entradas NVRAM).

Solución: Confirma el modo de arranque y luego alinea el disco:

UEFI: GPT + ESP + grub-install --target=x86_64-efi + entrada efibootmgr.
BIOS: MBR + partición activa + grub-install --target=i386-pc /dev/sdX.

2) Síntoma: prompt de GRUB rescue, no puede encontrar `normal.mod`

Causa raíz: El core de GRUB se cargó, pero no encuentra sus módulos/config—a menudo porque /boot se movió, cambiaron los IDs de partición, o falta la partición BIOS boot en BIOS+GPT.

Solución: Arranca con medios de rescate, monta root y boot, reinstala GRUB para el target correcto, regenera la configuración (update-grub o equivalente de la distro). En BIOS+GPT, asegúrate de que exista la partición BIOS boot.

3) Síntoma: El kernel arranca, luego shell initramfs: “cannot find UUID=…”

Causa raíz: El identificador del sistema de archivos root cambió (desajuste UUID/PARTUUID), o cambió el modo del controlador de almacenamiento (AHCI/RAID) y initramfs carece de los módulos del driver.

Solución: Compara /etc/fstab y los argumentos del kernel en el cargador con blkid. Actualiza identificadores, reconstruye initramfs. Si cambió el modo del controlador, revierte o reconstruye initramfs con los módulos correctos.

4) Síntoma: Disco es GPT pero herramientas se quejan de encabezados corrompidos después de redimensionar

Causa raíz: El encabezado GPT de respaldo no se movió al final tras clonar; o la tabla de particiones fue editada por herramientas solo MBR.

Solución: Usa sgdisk -v para validar; repara con sgdisk -e; evita herramientas legacy que reescriben el MBR protector incorrectamente.

5) Síntoma: El sistema UEFI arranca solo después de elegir el disco manualmente en el menú del firmware

Causa raíz: Orden/entradas NVRAM incorrectas o faltantes; a veces la entrada de arranque apunta a un GUID de partición cambiado.

Solución: Usa efibootmgr -v para auditar. Reinstala el cargador o recrea la entrada. Considera colocar una copia en la ruta de reserva (\EFI\BOOT\BOOTX64.EFI) si la política lo permite.

6) Síntoma: Tras “convertir a GPT”, Windows no arranca

Causa raíz: Se convirtió la tabla de particiones sin convertir el modo de arranque/gestor de arranque; falta la ESP; BCD aún apunta a la ruta de arranque estilo BIOS.

Solución: En Windows, usa herramientas de conversión adecuadas y luego activa el arranque UEFI. Asegura que exista la ESP y esté poblada. Si hay modo mixto, decide un camino y reconstruye el gestor de arranque acorde.

7) Síntoma: No puedes crear más de cuatro particiones en MBR

Causa raíz: MBR soporta solo cuatro particiones primarias a menos que uses una partición extendida con particiones lógicas.

Solución: Si necesitas muchas particiones y arranque moderno, cambia a GPT. Si debes quedarte en MBR, diseña con una partición extendida y acepta la complejidad legacy.

Listas de verificación / plan paso a paso

Checklist A: Elegir GPT vs MBR (camino de decisión)

Determina el modo de arranque objetivo: UEFI o BIOS? (No adivines; verifica en la especificación del firmware o el SO actual.)
Si UEFI: elige GPT.
Si BIOS: elige MBR a menos que tengas una razón específica para usar GPT (disco >2 TB, estandarización de flota) y estés preparado para usar una partición BIOS boot.
Comprueba necesidades de tamaño de disco: si necesitas >2 TB en un solo disco, GPT es obligatorio sin importar la nostalgia.
Decide la estrategia del cargador (GRUB, systemd-boot, gestor de arranque de Windows) y asegúrate de que existan las particiones requeridas.

Checklist B: Plan seguro de migración o clonación (servidores Linux)

Captura “hechos de arranque” antes del cambio: modo de arranque, tabla de particiones, lsblk, y si UEFI, efibootmgr -v.
Si usas GPT: valida encabezados GPT con sgdisk -v después del clon; arregla con sgdisk -e si es necesario.
Asegura que la ESP (UEFI) se clone o se recrée y esté montada en el punto esperado.
Verifica que /etc/fstab UUIDs coincidan con blkid.
Reinstala el cargador acorde al modo real de arranque (target UEFI vs BIOS).
Reinicia una vez mientras todavía tengas acceso a consola y una ventana de rollback.

Checklist C: Convertir BIOS/MBR a UEFI/GPT (pasos generales)

Confirma que el hardware/VM soporta arranque UEFI y que puedes cambiarlo.
Crea espacio para una ESP si es necesario (reduce particiones con cuidado).
Convierte la tabla de particiones (herramientas específicas de plataforma; no improvises con utilidades aleatorias).
Crea la ESP (FAT32) y móntala.
Instala el cargador EFI, crea la entrada NVRAM, verifica con efibootmgr -v.
Cambia el firmware a modo UEFI y prueba el arranque.

Preguntas frecuentes

1) ¿GPT siempre es mejor que MBR?

Mejor para sistemas modernos, sí: discos más grandes, más particiones, redundancia, sumas de comprobación. Pero “mejor” no hace que tu appliance antiguo solo BIOS arranque. Empareja con el modo de arranque.

2) ¿Puede BIOS arrancar desde GPT?

Sí, a menudo vía GRUB con una partición BIOS boot. Es común en flotas Linux que quieren GPT en todas partes. Pero no es magia: debes crear la pequeña partición BIOS boot e instalar GRUB correctamente.

3) ¿Por qué mi disco GPT muestra un MBR en algunas herramientas?

Ese es el MBR protector. Existe para que herramientas solo MBR no traten el disco como vacío. Si una herramienta “amablemente” lo reescribe, puede confundir a otras herramientas.

4) ¿Qué tamaño de ESP debería usar?

Para servidores Linux, 512 MiB es un valor por defecto aburrido que evita problemas futuros (múltiples kernels, múltiples cargadores, actualizaciones del vendedor). Menor puede funcionar, hasta que no.

5) ¿Necesito una bandera active/boot en GPT?

No para UEFI. UEFI no se preocupa por “activo” en el sentido MBR. Para BIOS+MBR, la bandera de arranque puede importar según el cargador y la cadena.

6) Cloné un disco y ahora las entradas UEFI apuntan a lo incorrecto. ¿Por qué?

Las entradas de arranque UEFI pueden referenciar una partición por GUID y una ruta de archivo. Clonar o recrear particiones puede cambiar GUIDs. Arregla reinstalando el cargador o recreando la entrada de arranque.

7) ¿Puedo mantener MBR y simplemente crear una ESP?

No como estrategia estándar y portable. Algunas firmas pueden arrancarlo, otras no. Si quieres fiabilidad UEFI, usa GPT con una ESP adecuada.

8) ¿Cuál es la diferencia entre una ESP y una partición BIOS boot?

ESP es un sistema de archivos FAT32 que guarda ejecutables EFI para firmware UEFI. Una partición BIOS boot es un pequeño espacio sin formatear que GRUB usa en discos GPT cuando arranca vía BIOS.

9) ¿Por qué algunos sistemas arrancan bien hasta el siguiente reinicio tras redimensionar particiones?

Porque no rompiste el sistema en ejecución—rompiste la cadena de arranque para el siguiente inicio. Redimensionar puede mover o recrear particiones, cambiar identificadores o borrar el área posterior al MBR en la que GRUB dependía.

10) ¿Qué debería estandarizar en una flota mixta?

Estandariza un proceso de decisión, no una sola respuesta. Detecta el modo de arranque y las restricciones de hardware, luego genera el layout correcto (UEFI+GPT por defecto; los casos BIOS tratados deliberadamente).

Siguientes pasos que puedes hacer hoy

Si ejecutas sistemas en producción, trata el arranque como un contrato API entre firmware y disposición del disco. Los contratos no se preocupan por tus intenciones.

Audita una muestra de tu flota: comprueba modo de arranque y tipo de tabla de particiones. Encuentra desajustes antes de que te hagan un page.
Actualiza tus scripts de provisión para seleccionar explícitamente UEFI vs BIOS y luego aplicar GPT vs MBR en consecuencia.
Añade un paso pre-cambio de captura de “hechos de arranque” a tus runbooks para trabajo con discos. Dos minutos al principio ahorran horas después.
Para cualquier flujo de clonación o migración: verifica que existan y estén pobladas la ESP/particiones BIOS boot antes de reiniciar.

La regla es simple. La disciplina no lo es. Pero la disciplina es más barata que el tiempo de inactividad.