Convertir MBR a GPT sin reinstalar (con herramientas integradas)

El problema real: tabla de particiones vs modo de arranque

MBR vs GPT trata sobre la tabla de particiones. BIOS vs UEFI trata sobre el modo de arranque del firmware. La gente los confunde porque a menudo van de la mano:

• Legacy BIOS normalmente arranca desde MBR.
• UEFI normalmente arranca desde GPT mediante una partición del sistema EFI (ESP).

Pero pueden darse desajustes en entornos reales. Ahí es donde las conversiones se desvían. Convertir la tabla de particiones no es suficiente; el sistema también debe tener un cargador de arranque que coincida con el modo de firmware que usarás tras la conversión.

El modelo mental más simple y seguro:

• Windows: Si conviertes el disco del sistema de MBR a GPT, debes arrancar Windows usando UEFI. La herramienta integrada de Microsoft (mbr2gpt) gestiona la partición y los archivos de arranque, pero aún tienes que cambiar la configuración del firmware.
• Linux: Puedes convertir a GPT y mantener el arranque legacy usando una partición BIOS boot (imagen core de GRUB) o pasarte a UEFI con una ESP. Qué es “integrado” depende de tu distro, pero las herramientas base (fdisk, gdisk/sgdisk, grub-install, efibootmgr) normalmente están disponibles.

La cruda verdad: la mayoría de los fallos durante MBR→GPT no los causa la herramienta de conversión. Los causa la gente adivinando qué disco es “Disco 0”, asumiendo que el firmware seguirá mágicamente, o descubriendo demasiado tarde que BitLocker/políticas de Secure Boot no encajan con el plan.

Broma #1: Las tablas de particiones son como los organigramas de oficina: todo el mundo las ignora hasta que algo se rompe, y entonces de repente son “documentación crítica”.

Una cita de fiabilidad que aplica al trabajo con discos:

“La esperanza no es una estrategia.” — James Cameron

En este contexto, “esperanza” es convertir en caliente sin una copia de seguridad verificada y sin confirmar que puedes entrar al setup del firmware. No lo hagas.

Datos y contexto interesantes (lo que explica las rarezas)

1. El tope de 2 TB de MBR viene del direccionamiento de sectores de 32 bits con sectores de 512 bytes: 2^32 × 512 bytes ≈ 2 TB. Sí, los discos con sectores 4K complican la cuenta, pero el límite heredado sigue afectando.
2. MBR data de la era temprana del PC y fue diseñado para un mundo donde un “disco grande” se medía en megabytes, no en terabytes.
3. GPT forma parte de UEFI, pero puede usarse sin UEFI en algunas configuraciones Linux. El emparejamiento es tanto cultural como técnico.
4. GPT mantiene una cabecera de respaldo al final del disco. No es decorativa; sirve para recuperar la cabecera primaria si se corrompe.
5. MBR tiene una sola tabla de particiones para siempre, mientras que GPT usa sumas CRC para detectar corrupción. Por eso las herramientas GPT pueden decir “tu metadata está mal” en vez de arrancar en caos silencioso.
6. El “MBR protector” en discos GPT existe para que las herramientas antiguas no piensen que el disco está vacío y lo sobrescriban “útilmente”.
7. Históricamente Windows requirió GPT para arranque UEFI en discos de sistema. La herramienta de conversión moderna existe porque las empresas exigieron migración in-situ para cumplir bases de seguridad.
8. Las entradas de arranque UEFI viven en NVRAM y pueden borrarse con actualizaciones de firmware, reinicios de NVRAM o algunos scripts de endurecimiento que no entienden lo que eliminan.
9. Arrancar BIOS desde GPT es posible en Linux mediante una pequeña “partición BIOS boot”, pero Windows no hace eso para discos de sistema. Diferente SO, diferentes reglas.

Preflight: decide tu camino antes de tocar un disco

Antes de la conversión, responde tres preguntas. No “creo que sí”. Pruébalo con comandos.

1) ¿Qué sistema operativo está realmente arrancando esta máquina?

Las máquinas con arranque dual, entornos de rescate y hosts de staging antiguos encantan sorprenderte. Convierte el disco equivocado y practicarás comunicación de incidentes.

2) ¿Estás actualmente en modo BIOS/Legacy o UEFI?

Esto decide si puedes mantener el mismo enfoque de arranque o debes cambiar. Para la conversión del disco del sistema Windows con mbr2gpt, cambiarás a UEFI.

3) ¿Se puede convertir el diseño del disco sin mover montañas?

mbr2gpt es exigente: necesita espacio para crear una EFI System Partition (ESP), y tiene restricciones sobre número/tipos de particiones. Las conversiones en Linux pueden ser más flexibles, pero tu cargador de arranque y /etc/fstab podrían no estar preparados.

Consejos con criterio:

• Si es un portátil o un servidor crítico único y no tienes consola fuera de banda: programa una ventana de mantenimiento y ten un medio de recuperación booteable listo. “Manos remotas” no es un plan; es una oración con número de ticket.
• Si es una VM: haz un snapshot (si la política lo permite) y aun así realiza las comprobaciones. Las snapshots no son copias de seguridad, pero son excelentes reductores de arrepentimiento.
• Si es un LUN de controlador RAID: confirma que el controlador no hace reescrituras “útiles” de metadatos durante las conversiones. Normalmente está bien, ocasionalmente maldecido.

Guía de diagnóstico rápido (encuentra el cuello de botella rápido)

Cuando la “conversión MBR a GPT” falla, el cuello de botella casi siempre es uno de estos: disco equivocado, modo de arranque incorrecto, sin espacio para ESP, o confusión con el cargador/NVRAM. Revisa en este orden.

Primero: confirma modo de arranque y disco objetivo

• Windows: comprueba el modo del BIOS en msinfo32 o vía PowerShell/WMI.
• Linux: comprueba la existencia de /sys/firmware/efi.
• Confirma el número/ruta del disco que piensas convertir, y confirma que contiene el SO.

Segundo: valida los prerequisitos de conversión

• Windows: ejecuta mbr2gpt /validate. Lee el error. No improvises.
• Linux: confirma que hay espacio para añadir un ESP (ruta UEFI) o una partición BIOS boot (ruta legacy). Asegura que los cambios en la tabla de particiones no colisionen con ubicaciones de metadatos LVM/RAID.

Tercero: planifica la ruta de arranque post-conversión

• Windows: tras la conversión, debes cambiar el firmware a UEFI y asegurarte de que existe la entrada Windows Boot Manager.
• Linux: decide si instalas GRUB en modo EFI (ESP + entrada NVRAM) o en modo BIOS (partición BIOS boot). Luego instala acorde a ello.

Cuarto: si convirtió pero no arranca, céntrate en los artefactos de arranque

• Windows: usa WinRE, bcdboot y comprueba la ESP.
• Linux: usa un live ISO, efibootmgr, grub-install y revisa montajes y UUIDs.

Ruta en Windows (integrada): MBR2GPT + cambio a UEFI

En Windows 10/11 y Windows Server modernos, la herramienta integrada es mbr2gpt.exe. Convierte el disco del sistema de MBR a GPT sin modificar el contenido de tus particiones de Windows, crea una ESP y actualiza la configuración de arranque. Es la mejor opción cuando aplica.

Qué hace bien mbr2gpt

• Conversión no destructiva de la tabla de particiones (en el sentido de que no borra el contenido de tus particiones de datos).
• Crea una EFI System Partition y una Microsoft Reserved Partition si hace falta.
• Actualiza el BCD para arrancar en modo UEFI.

Qué se negará a hacer mbr2gpt

• Convertir discos que no cumplan sus restricciones de diseño.
• Reconfigurar mágicamente tu firmware de Legacy a UEFI. Eso lo debes hacer tú.
• Arreglar gestores de arranque de terceros que hayas instalado de formas creativas.

Enfoque operativo

Realiza la conversión desde WinRE o desde Windows completo con /allowFullOS cuando sea necesario. En flotas empresariales, WinRE reduce sorpresas como “algo tenía un bloqueo sobre los metadatos del disco”. En la práctica, si puedes programar downtime, WinRE resulta más tranquilo.

Después de la conversión: reinicia, entra al setup del firmware, cambia a modo UEFI, mantiene Secure Boot desactivado hasta confirmar que el arranque funciona y luego actívalo si la política lo exige. No combines “migración de tabla de particiones” con “aplicación de Secure Boot” a menos que disfrutes de fallos en capas.

Ruta en Linux: convierte con gdisk/sgdisk y luego deja el arranque explícito

Linux te da opciones, y las opciones son cómo acabas con siete cargadores de arranque y un fin de semana funcionando. Si tu objetivo es “GPT sin reinstalación”, tienes dos estrategias sensatas:

1. Convertir a GPT y mantener arranque Legacy creando una pequeña partición BIOS boot y reinstalando GRUB en modo BIOS.
2. Convertir a GPT y cambiar a arranque UEFI creando una ESP, instalando GRUB para EFI y creando una entrada en NVRAM.

La mayoría de entornos modernos deberían elegir UEFI salvo que exista una restricción firme. UEFI no es automáticamente “mejor”, pero es la dirección que asumen tu firmware, las herramientas del proveedor y las bases de seguridad.

Precauciones clave para conversiones en Linux

• Si usas LVM, mdraid o cifrado, tus particiones son contenedores. Convertir la tabla de particiones no reescribe el contenido, pero no debes cambiar sectores de inicio casualmente.
• Conoce tu cargador de arranque: GRUB en modo BIOS depende del espacio de incrustación del core image; en discos GPT típicamente necesita una partición BIOS boot.
• UEFI requiere una ESP formateada como FAT32, típicamente montada en /boot/efi.

Broma #2: Las pantallas de configuración del firmware UEFI fueron diseñadas por alguien que miró una cabina de piloto y dijo: “Demasiado intuitivo”.

Tareas prácticas: comandos, qué significa la salida, la decisión que tomas

Estos son los chequeos reales que ejecuto. Cada uno tiene una razón: convierte una suposición en una decisión. Los comandos están agrupados por plataforma, pero algunos aplican en todas partes.

Task 1 (Windows): Confirmar modo de BIOS (UEFI vs Legacy)

cr0x@server:~$ powershell -NoProfile -Command "(Get-ComputerInfo).BiosFirmwareType"
Legacy

Qué significa: Actualmente has arrancado en modo Legacy.

Decisión: Si conviertes el disco del sistema a GPT, planifica un cambio del firmware a UEFI después de la conversión. Si no puedes acceder al setup del firmware de forma remota, detente y organiza acceso físico.

Task 2 (Windows): Identificar el número del disco del sistema

cr0x@server:~$ powershell -NoProfile -Command "Get-Disk | Select Number,FriendlyName,PartitionStyle,Size"
0  NVMe SAMSUNG MZVLW512  MBR  476.94 GB
1  Virtual Disk            GPT  100.00 GB

Qué significa: El Disco 0 es MBR y probablemente tu disco de SO; Disco 1 ya es GPT.

Decisión: Apunta al Disco 0 para validar y convertir. Si el SO está en Disco 1, tu suposición es errónea—verifica con el mapeo de particiones y volúmenes.

Task 3 (Windows): Confirmar qué partición contiene Windows

cr0x@server:~$ powershell -NoProfile -Command "Get-Partition -DiskNumber 0 | Select PartitionNumber,DriveLetter,Type,Size"
1      System     500 MB
2      Reserved   128 MB
3  C   Basic      475.8 GB

Qué significa: El volumen C: está en el Disco 0 partición 3.

Decisión: La conversión debe centrarse en el Disco 0. Si C: no está aquí, sigue investigando; no conviertas “lo que sea el Disco 0” por costumbre.

Task 4 (Windows): Validar prerrequisitos de conversión

cr0x@server:~$ mbr2gpt /validate /disk:0 /allowFullOS
MBR2GPT: Attempting to validate disk 0
MBR2GPT: Retrieving layout of disk
MBR2GPT: Validating layout, disk sector size is: 512 bytes
MBR2GPT: Validation completed successfully

Qué significa: La herramienta cree que puede convertir este disco de forma segura.

Decisión: Procede a la conversión en la ventana de mantenimiento. Si la validación falla, no intentes “probar de todas formas”. Arregla el diseño primero.

Task 5 (Windows): Convertir el disco

cr0x@server:~$ mbr2gpt /convert /disk:0 /allowFullOS
MBR2GPT: Attempting to convert disk 0
MBR2GPT: Retrieving layout of disk
MBR2GPT: Creating the EFI system partition
MBR2GPT: Installing the new boot files
MBR2GPT: Performing the layout conversion
MBR2GPT: Migrating default boot entry
MBR2GPT: Conversion completed successfully

Qué significa: El disco ahora es GPT y tiene archivos de arranque preparados para UEFI.

Decisión: Reinicia y entra al setup del firmware y cambia a arranque UEFI. Si reinicias sin cambiar el firmware, podrías obtener un “no hay dispositivo de arranque”.

Task 6 (Windows): Confirmar que el disco ahora es GPT

cr0x@server:~$ powershell -NoProfile -Command "Get-Disk -Number 0 | Select Number,PartitionStyle"
0 GPT

Qué significa: La conversión de la tabla de particiones tuvo éxito.

Decisión: Continúa con la configuración y verificación del arranque UEFI. No declares terminado hasta confirmar que el modo de arranque es UEFI.

Task 7 (Windows): Verificar que existe la ESP y darle una letra temporal (opcional)

cr0x@server:~$ diskpart
DISKPART> list vol

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 0     C                NTFS   Partition    475 GB  Healthy    Boot
  Volume 1                      FAT32  Partition    100 MB  Healthy    System

Qué significa: Hay un volumen FAT32 “System”—la ESP.

Decisión: Si no existe la ESP, la conversión no hizo lo que crees. Detente e inspecciona la tabla de particiones antes de reiniciar a ciegas.

Task 8 (Windows/WinRE): Reconstruir archivos de arranque si es necesario

cr0x@server:~$ bcdboot C:\Windows /s S: /f UEFI
Boot files successfully created.

Qué significa: Los archivos de arranque de Windows se escribieron en la ESP montada como S:.

Decisión: Usa esto cuando la conversión tuvo éxito pero el firmware no encuentra una entrada de arranque. Es una maniobra de reparación, no el primer paso.

Task 9 (Linux): Confirmar modo de arranque actual

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

Qué significa: El kernel se inició vía legacy BIOS.

Decisión: Si quieres pasarte a UEFI, necesitarás una ESP y un cargador EFI. Si quieres seguir en BIOS, planifica una partición BIOS boot en GPT.

Task 10 (Linux): Inspeccionar disco actual y tipo de tabla de particiones

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
sda     931.5G disk
├─sda1    512M part ext4   /boot
├─sda2    100G part LVM2_member
└─sda3    831G part LVM2_member

Qué significa: El diseño del disco es por particiones con miembros LVM.

Decisión: La conversión puede funcionar, pero debes preservar los sectores de inicio de las particiones. Herramientas como sgdisk son preferibles porque no realinean “útilmente” a menos que se lo indiques.

Task 11 (Linux): Verificar la tabla de particiones (MBR vs GPT) con parted

cr0x@server:~$ sudo parted -s /dev/sda print
Model: ATA ST1000DM003-1CH1 (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Number  Start   End     Size    Type     File system  Flags
 1      1049kB  538MB   537MB   primary  ext4         boot
 2      538MB   108GB   107GB   primary
 3      108GB   1000GB  892GB   primary

Qué significa: Es MBR (“msdos” en términos de parted).

Decisión: Procede con un plan de conversión MBR→GPT. También nota: ya hay tres particiones primarias. Si necesitas una partición BIOS boot o una ESP, debes hacer espacio.

Task 12 (Linux): Convertir no destructivamente MBR → GPT con sgdisk

cr0x@server:~$ sudo sgdisk --mbrtogpt /dev/sda
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.

Qué significa: Se convirtió la metadata del disco; el kernel en ejecución sigue viendo la tabla antigua.

Decisión: No empieces a redimensionar particiones en este estado. Reinicia (en ventana de mantenimiento) o ejecuta partprobe si es seguro, y vuelve a comprobar con parted.

Task 13 (Linux): Releer la tabla de particiones de forma segura

cr0x@server:~$ sudo partprobe /dev/sda
cr0x@server:~$ sudo parted -s /dev/sda print | grep -i "Partition Table"
Partition Table: gpt

Qué significa: El kernel y las herramientas ahora coinciden en que es GPT.

Decisión: Ahora procede a añadir la partición de arranque necesaria (BIOS boot o ESP) y reinstala el cargador de arranque según corresponda.

Task 14 (Linux, ruta BIOS): Crear una partición BIOS boot (si te quedas en Legacy)

cr0x@server:~$ sudo parted -s /dev/sda mkpart biosboot 1MiB 3MiB
cr0x@server:~$ sudo parted -s /dev/sda set 4 bios_grub on
cr0x@server:~$ sudo parted -s /dev/sda print | tail -n +1
Model: ATA ST1000DM003-1CH1 (scsi)
Disk /dev/sda: 1000GB
Partition Table: gpt
Number  Start   End     Size    File system  Name      Flags
 1      1049kB  538MB   537MB   ext4         primary   boot
 2      538MB   108GB   107GB                primary
 3      108GB   1000GB  892GB                primary
 4      1049kB  3146kB  2097kB               biosboot  bios_grub

Qué significa: Ahora tienes una partición BIOS boot (tiny, sin formatear) marcada para la incrustación de GRUB.

Decisión: Reinstala GRUB en modo BIOS en el área protectora MBR del disco (GRUB usa la partición bios_grub para core image en GPT).

Task 15 (Linux, ruta BIOS): Reinstalar GRUB para BIOS

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

Qué significa: El cargador GRUB en BIOS se instaló en el disco, usando la partición BIOS boot según fue necesario.

Decisión: Reinicia y verifica. Si el host arranca, puedes mantener el modo legacy del firmware. Si pretendías UEFI, detente e instala la ruta UEFI en su lugar.

Task 16 (Linux, ruta UEFI): Crear y formatear una EFI System Partition

cr0x@server:~$ sudo parted -s /dev/sda mkpart esp fat32 3MiB 515MiB
cr0x@server:~$ sudo parted -s /dev/sda set 4 esp on
cr0x@server:~$ sudo mkfs.fat -F32 /dev/sda4
mkfs.fat 4.2 (2021-01-31)

Qué significa: Creaste una ESP de ~512 MiB y la formateaste FAT32.

Decisión: móntala en /boot/efi e instala un cargador EFI. Si ya tenías una ESP en otro lugar, no crees una segunda a la ligera—el firmware elegirá favoritos.

Task 17 (Linux, ruta UEFI): Instalar GRUB para EFI y crear entrada en NVRAM

cr0x@server:~$ sudo mkdir -p /boot/efi
cr0x@server:~$ sudo mount /dev/sda4 /boot/efi
cr0x@server:~$ sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB
Installing for x86_64-efi platform.
Installation finished. No error reported.
cr0x@server:~$ sudo efibootmgr -v | head
BootCurrent: 0002
Timeout: 1 seconds
BootOrder: 0002,0001
Boot0002* GRUB HD(4,GPT,...)File(\EFI\GRUB\grubx64.efi)

Qué significa: GRUB se instaló en la ESP y existe una entrada de arranque en el firmware.

Decisión: Cambia el firmware a modo UEFI, asegúrate de que la entrada GRUB/EFI esté en primer lugar (o al menos presente), y luego reinicia.

Task 18 (Linux): Verificar que fstab/UUIDs no cambiaron inesperadamente

cr0x@server:~$ sudo blkid /dev/sda1 /dev/sda4
/dev/sda1: UUID="2e5c0b3f-8f3e-4d21-bc6a-7a8c0a2a4cbd" TYPE="ext4" PARTUUID="d9c3d8e9-01"
/dev/sda4: UUID="7A3C-1B2F" TYPE="vfat" PARTUUID="d9c3d8e9-04"

Qué significa: Los UUIDs de los sistemas de ficheros son estables; GPT añade PARTUUIDs.

Decisión: Si tu configuración de arranque usa PARTUUIDs, actualiza las configuraciones en consecuencia. Si montas por UUID, probablemente estés bien. Confirma que /etc/fstab incluya la ESP para UEFI.

Listas de verificación / plan paso a paso

Lista A: “Necesito que el disco del sistema Windows sea GPT para poder activar Secure Boot / baseline moderno”

1. Backup o snapshot (sí, incluso si es “no destructivo”). Asegúrate de poder restaurar la máquina, no solo los datos.
2. Confirma que el modo de arranque del SO es Legacy y que la conversión es necesaria (Task 1).
3. Identifica el disco correcto (Task 2) y confirma el mapeo de particiones de Windows (Task 3).
4. Suspende BitLocker si está activado (dependiendo de la política). Si no lo haces, espera solicitudes de clave de recuperación o, peor, fallo de arranque tras cambios en el firmware.
5. Ejecuta mbr2gpt /validate (Task 4). Si falla, arregla las razones (a menudo recuento/espacio de particiones).
6. Ejecuta mbr2gpt /convert (Task 5).
7. Reinicia en firmware y cambia a modo UEFI. Mantén Secure Boot desactivado hasta comprobar el arranque.
8. Arranca Windows, verifica que el estilo de disco es GPT (Task 6) y que el tipo de firmware es UEFI (Task 1 de nuevo).
9. Solo entonces activa Secure Boot si es requerido y reactiva la protección de BitLocker.

Lista B: “Servidor Linux, convertir disco del SO a GPT y mantener Legacy BIOS porque el firmware del proveedor es extraño”

1. Consigue acceso a consola (iLO/iDRAC/IPMI o al menos la consola de la VM). Trabajar con discos sin consola es una apuesta, no ingeniería.
2. Confirma el modo de arranque actual (Task 9). Si ya estás en UEFI, replantea por qué quieres legacy.
3. Confirma que la tabla actual es msdos (Task 11).
4. Convierte MBR→GPT con sgdisk --mbrtogpt (Task 12).
5. Relee la tabla de particiones (Task 13) o reinicia en modo mantenimiento.
6. Crea la partición BIOS boot (Task 14) si no existe.
7. Reinstala GRUB para destino BIOS (Task 15).
8. Reinicia y verifica. Conserva el medio de rescate hasta haber sobrevivido al menos un reinicio adicional.

Lista C: “Servidor Linux, convertir disco del SO a GPT y pasar a UEFI correctamente”

1. Confirma que la plataforma soporta UEFI y que puedes activarlo en el firmware.
2. Verifica el modo de arranque actual (Task 9). Si hoy es BIOS, lo cambiarás después de instalar el arranque EFI.
3. Convierte MBR→GPT (Task 12), luego relee (Task 13).
4. Crea una ESP y formateala FAT32 (Task 16). Tamaño típico: 260–512 MiB.
5. Monta la ESP en /boot/efi e instala GRUB EFI (Task 17).
6. Verifica que existe la entrada en NVRAM (efibootmgr -v como en Task 17).
7. Cambia el firmware a modo UEFI. Si el firmware soporta ambos modos, prefiere “UEFI only” una vez estable para evitar ambigüedad de arranque.
8. Verifica el arranque, luego confirma que el SO detecta UEFI (/sys/firmware/efi existe).

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

1) Síntoma: “No hay dispositivo de arranque” justo después de la conversión

Causa raíz: Disco convertido, pero el firmware sigue configurado en Legacy/CSM. Existen archivos de arranque UEFI, pero el firmware no los busca.

Solución: Entra al setup del firmware, cambia a modo UEFI, asegúrate de que “Windows Boot Manager” (o tu entrada de Linux) esté presente y priorizada.

2) Síntoma: mbr2gpt /validate falla con errores de diseño

Causa raíz: Demasiadas particiones, tipos de partición no soportados o espacio insuficiente para crear la ESP.

Solución: Reduce particiones (fusiona, elimina una partición de recuperación que puedas regenerar, o reduce C: para crear espacio). Luego vuelve a ejecutar validate. No sigas hasta que la validación tenga éxito.

3) Síntoma: Windows arranca, pero BitLocker pide la clave de recuperación cada vez

Causa raíz: Las mediciones de arranque del firmware/TPM cambiaron (Legacy→UEFI, toggles de Secure Boot, cambios en el orden de arranque) sin suspender y reasegurar correctamente BitLocker.

Solución: Suspende BitLocker antes del cambio; tras un arranque estable, vuelve a habilitar la protección para que se reasegure a la nueva ruta de arranque.

4) Síntoma: Linux arranca una vez, luego tras una actualización de firmware cae a PXE

Causa raíz: Las entradas de arranque UEFI en NVRAM fueron borradas o reordenadas por una actualización/reset del firmware.

Solución: Recrea la entrada con efibootmgr (desde un live ISO si hace falta) y considera instalar un cargador de fallback en \EFI\BOOT\BOOTX64.EFI en la ESP.

5) Síntoma: parted muestra GPT pero el kernel aún ve las particiones antiguas

Causa raíz: El kernel no ha releído la tabla de particiones; los dispositivos siguen mapeados con la geometría antigua.

Solución: Usa partprobe y vuelve a comprobar, o reinicia en mantenimiento. Evita operaciones de redimensionado hasta que el kernel concuerde.

6) Síntoma: Después de la conversión en Linux, aparece el prompt de GRUB rescue

Causa raíz: La imagen core de GRUB no puede encontrarse/incrustarse (BIOS sobre GPT sin partición bios_grub), o se instaló el target de GRUB equivocado.

Solución: Si te quedas en BIOS, añade la partición BIOS boot y reinstala GRUB con --target=i386-pc. Si cambiaste a UEFI, crea/monta la ESP e instala con --target=x86_64-efi.

7) Síntoma: El disco es GPT pero el instalador/recuperación de Windows no encuentra Windows

Causa raíz: Arrancaste el medio de recuperación en modo Legacy mientras el disco espera estructuras UEFI (o viceversa).

Solución: Arranca el entorno de recuperación en el mismo modo que pretendes usar para el SO (UEFI para disco de sistema GPT). Luego ejecuta acciones de reparación como bcdboot.

8) Síntoma: Todo funcionó, pero la monitorización informa “cambio de firma de disco”

Causa raíz: Algunas herramientas usan la firma MBR; GPT usa identificadores diferentes (PARTUUID/GUIDs).

Solución: Actualiza la configuración de monitorización/backup para usar UUIDs de sistema de ficheros o IDs de dispositivo estables en vez de firmas MBR.

Tres mini-historias del mundo empresarial (y lo que enseñan)

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

El equipo tenía una flota de servidores de aplicación “idénticos”. Mismo modelo, misma imagen de SO, misma automatización. Necesitaban Secure Boot para una nueva baseline de cumplimiento, y el plan era sencillo: convertir MBR a GPT, cambiar a UEFI, activar Secure Boot, seguir adelante.

En el primer host todo funcionó. En el segundo no arrancó. “No hay dispositivo de arranque.” La consola remota mostró un menú de arranque del firmware con dos discos, uno del que nadie recordaba el pedido. La automatización había aprovisionado un disco secundario pequeño meses antes para dumps de crash. En firmware estaba primero en el orden de arranque. En el SO no estaba montado ni usado. En la cabeza de todos, no existía.

Habían validado y convertido el disco de SO correcto. La falla fue más sencilla: el orden de arranque del firmware ahora prefería el otro disco porque la entrada UEFI no existía en él. El arranque legacy lo enmascaraba antes.

La solución fue aburrida: fijar la entrada UEFI correcta, deshabilitar el arranque desde el disco de dumps y asegurar que el proceso de provisión estableciera un orden de arranque determinista. La lección fue aguda: “Disco 0” no es un concepto de ingeniería; es una conveniencia de UI que cambia cuando el hardware cambia.

Añadieron una comprobación preflight en la automatización: enumerar discos, confirmar el serial del disco subyacente al volumen del SO y negarse a continuar si hay ambigüedad. Les costó un día hacerlo. Les salvó de repetir el mismo error a escala.

Mini-historia 2: La optimización que se volvió en contra

Otra organización quería acelerar las ventanas de mantenimiento. Alguien propuso convertir en el SO en ejecución para evitar reiniciar a entornos de recuperación. “Es la misma herramienta, funcionó en laboratorio.” Esa persona no estaba estrictamente equivocada.

Ejecutaron conversiones con /allowFullOS en lote, uno por uno. La mayoría tuvo éxito. Unas pocas fallaron la validación por diseños extraños—máquinas con particiones adicionales de tooling antiguo. En lugar de detenerse, el operador intentó “optimizar” borrando la partición más pequeña en caliente para ganar espacio.

En una máquina, esa “partición más pequeña” era una partición de recuperación del proveedor que también contenía un entorno de diagnóstico usado por soporte remoto. Borrarla no rompió el sistema en ejecución, así que parecía una victoria. Más tarde, un incidente separado requirió ese entorno de diagnóstico, y de pronto el procedimiento estándar de soporte dejó de funcionar. El cambio en almacenamiento no provocó el fallo; provocó la incapacidad de recuperarse rápidamente.

El postmortem no trató de avergonzar. Reconoció una realidad: optimizar para velocidad suele externalizar riesgo. La reparación fue estandarizar un layout de particiones soportado, documentar qué particiones se pueden eliminar y ejecutar la conversión desde WinRE cuando sea posible para reducir fallos dependientes del estado.

Siguieron mejorando la velocidad—pero haciendo el proceso predecible, no convirtiendo a los técnicos en cirujanos improvisados.

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

Una compañía financiera tenía una regla: cualquier cambio que afecte el arranque requería una ruta de recuperación probada. Al equipo de ops le resultaba tedioso. A los ingenieros les parecía lento. A los auditores les daba tranquilidad. Todos pusieron los ojos en blanco hasta que importó.

Durante una conversión MBR→GPT en una VM Windows crítica, la conversión tuvo éxito, pero la VM no arrancó tras cambiar a UEFI. La consola del hipervisor mostró un prompt de shell UEFI. No había entrada “Windows Boot Manager”. Clásico problema de NVRAM.

Porque el equipo había seguido la lista de verificación aburrida, ya tenían WinRE adjunto como CD virtual y habían confirmado que podían arrancarlo en modo UEFI. Montaron la ESP, ejecutaron bcdboot y recrearon los archivos de arranque en minutos. No fue necesario restaurar, no hubo pánico ni tiempo de inactividad prolongado.

La lección: no necesitas brillantez para sobrevivir problemas de arranque. Necesitas preparación y una ruta de regreso a conocido bueno. La checklist se sintió como burocracia hasta que fue un paracaídas.

Preguntas frecuentes (FAQ)

1) ¿Puedo convertir MBR a GPT sin perder datos?

A menudo sí—herramientas como Windows mbr2gpt y Linux sgdisk --mbrtogpt están diseñadas para ser no destructivas con el contenido de las particiones. Pero “no destructivo” no significa “sin riesgo”. Haz una copia de seguridad o snapshot y asegúrate de poder recuperar el arranque.

2) ¿Tengo que cambiar de Legacy BIOS a UEFI después de convertir?

Para discos de sistema Windows: sí, si quieres que arranque. Para Linux: no necesariamente. Linux puede arrancar en BIOS desde GPT con una partición BIOS boot y el target de GRUB correcto.

3) ¿Cuál es el tamaño mínimo de la ESP?

La práctica común es 260 MiB en Windows, y 260–512 MiB en Linux si podrías almacenar múltiples cargadores/kernels. Menos puede funcionar, pero ahorras céntimos y arriesgas euros.

4) ¿Por qué falla la validación de mbr2gpt cuando “solo” tengo unas pocas particiones?

No es solo el recuento; es el diseño y el espacio disponible para la ESP, además de los tipos de partición. También las particiones OEM y de recuperación pueden empujarte fuera de las restricciones de la herramienta. Arregla el diseño y vuelve a validar.

5) ¿Puedo hacer esto en un servidor remoto sin acceso a consola?

Puedes. No deberías. Si el firmware no cambia a UEFI correctamente o faltan entradas de arranque, necesitarás consola para arreglarlo. Si de verdad debes hacerlo, organiza acceso fuera de banda o manos remotas primero.

6) ¿Convertir a GPT mejorará el rendimiento?

No de forma significativa. Esto trata sobre límites de capacidad, flexibilidad de particiones y alineación con UEFI/Secure Boot. Si buscas rendimiento, mira el sistema de ficheros, el planificador de IO, la profundidad de cola y el layout de almacenamiento.

7) ¿Qué pasa con RAID, Storage Spaces, LVM o mdraid?

Normalmente está bien, pero importa la ruta del disco de arranque. Con RAID de hardware, conviertes el volumen lógico presentado al SO. Con LVM/mdraid, preserva los sectores de inicio de las particiones y sé explícito sobre los targets de instalación del cargador.

8) Después de la conversión, Windows arranca pero muestra cambios en “System Reserved”—¿debo preocuparme?

Espera cierto remodelado de particiones: se crea una ESP y los archivos de arranque se mueven. Preocúpate solo si el espacio libre es extremadamente justo o si las políticas esperan un layout de recuperación específico. Valida las funciones de arranque y recuperación después.

9) ¿Puedo convertir un disco de datos de MBR a GPT sin tocar el arranque?

Sí, y es menos arriesgado. Aun así: identifica el disco correcto, desmóntalo o ponlo offline si es posible, y verifica que las aplicaciones no dependan de firmas de disco MBR.

10) ¿Por qué a veces el firmware “olvida” mi entrada de arranque de Linux?

Las entradas de arranque UEFI viven en NVRAM. Las actualizaciones de firmware, resets o algunas herramientas de seguridad pueden borrarlas o reordenarlas. Mitiga con un cargador de fallback en la ESP y pasos de recuperación documentados.

Siguientes pasos que deberías hacer realmente

Si conviertes en producción, el trabajo no termina cuando el disco dice GPT. Termina cuando has probado la resiliencia del arranque.

1. Verifica el modo de arranque tras la conversión: Windows debe informar UEFI; Linux debe tener /sys/firmware/efi si te pasaste a UEFI.
2. Registra lo que cambió: layout del disco antes/después, qué versión de herramienta usaste y qué ajustes de firmware modificaste. Tu yo futuro no lo recordará.
3. Prueba un segundo reinicio tras cualquier cambio de política (Secure Boot, reactivar BitLocker, actualizaciones de kernel). Un arranque limpio es tranquilizador; dos son evidencia.
4. Confirma la ruta de recuperación: WinRE bootea en UEFI; un live ISO de Linux puede ver y montar la ESP/root; puedes reinstalar el cargador si hace falta.
5. Actualiza la automatización para detectar modo de arranque y estilo de partición para no tener una flota mixta que se comporte distinto durante parches y cumplimiento.

Convierte con cuidado, verifica sin piedad y trata el arranque como una dependencia de sistema—no como una propiedad mágica de “Disco 0”.