Reparación de arranque GPT/MBR: arreglar «No Boot Device» sin pérdida de datos

Qué significa realmente «No Boot Device» (y qué no significa)

El firmware (BIOS o UEFI) está intentando localizar un destino arrancable. Falla pronto, antes de que tu SO tenga oportunidad de responder. Esto aún no es un problema del sistema operativo; es un problema del «camino hacia el SO».

Ese camino es distinto según el estilo de arranque:

• Legacy BIOS + MBR: El BIOS lee el primer sector del disco (MBR). El MBR apunta al código de arranque (a menudo un “stage 1.5”) y luego al cargador del SO.
• Legacy BIOS + GPT (sí, existe): El BIOS no puede arrancar GPT de forma nativa; normalmente necesitas una partición BIOS boot para la imagen core de GRUB. Algunos sistemas lo simulan de forma pobre.
• UEFI + GPT: UEFI lee una EFI System Partition (ESP), una partición FAT32 que contiene binarios .efi. Usa entradas NVRAM para elegir qué .efi ejecutar.

Cuando ves «No Boot Device», normalmente estás en uno de estos grupos:

• El firmware busca en el lugar equivocado: orden de arranque incorrecto, disco equivocado, modo UEFI/Legacy equivocado.
• La tabla de particiones está bien, pero los metadatos de arranque están rotos: archivos del ESP faltantes, BCD de Windows ausente, instalación de GRUB rota, entrada NVRAM borrada.
• El disco está presente pero no legible: cambió el modo SATA, NVMe no detectado, modo RAID activado/desactivado, controlador raro, fallo real del disco.
• Alguien ya lo “arregló”: y su arreglo escribió en el disco equivocado.

Una cosa más: la reparación de arranque implica escribir. Incluso las herramientas “inocuas” pueden garabatear los primeros megabytes. Trátalo como cambiar reglas de firewall en producción: haz snapshot primero, cambia segundo, verifica tercero.

Hechos e historia que te ayudan a depurar

Los problemas de arranque son más fáciles cuando sabes por qué el mundo es así. Aquí hay algunos hechos concretos que aparecen en incidentes reales:

1. El MBR es pequeño por diseño: el código de arranque clásico del MBR vive en los primeros 446 bytes del sector 0, dejando 64 bytes para cuatro entradas de partición y 2 bytes para la firma 0x55AA.
2. GPT existe porque al MBR se le acabó la pista: la dirección de sectores de 32 bits del MBR te limita alrededor de 2 TiB con sectores de 512 bytes; GPT usa LBA de 64 bits y no tiene ese límite.
3. GPT aún mantiene un “MBR protector”: el sector 0 a menudo contiene un MBR que dice “una partición grande” tipo 0xEE para que las herramientas antiguas no traspasen el disco.
4. UEFI no “explora en busca de un SO” como la gente supone: usa entradas NVRAM que apuntan a binarios EFI concretos en una ruta de disco/partición específica.
5. La EFI System Partition es FAT intencionalmente aburrida: FAT32 se eligió por la amplia compatibilidad del firmware, no porque a alguien le encante.
6. Secure Boot cambia los modos de fallo: el disco puede estar perfecto y el cargador intacto, pero el firmware se niega a ejecutar un cargador sin firmar (o firmado de forma distinta).
7. Windows y Linux pueden coexistir, pero no se ponen de acuerdo sobre quién manda: las actualizaciones de Windows a veces restauran Windows Boot Manager como predeterminado, mientras que las instalaciones de Linux suelen poner a GRUB primero.
8. El arranque BIOS desde GPT es un caso especial: GRUB necesita una pequeña partición sin formatear “BIOS boot” (a menudo 1–2 MiB) para guardar piezas que no caben en el hueco del MBR.
9. Clonar discos puede duplicar silenciosamente identificadores: esto rompe entradas de arranque y a veces confunde el montaje a nivel de SO porque el sistema ve “dos discos iguales”.

Guía rápida de diagnóstico (comprueba primero/segundo/tercero)

Primero: comprobación del firmware (60 segundos)

• ¿Se detecta siquiera el disco? Si el BIOS/UEFI no lo ve, para. Esto es cableado, modo del controlador o hardware.
• ¿Estás en modo UEFI o Legacy/CSM? El modo equivocado es la causa número 1 de incidentes donde “no hay nada malo con el disco”.
• Orden de arranque: si acabas de enchufar una unidad USB, algún firmware decide cortésmente que es el nuevo rey.

Segundo: identifica el disco y el estilo de particionado (5 minutos)

• Desde un entorno live, determina: ¿GPT o MBR? ¿Hay ESP? ¿Hay partición BIOS boot? ¿Está presente la partición del SO?
• Si es Windows: localiza la partición EFI y la partición de Windows. Si es Linux: localiza /boot, /boot/efi y la partición root.

Tercero: decide qué estás reparando (10 minutos)

• UEFI/GPT: repara la entrada NVRAM y/o restaura archivos EFI; posiblemente reconstruye el BCD o reinstala GRUB EFI.
• BIOS/MBR: repara el código MBR, la bandera de partición activa (para algunos setups) y la cadena del cargador del SO.
• BIOS/GPT: asegúrate de que exista la partición BIOS boot; reinstala GRUB en el disco (no en la partición).

Condiciones de parada (cuando no debes “probar cosas al azar”)

• SMART muestra fallo evidente (sectores reasignados en aumento, errores de lectura). Clona primero.
• No estás seguro de qué disco es cuál. Etiquétalos. Desconecta unidades extras si puedes.
• El sistema está cifrado y no conoces el proceso de recuperación. Reparar el arranque es fácil; reparar “ups, rompí la única forma de desbloqueo” no lo es.

Antes de tocar nada: reglas de seguridad para evitar pérdida de datos

Si quieres “sin pérdida de datos”, tienes que actuar como si lo dijeras en serio.

Regla 1: No escribas hasta que puedas explicar qué vas a escribir

Comandos como bootrec /FixMbr, grub-install o efibootmgr -c no son “diagnósticos”. Modifican estado en disco o NVRAM. Úsalos solo después de haber identificado el disco correcto y el modo de arranque.

Regla 2: Clona o imagen si el disco parece enfermo

Si el disco está fallando, cada reinicio y cada escaneo de sistema de ficheros es una moneda al aire. Haz una imagen hacia otro disco y trabaja sobre la copia.

Regla 3: Prefiere cambios reversibles

Cambiar el orden de arranque UEFI, crear una nueva entrada NVRAM o reinstalar un cargador en el ESP suele ser reversible. Convertir GPT↔MBR in situ no es una “reparación”; es una migración con filos afilados.

Regla 4: Un solo disco conectado es la mejor gestión

Si es un portátil, puede que no tengas ese lujo. En sobremesas y servidores, desconecta todos los discos que no son el objetivo. Previene el error clásico: arreglaste perfectamente el disco equivocado.

Broma corta #1: La reparación de arranque es como una cirugía: es fácil ser valiente cuando no son tus datos sobre la mesa.

Tareas prácticas: comandos, salidas, decisiones (12+)

Estas tareas asumen que arrancaste un USB live de Linux (porque es una buena caja de herramientas neutral) a menos que la tarea sea específica de Windows. Los comandos son realistas. Las salidas son ejemplos; las tuyas variarán. El punto es cómo interpretarlas y decidir.

Task 1: Confirmar si el entorno live arrancó en modo UEFI o BIOS

cr0x@server:~$ ls -ld /sys/firmware/efi
drwxr-xr-x 5 root root 0 Feb  4 10:12 /sys/firmware/efi

Qué significa: Si ese directorio existe, estás en modo UEFI. Si no existe, estás en modo Legacy BIOS.

Decisión: Ajusta el modo de reparación al modo en el que está instalado el SO. Si Windows se instaló en modo UEFI pero arrancaste el live USB en Legacy, perseguirás fantasmas.

Task 2: Identificar discos y tablas de particiones rápidamente

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,PARTTYPE,PARTLABEL,MOUNTPOINTS
NAME        SIZE TYPE FSTYPE PARTTYPE                             PARTLABEL    MOUNTPOINTS
nvme0n1   476.9G disk
├─nvme0n1p1   260M part vfat   c12a7328-f81f-11d2-ba4b-00a0c93ec93b EFI System
├─nvme0n1p2    16M part        e3c9e316-0b5c-4db8-817d-f92df00215ae Microsoft reserved
├─nvme0n1p3   200G part ntfs   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 Basic data
└─nvme0n1p4 276.6G part ext4   0fc63daf-8483-4772-8e79-3d69d8477de4 Linux filesystem

Qué significa: Los GUIDs de tipo de partición GPT aparecen en PARTTYPE. La ESP es vfat y tiene el conocido GUID EFI.

Decisión: Esto es un sistema UEFI/GPT. La reparación de arranque se centrará en la ESP y las entradas UEFI, no en las banderas “active” del MBR.

Task 3: Verificar GPT vs MBR con parted (más explícito)

cr0x@server:~$ sudo parted -s /dev/nvme0n1 print
Model: Samsung SSD 970 (nvme)
Disk /dev/nvme0n1: 512GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name                          Flags
 1      1049kB  274MB   273MB   fat32        EFI System Partition          boot, esp
 2      274MB   291MB   16.8MB               Microsoft reserved partition  msftres
 3      291MB   215GB   215GB   ntfs         Basic data partition          msftdata
 4      215GB   512GB   297GB   ext4                                       

Qué significa: Partition Table: gpt y las banderas boot, esp indican la EFI System Partition.

Decisión: No pierdas tiempo con comandos de reparación MBR. Puede que necesites montar la ESP y restaurar archivos del cargador.

Task 4: Comprobar si la ESP contiene archivos de arranque plausibles

cr0x@server:~$ sudo mkdir -p /mnt/esp
cr0x@server:~$ sudo mount /dev/nvme0n1p1 /mnt/esp
cr0x@server:~$ ls -R /mnt/esp/EFI | head
/mnt/esp/EFI:
Boot
Microsoft
ubuntu

/mnt/esp/EFI/Boot:
BOOTX64.EFI

Qué significa: Tienes directorios estándar. EFI/Boot/BOOTX64.EFI es la ruta de respaldo que muchos firmwares prueban si faltan entradas NVRAM.

Decisión: Si /mnt/esp/EFI está vacío o falta Microsoft/ubuntu, probablemente hay corrupción o eliminación de la ESP. La reparación será “restaurar archivos”, no “reparticionar el disco”.

Task 5: Inspeccionar entradas NVRAM UEFI (sistemas UEFI)

cr0x@server:~$ sudo efibootmgr -v
BootCurrent: 0002
Timeout: 1 seconds
BootOrder: 0002,0000,0001
Boot0000* Windows Boot Manager  HD(1,GPT,3c4b2c2e-...,0x800,0x82000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)
Boot0001* ubuntu                HD(1,GPT,3c4b2c2e-...,0x800,0x82000)/File(\EFI\ubuntu\shimx64.efi)
Boot0002* UEFI: USB Flash Disk  PciRoot(0x0)/Pci(0x14,0x0)/USB(0x3,0x0)/HD(1,MBR,0x1234,0x800,0x3a9800)

Qué significa: Hay entradas para Windows y Ubuntu. Eso es bueno. Si el sistema sigue mostrando “No Boot Device”, puede que esté arrancando en modo Legacy, o el disco no se detecta al inicio, o Secure Boot bloquea el cargador.

Decisión: Si falta la entrada Windows Boot Manager, recréala. Si las entradas existen pero apuntan al GUID de disco erróneo (común después de clonar), arréglalas o usa la ruta de respaldo.

Task 6: Recrear una entrada Windows Boot Manager faltante (UEFI)

cr0x@server:~$ sudo efibootmgr -c -d /dev/nvme0n1 -p 1 -L "Windows Boot Manager" -l '\EFI\Microsoft\Boot\bootmgfw.efi'
BootCurrent: 0002
BootOrder: 0003,0002,0000,0001
Boot0003* Windows Boot Manager  HD(1,GPT,3c4b2c2e-...,0x800,0x82000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)

Qué significa: Creaste una nueva entrada NVRAM apuntando al binario EFI de Microsoft en la partición 1.

Decisión: Reinicia y selecciónala desde el firmware. Si arranca, has terminado. Si el firmware olvida la entrada tras reiniciar, sospecha de batería CMOS/bug del firmware o rarezas de “Fast Boot”; usa la ruta de respaldo o actualiza el firmware.

Task 7: Comprobar banderas de BIOS/MBR y partición “active” (sistemas legacy)

cr0x@server:~$ sudo fdisk -l /dev/sda
Disk /dev/sda: 500 GiB, 536870912000 bytes, 1048576000 sectors
Disklabel type: dos
Device     Boot    Start        End    Sectors   Size Id Type
/dev/sda1  *        2048  1026047  1024000   500M  7 HPFS/NTFS/exFAT
/dev/sda2        1026048 1048575999 1047549952 499.5G 7 HPFS/NTFS/exFAT

Qué significa: Disklabel type dos indica MBR. El * marca la partición activa (bootable), relevante para algunas cadenas de arranque BIOS.

Decisión: Si no hay partición activa en una instalación BIOS/Windows, márcala (con cuidado) en la partición system-reserved/boot, no en la partición de datos.

Task 8: Establecer la bandera activa en la partición correcta (MBR)

cr0x@server:~$ sudo fdisk /dev/sda
Command (m for help): a
Partition number (1-2): 1
Command (m for help): p

Device     Boot    Start        End    Sectors   Size Id Type
/dev/sda1  *        2048  1026047  1024000   500M  7 HPFS/NTFS/exFAT
/dev/sda2        1026048 1048575999 1047549952 499.5G 7 HPFS/NTFS/exFAT

Command (m for help): w
The partition table has been altered!

Qué significa: Has cambiado la bandera bootable.

Decisión: Reinicia y prueba. Si el arranque sigue fallando, probablemente necesites reparar el código de arranque (MBR/VBR/BCD) más que las banderas.

Task 9: Evaluar la salud del disco antes de escribir estructuras de arranque

cr0x@server:~$ sudo smartctl -a /dev/sda | egrep -i "Reallocated|Pending|Uncorrect|SMART overall"
SMART overall-health self-assessment test result: PASSED
Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0

Qué significa: No hay señales obvias de fallo del medio. “PASSED” no es una garantía, pero no está gritando tampoco.

Decisión: Procede con la reparación de arranque. Si los pending sectors fueran distintos de cero, clona primero y evita herramientas que escriban mucho.

Task 10: Clonar un disco antes de las reparaciones si sospechas problemas

cr0x@server:~$ sudo ddrescue -f -n /dev/sda /dev/sdb /mnt/recovery/ddrescue.log
GNU ddrescue 1.27
Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:        0 B,  errsize:        0 B,  errors:       0
Current status
rescued:  500000 MB,  errsize:      0 B,  current rate:  120 MB/s
ipos: 500000 MB,  errors:       0,    average rate:  115 MB/s
Finished

Qué significa: Copiaste el disco origen a un disco destino mientras registrabas la recuperabilidad. ddrescue está hecho para medios imperfectos.

Decisión: Haz todas las reparaciones de arranque contra /dev/sdb (la copia). Mantén /dev/sda intacto como evidencia original.

Task 11: Montar particiones del sistema Linux correctamente para reparar con chroot

cr0x@server:~$ sudo mount /dev/nvme0n1p4 /mnt
cr0x@server:~$ sudo mount /dev/nvme0n1p1 /mnt/boot/efi
cr0x@server:~$ for i in /dev /dev/pts /proc /sys /run; do sudo mount --bind $i /mnt$i; done
cr0x@server:~$ sudo chroot /mnt /bin/bash
root@server:/# ls /boot/efi/EFI
Boot  Microsoft  ubuntu

Qué significa: Estás operando dentro del entorno del SO instalado, con la ESP montada donde el SO la espera.

Decisión: Este es el contexto correcto para reinstalar GRUB o regenerar initramfs sin estropear el entorno del live USB.

Task 12: Reinstalar GRUB para sistemas UEFI (Linux)

cr0x@server:~$ sudo chroot /mnt /bin/bash -c "grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu && update-grub"
Installing for x86_64-efi platform.
Installation finished. No error reported.
Generating grub configuration file ...
Found Windows Boot Manager on /dev/nvme0n1p1@/EFI/Microsoft/Boot/bootmgfw.efi
done

Qué significa: El binario EFI de GRUB y su configuración se instalaron, y detectó Windows también.

Decisión: Reinicia y elige “ubuntu” o ajusta el orden de arranque. Si Secure Boot está activado y instalaste GRUB no firmado, puede que necesites paquetes shim o desactivar Secure Boot temporalmente.

Task 13: Instalar GRUB para sistemas BIOS/MBR (Linux)

cr0x@server:~$ sudo chroot /mnt /bin/bash -c "grub-install /dev/sda && update-grub"
Installing for i386-pc platform.
Installation finished. No error reported.
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.0-31-generic
done

Qué significa: GRUB se instaló en el área de arranque MBR del disco (no en una partición), y se reconstruyó la configuración.

Decisión: Reinicia. Si sigue fallando, verifica que el BIOS esté configurado para arrancar desde /dev/sda y que el disco sea el primero en el orden.

Task 14: Detectar la necesidad de partición BIOS/boot en GPT (Linux en GPT en modo BIOS)

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

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  538MB   537MB   ext4
 2      538MB   1000GB  999GB   ext4

Qué significa: Disco GPT, pero no hay una pequeña partición con la bandera bios_grub. El arranque BIOS de GRUB desde GPT típicamente la necesita.

Decisión: Si la máquina arranca en modo Legacy, crea una partición BIOS boot de 1–2 MiB (sin formatear) y marca la bandera bios_grub, sólo si puedes reducir/mover particiones con seguridad. Si puedes cambiar el firmware a modo UEFI, haz eso en su lugar. Es más limpio.

Task 15: Windows UEFI: reconstruir BCD desde el entorno de recuperación

Desde el Símbolo del sistema de Recuperación de Windows (no Linux), típicamente asignas una letra de unidad a la ESP y reconstruyes los archivos de arranque. Ejemplo:

cr0x@server:~$ diskpart
DISKPART> list vol
Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
----------  ---  -----------  -----  ----------  -------  ---------  --------
Volume 0     C                NTFS   Partition    200 GB  Healthy    Boot
Volume 1          SYSTEM      FAT32  Partition    260 MB  Healthy    System

DISKPART> sel vol 1
DISKPART> assign letter=S
DISKPART> exit

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

Qué significa: bcdboot copió los archivos de arranque de Windows a la ESP y construyó un almacén BCD apto para UEFI.

Decisión: Reinicia y pon Windows Boot Manager primero en el firmware si es necesario. Si falla, puede que la ESP esté montada mal, o que la instalación de Windows no esté realmente en C:\Windows en el modo de recuperación—verifica las letras de unidad.

Task 16: Windows BIOS/MBR: reparar la cadena de arranque (con cuidado)

cr0x@server:~$ bootrec /FixMbr
The operation completed successfully.
cr0x@server:~$ bootrec /FixBoot
Access is denied.
cr0x@server:~$ bootrec /RebuildBcd
Successfully scanned Windows installations.
Total identified Windows installations: 1
[1]  D:\Windows
Add installation to boot list? Yes(Y)/No(N)/All(A): Y
The operation completed successfully.

Qué significa: /FixMbr escribió código MBR de arranque. Es común que /FixBoot falle con “Access is denied” en algunas versiones de Windows e indica problemas de permisos de partición/ESP (especialmente cuando en realidad estás en UEFI/GPT) o mismatch del entorno de recuperación.

Decisión: Si realmente estás en BIOS/MBR, asegúrate de que la partición del sistema correcta esté activa y tenga un sector de arranque; a veces se usa bootsect /nt60 SYS. Si el disco es GPT, deja de usar herramientas BIOS y cambia a reparación UEFI (bcdboot).

Task 17: Verificar la integridad del sistema de archivos en la ESP (FAT puede comportarse raro)

cr0x@server:~$ sudo umount /mnt/esp
cr0x@server:~$ sudo fsck.vfat -a /dev/nvme0n1p1
fsck.fat 4.2 (2021-01-31)
FATs differ but appear to be intact. Using first FAT.
Reclaimed 12 unused clusters (49152 bytes) in 3 chains.

Qué significa: Se repararon pequeñas inconsistencias de FAT. Si reporta corrupción severa, puede que tengas que recrear la ESP y restaurar archivos de arranque.

Decisión: Después de reparar, monta de nuevo y verifica el contenido del directorio EFI.

Vías de reparación por plataforma y estilo de arranque

UEFI + GPT: la opción “moderna” por defecto

Esto es la mayoría de portátiles y sobremesas de la última década. Tu recuperación gira en torno a tres cosas: particiones del disco, archivos en la ESP y entradas NVRAM.

• Si el disco no se detecta en el firmware: no es un problema del cargador. Revisa modo del controlador (AHCI vs RAID), ajustes NVMe, cableado, actualizaciones de firmware.
• Si la ESP existe pero está vacía/dañada: restaura EFI/Microsoft con bcdboot (Windows) o reinstala GRUB (Linux). Usa fsck.vfat para reparar corrupciones menores.
• Si la ESP está bien pero faltan entradas de arranque: recrea entradas con efibootmgr (Linux) o deja que la reparación de Windows las regenere (Recuperación de Windows).
• Si las entradas existen pero apuntan al ID de disco equivocado (tras clonar): crea nuevas entradas referenciando el disco/partición correctos y elimina las antiguas.
• Si Secure Boot bloquea: usa shim/GRUB firmados, inscribe las claves apropiadas, o desactiva Secure Boot temporalmente para confirmar el diagnóstico.

Legacy BIOS + MBR: todavía vivo en appliances y sistemas antiguos

Este camino es menos “archivos” y más “pequeños segmentos de código de arranque”. Tus objetivos:

• Código de arranque MBR (primer sector)
• Sector de arranque de partición (VBR) para la partición activa (Windows) o configuración de etapas de GRUB (Linux)
• BCD (Windows) o configuración de GRUB (Linux)

El error más arriesgado aquí es instalar código de arranque en el disco equivocado. En sistemas con varios discos es común “arreglar” la unidad de datos mientras la unidad del SO queda intacta y ofendida.

Legacy BIOS + GPT: la configuración “no lo hagas a menos que debas”

Puede funcionar, pero es frágil y suele romperse tras mover discos o cambiar el firmware. Si lo heredas, lo mejor suele ser cambiar a arranque UEFI si el hardware lo soporta. Si no, necesitarás una partición BIOS boot y un GRUB instalado correctamente en el disco.

Qué no hacer: conversiones in situ durante una incidencia

Convertir MBR↔GPT es posible. También es un proyecto distinto a “reparación de arranque”, especialmente si intentas preservar datos. Hazlo solo con copias de seguridad y control de cambios. Si tu objetivo es arrancar hoy, no intentes una aventura con formato.

Broma corta #2: Las entradas NVRAM de UEFI son como la configuración de impresora: todo el mundo está seguro de que es simple hasta que es lo único entre tú y una fecha límite.

Tres mini-historias corporativas de la vida real

Incidente #1: La suposición equivocada («el disco está muerto»)

Recibimos un portátil de campo tras un viaje con “No Boot Device”. El usuario juraba que pasó tras un agotamiento de batería. El primer instinto del helpdesk fue “SSD muerto”, porque es una narrativa clara y a todos les gusta cambiar piezas.

Alguien reemplazó el SSD. Seguía sin arrancar. Ahora la narrativa cambió a “fallo de placa madre”, porque si el SSD nuevo no arranca, la máquina debe estar maldita. Un ticket estuvo dando vueltas un día mientras se acercaba la fecha límite del usuario.

Cuando llegó a un SRE con experiencia, el primer paso fue humillantemente simple: confirmar si el firmware estaba en modo UEFI. No lo estaba. Un reset del BIOS lo había puesto en Legacy/CSM. La instalación original de Windows era UEFI/GPT. En modo Legacy, el firmware buscó una firma de arranque MBR, no la encontró y se rindió.

Cambia el firmware a UEFI, Windows Boot Manager reaparece, la máquina arranca. El “SSD muerto” estaba bien. El SSD reemplazado ahora era un problema nuevo: tenía que ser borrado y devuelto al inventario correctamente.

Lección: No asumas que “No Boot Device” significa fallo de almacenamiento. A menudo significa que el firmware está mirando por la puerta equivocada.

Incidente #2: Optimización que salió mal (la ESP de la imagen dorada)

Un equipo de flota corporativa quería acelerar el aprovisionamiento. Crearon una imagen “golden” clonando discos: mismo layout GPT, mismo SO, mismas apps. Era rápido. Funcionó en laboratorio. Luego lo desplegaron en portátiles en serie.

Una semana después: máquinas aleatorias arrancando en “No Boot Device” después de una actualización de firmware. No todas. Suficientes para hacerlo interesante. El patrón fue desordenado: principalmente máquinas reimaginadas recientemente.

Causa raíz: el proceso de clonación duplicó identificadores de disco y dejó entradas NVRAM UEFI apuntando a una identidad de disco/partición específica que no era estable entre la serie. Algunos firmwares lo toleraron y “rescanearon”. Otros no. Tras la actualización, la NVRAM se limpió y la ruta de respaldo no se pobló consistentemente, así que las máquinas no tenían un puntero válido a un binario EFI.

La solución no fue mágica. Fue poco glamorosa: tras la imagen, siempre ejecutar un paso post que garantice que la ESP tenga un cargador de respaldo correcto y registre entradas de arranque limpias para ese dispositivo. Y deja de confiar en que el firmware se comporte igual entre proveedores.

Lección: El arranque es con estado. Clonar funciona hasta que no, y cuando falla lo hace en el peor momento: el primer arranque después de un cambio.

Incidente #3: La práctica aburrida y correcta que salvó el día (imaginar primero)

Un ingeniero de bases de datos informó de un puesto que dejó de arrancar tras un corte de energía. Tenía datasets locales que no estaban bien respaldados. El impulso inmediato en la sala fue “simplemente ejecutar bootrec” porque es rápido y da la sensación de estar haciendo algo.

La persona de almacenamiento hizo una pregunta: “¿Qué dice SMART?” Mostró sectores pendientes. No muchos, pero los suficientes. El disco no estaba muerto; era poco fiable. Cada lectura adicional podía estar bien—o podía ser la que lo llevase a una falla irreversible.

Hicieron una imagen con ddrescue a un SSD conocido bueno, usando un logfile para poder reintentar áreas malas sin volver a leer las buenas. Solo entonces hicieron reparaciones de arranque en la copia. La copia arrancó tras una reparación EFI y reconstrucción del BCD. El disco original más tarde se degradó, como se predijo.

Nada del proceso fue heroico. Fue disciplinado: preservar evidencia, trabajar en una copia, verificar resultados. Esa disciplina salvó los datos y evitó el incómodo postmortem “arreglamos el arranque pero perdimos tus archivos”.

Lección: Si hay algún indicio de problema del disco, copia primero. Reparar el arranque es barato; recuperar datos es caro.

Un máximo de operaciones que vale la pena recordar (idea parafraseada) viene de Richard Cook: Los sistemas complejos tienen éxito porque la gente se adapta y corrige constantemente problemas ocultos.

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

1) Síntoma: «No Boot Device» justo después de resetear el BIOS o actualizar el firmware

Causa raíz: El modo de arranque cambió (UEFI ↔ Legacy/CSM), o el orden de arranque se restableció.

Solución: Ajusta el modo al que se instaló el SO. Si hay GPT + ESP, usa modo UEFI. Restaura el orden de arranque a Windows Boot Manager o a tu entrada GRUB.

2) Síntoma: El disco aparece en el live USB de Linux pero no en el menú de arranque del firmware

Causa raíz: Falta la entrada de arranque UEFI; el firmware solo arranca entradas registradas y puede ignorar la ruta de respaldo, o la ruta ESP es incorrecta.

Solución: Usa efibootmgr -v para inspeccionar; crea una nueva entrada apuntando a \EFI\Microsoft\Boot\bootmgfw.efi o \EFI\ubuntu\shimx64.efi. Asegura la existencia de la ruta de respaldo \EFI\Boot\BOOTX64.EFI.

3) Síntoma: Las herramientas de reparación de Windows se quejan “Access is denied” en FixBoot

Causa raíz: A menudo en realidad estás en UEFI/GPT y usando la vía de reparación equivocada, o la partición del sistema no es la que crees.

Solución: Prefiere bcdboot C:\Windows /s S: /f UEFI después de asignar letra a la ESP. Verifica qué volumen es la ESP (FAT32, “System”).

4) Síntoma: Prompt de GRUB rescue, “unknown filesystem”

Causa raíz: GRUB no encuentra sus módulos/config por particiones movidas, core image sobrescrita o /boot faltante.

Solución: Arranca un Linux live, monta root y boot, chroot, reinstala GRUB (UEFI: --target=x86_64-efi; BIOS: instala en el disco), luego update-grub.

5) Síntoma: Sistema dual-boot ahora arranca directamente a Windows

Causa raíz: Una actualización de Windows puso Windows Boot Manager primero en el orden de arranque, o reescribió la entrada predeterminada.

Solución: Reordena desde la UI del firmware o con efibootmgr -o. Si falta la entrada GRUB, reinstálalo en la ESP y recrea la entrada.

6) Síntoma: Tras clonar el disco, el sistema solo arranca cuando el disco viejo está conectado

Causa raíz: La entrada de arranque apunta al disco original por GUID/ubicación. El clon tiene identidad de disco o GUID de partición distinto.

Solución: Crea nuevas entradas UEFI apuntando al clon. Considera eliminar duplicados y usar la ruta de respaldo EFI/Boot.

7) Síntoma: «No bootable device» solo cuando hay unidades USB conectadas

Causa raíz: El firmware prioriza medios extraíbles o trata una USB inserta como primera opción, pero no es arrancable.

Solución: Ajusta el orden de arranque; desactiva “boot from USB” si la política lo permite; o asegúrate de que la USB sea realmente arrancable.

8) Síntoma: Linux arranca, Windows falta en GRUB

Causa raíz: os-prober deshabilitado por política de la distro, o la partición de Windows no es accesible (BitLocker bloqueado, hibernado, o fast startup activado).

Solución: Desactiva Windows fast startup; desbloquea BitLocker si hace falta; activa y ejecuta os-prober donde corresponda, luego regenera la configuración de GRUB.

Listas de verificación / plan paso a paso

Checklist A: Flujo de riesgo mínimo para “No Boot Device” (genérico)

1. Entra al setup del firmware: confirma que el disco se detecta.
2. Confirma el modo de arranque: UEFI vs Legacy. No adivines.
3. Coloca el orden de arranque en el disco/entrada correcta (Windows Boot Manager o tu entrada Linux).
4. Arranca un USB live en el mismo modo (UEFI o BIOS) que el SO instalado.
5. Identifica discos y particiones (lsblk, parted).
6. Si SMART está mal, clona con ddrescue primero.
7. Monta la ESP e inspecciona los directorios EFI.
8. Inspecciona y arregla entradas UEFI (efibootmgr) o banderas MBR (fdisk).
9. Repara el cargador:
   • Windows UEFI: bcdboot
   • Windows BIOS: bootrec (y comprobaciones de partición activa)
   • Linux UEFI: grub-install --target=x86_64-efi
   • Linux BIOS: grub-install /dev/sdX
10. Reinicia una vez. Verifica. No hagas diez bucles de reparación; así es como pierdes el rastro del estado.

Checklist B: Reparación UEFI/GPT cuando la ESP existe pero falta la entrada de arranque

1. Monta la ESP y verifica que el .efi objetivo exista.
2. Crea una nueva entrada con efibootmgr -c apuntando a ella.
3. Opcionalmente crea/verifica la ruta de respaldo: \EFI\Boot\BOOTX64.EFI.
4. Pon en primer lugar la nueva entrada en el orden de arranque.
5. Reinicia y confirma.

Checklist C: Flujo “no confío en este disco” (datos primero)

1. Arranca un USB live, no ejecutes reparaciones de sistema de archivos todavía.
2. Comprueba SMART; si hay sectores pendientes/incorregibles, para.
3. Clona con ddrescue a un disco nuevo.
4. Desconecta el disco original.
5. Repara el arranque en el clon.
6. Tras restaurar el arranque, haz una copia de seguridad real. No vivas en el clon como si nada hubiera pasado.

Preguntas frecuentes

1) ¿Puedo arreglar “No Boot Device” sin reinstalar el SO?

Normalmente, sí. La mayoría de las veces las particiones del SO están intactas y solo los metadatos de arranque están rotos: modo de firmware equivocado, entrada UEFI faltante, ESP dañada, BCD roto o GRUB roto.

2) ¿Cómo sé si el disco es GPT o MBR?

Desde Linux: parted -s /dev/sdX print muestra “Partition Table: gpt” o “msdos.” Desde Windows: diskpart → list disk muestra un * bajo GPT para discos GPT.

3) ¿Cuál es la forma más rápida de saber que estoy en el modo de arranque equivocado?

Si el disco es GPT y tiene una ESP, pero el firmware está en Legacy/CSM, a menudo obtendrás “No Boot Device.” A la inversa, una instalación MBR/BIOS no arrancará mágicamente en modo UEFI puro sin un cargador UEFI.

4) ¿Es seguro ejecutar bootrec o grub-install?

Es seguro cuando sabes qué disco estás apuntando y has decidido que es la reparación correcta. Es inseguro como juego de adivinanzas, especialmente en sistemas con varios discos. Si el disco falla, clona primero.

5) ¿Por qué UEFI a veces “olvida” entradas de arranque?

La NVRAM puede resetearse por actualizaciones de firmware, resets del BIOS o bugs del firmware. Algunos sistemas también actúan mal cuando cambian identificadores de disco tras clonar. Tener un cargador de respaldo válido en \EFI\Boot\BOOTX64.EFI ayuda.

6) ¿Necesito recrear la EFI System Partition si está corrompida?

No siempre. Las corrupciones menores de FAT se pueden reparar con fsck.vfat. Si la ESP falta, está muy dañada o la tabla de particiones fue alterada, puede que necesites recrearla y restaurar archivos de arranque (Windows: bcdboot; Linux: grub-install).

7) ¿Qué pasa con BitLocker o cifrado de disco completo?

El cifrado cambia tus prioridades. A menudo puedes reparar EFI/cargador sin tocar volúmenes cifrados, pero asegúrate de tener claves de recuperación y entender la cadena de arranque. No reparticiones para “arreglarlo”.

8) Mi sistema es dual-boot y ahora solo aparece un SO. ¿Perdí el otro SO?

No necesariamente. Los menús de arranque son solo punteros. El otro SO suele seguir presente; necesitas reparar la configuración de GRUB o restaurar el orden/entradas UEFI correctas.

9) ¿Debo convertir MBR a GPT (o viceversa) para arreglar el arranque?

No, no como primera opción. El desajuste de modo y los archivos de arranque faltantes son mucho más comunes. La conversión es un cambio controlado que requiere backups y planificación cuidadosa.

10) ¿Cuándo dejo de intentar reparaciones y lo trato como hardware?

Si el disco no se detecta en el firmware, si SMART muestra lectura de errores/pending sectors en aumento, o si no puedes leer particiones de forma fiable desde un entorno live, trátalo como fallo de hardware o medio. Imagínalo primero, luego recupera.

Conclusión: próximos pasos prácticos

Los fallos de arranque parecen dramáticos porque el sistema guarda un silencio absoluto, pero la solución suele ser aburrida: el firmware está en el modo equivocado, la ESP carece de archivos, o la entrada de arranque apunta a la nada.

Haz esto a continuación, en orden:

1. Confirma la detección del disco y el modo de arranque en el firmware.
2. Arranca un entorno live en el mismo modo que el SO instalado.
3. Identifica GPT vs MBR, luego localiza ESP/particiones del sistema.
4. Si el disco parece poco saludable, clona con ddrescue y repara la copia.
5. Repara la capa correcta: entradas UEFI + archivos ESP para UEFI/GPT; MBR/partición activa/BCD o GRUB para BIOS/MBR.
6. Reinicia una vez, verifica y luego haz una copia de seguridad real. Un cargador reparado no es una estrategia de backup.