¿Arranque dual roto? Restaura el cargador de arranque de Windows de forma segura

Reparar el cargador sin supersticiones: el modelo mental

Cuando Windows “no arranca” tras un cambio de arranque dual, normalmente estás tratando con una de cuatro capas que fallan:

Capa 1: Puntos de entrada del firmware (NVRAM de UEFI o BIOS)

Las máquinas UEFI almacenan entradas de arranque en NVRAM: pequeños punteros como “Boot0003 → \EFI\Microsoft\Boot\bootmgfw.efi on disk X partition Y”. Si ese puntero se borra, se renombra o apunta al disco equivocado, Windows puede estar perfectamente intacto y aun así ser inalcanzable.

Las máquinas con BIOS heredado no tienen entradas de arranque en NVRAM. Cargan el código de arranque de primera etapa desde el MBR del disco, que luego encuentra el sector de arranque de la partición activa, que luego encuentra un cargador de arranque. Diferente época, diferentes modos de fallo, mismo pánico.

Capa 2: El esquema de disco (GPT vs MBR y dónde vive la EFI System Partition)

En sistemas UEFI, la EFI System Partition (ESP) es una partición pequeña FAT32 que contiene cargadores de arranque para Windows, Linux y cualquier otra cosa que quiera su turno. La ESP no es opcional. Si falta, está dañada o se monta y modifica incorrectamente, la máquina se convierte en un pisapapeles muy caro con LEDs.

Capa 3: Los archivos del cargador (Windows Boot Manager)

Para Windows bajo UEFI, el archivo principal suele ser \EFI\Microsoft\Boot\bootmgfw.efi. Bajo BIOS/MBR, los “archivos del cargador” se refieren más al código de arranque del volumen y \Boot\BCD en la partición System Reserved (o a veces en C: si alguien “optimizó” cosas).

Capa 4: La tienda BCD (configuración de arranque de Windows)

BCD (Boot Configuration Data) es el menú de arranque y los parámetros de arranque de Windows. Si BCD está dañado, puedes llegar al Windows Boot Manager pero fallar en el salto final hacia el sistema operativo.

Tu trabajo es identificar qué capa falló, repararla y detenerte. No “también” reescribas todo solo porque tienes herramientas y emociones.

Una cita para recordar: “La esperanza no es una estrategia.” — idea parafraseada, usada a menudo en operaciones y fiabilidad.

Un chiste corto, para limpiar el paladar: Los cargadores de arranque son como la señalización de un aeropuerto: cuando está mal, técnicamente aún tienes un avión, pero no vas a ninguna parte.

Guía de diagnóstico rápido (comprueba primero, segundo, tercero)

Si quieres arreglar esto rápido, no empieces con conjuros de bootrec. Comienza con una triage en tres pasos que reduce el problema en minutos.

Primero: confirma el modo de firmware y el disco desde el que realmente estás arrancando

• Comprueba si Windows se instaló en modo UEFI o Legacy. Mezclar modos es la razón número 1 por la que las reparaciones “funcionan” pero nunca arrancan.
• Revisa el orden de arranque del firmware. Una instalación de Linux puede añadir una entrada nueva y empujar a Windows hacia abajo en la lista.
• Verifica qué disco físico contiene la ESP o la partición System Reserved. Las configuraciones de arranque dual con múltiples discos son donde las suposiciones inocentes van a morir.

Segundo: verifica que la ESP/partición del sistema exista y sea legible

• UEFI: encuentra la ESP FAT32, móntala y confirma que \EFI\Microsoft\Boot existe.
• BIOS: encuentra la partición “System Reserved” NTFS activa (o equivalente) y confirma que contiene \Boot\BCD.

Tercero: solo entonces repara la capa más pequeña rota

• ¿Falta la entrada NVRAM? Recrea la entrada (o ejecuta bcdboot que a menudo lo hace).
• ¿Faltan archivos de arranque? Reconstrúyelos en la ESP con bcdboot.
• ¿BCD dañado? Reconstruye BCD (con cuidado) después de identificar la instalación de Windows.
• ¿Código MBR dañado? Usa la vía MBR (bootrec, bootsect).

No saltes directamente a la cirugía de particiones. La mayoría de los eventos “Windows desapareció” son solo un problema de puntero de arranque.

Hechos y contexto interesantes para repetir en reuniones

1. UEFI reemplazó al BIOS gradualmente durante los años 2010, y muchas máquinas todavía ofrecen compatibilidad “Legacy” que causa instalaciones en modo mixto por accidente.
2. Los discos GPT no usan la bandera de partición “activa” como lo hacen los discos MBR; ese concepto es un artefacto de la era BIOS.
3. La EFI System Partition suele ser FAT32 porque el firmware puede leerla de manera confiable entre distintos proveedores, mucho antes de que cargue cualquier núcleo del sistema operativo.
4. Windows Boot Manager bajo UEFI es solo un archivo .efi; no es místico: bórralo o renómbralo y Windows pasa a estar “desaparecido”.
5. GRUB puede encadenar la carga de Windows, pero las actualizaciones de Windows a veces reescriben el orden de arranque para preferir Windows Boot Manager, lo que sorprende a usuarios de Linux.
6. BCD reemplazó a boot.ini (usado en versiones antiguas de Windows) para soportar escenarios de arranque más flexibles e interacciones modernas con el firmware.
7. Muchos sistemas OEM vienen con varias particiones de recuperación; eliminar “pequeñas particiones desconocidas” para “limpiar” puede borrar la única copia de archivos críticos de arranque.
8. BitLocker cambia el perfil de riesgo de las reparaciones de arranque: incluso reparaciones correctas pueden provocar solicitudes de clave de recuperación si la ruta de arranque cambia.
9. En sistemas con múltiples discos, los instaladores suelen elegir la “primera” ESP que encuentran (según la enumeración del firmware), no necesariamente el disco que tú asignaste mentalmente a cada SO.

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

A continuación hay tareas reales que puedes ejecutar desde el símbolo del sistema del Entorno de recuperación de Windows (WinRE) o desde un USB live de Linux. Cada tarea incluye: el comando, qué significa una salida típica y qué decisión tomar después.

Tarea 1: En WinRE, identifica discos y particiones (pistas UEFI vs BIOS)

cr0x@server:~$ diskpart
Microsoft DiskPart version 10.0.19041.1

DISKPART> list disk

  Disk ###  Status         Size     Free     Dyn  Gpt
  --------  -------------  -------  -------  ---  ---
  Disk 0    Online          476 GB      0 B        *
  Disk 1    Online          931 GB      0 B

DISKPART> list vol

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 0     D   WinRE        NTFS   Partition    980 MB  Healthy    Hidden
  Volume 1     S   SYSTEM       FAT32  Partition    100 MB  Healthy    System
  Volume 2     C   Windows      NTFS   Partition    475 GB  Healthy    Boot

Qué significa: Disk 0 es GPT (la estrella en la columna “Gpt”). El volumen S: es FAT32 y está marcado como “System”: esa es tu ESP. Estás en territorio UEFI.

Decisión: Usa la ruta de reparación UEFI y céntrate en la ESP + BCD/archivos de arranque. No ejecutes comandos centrados en MBR como bootrec /fixmbr a menos que te guste la confusión.

Tarea 2: Confirma la ruta de la instalación de Windows y las letras de unidad en WinRE

cr0x@server:~$ dir C:\Windows\System32
 Volume in drive C has no label.
 Volume Serial Number is 3A1B-19C2

 Directory of C:\Windows\System32

01/15/2026  10:21 AM    <DIR>          .
01/15/2026  10:21 AM    <DIR>          ..
...

Qué significa: Tu partición de Windows está montada como C: en WinRE (no siempre es así). Si dir falla, tu partición de Windows puede ser D: o E: en WinRE.

Decisión: Usa la letra correcta en los comandos posteriores. Las letras de unidad incorrectas son como la gente que “repara” el SO equivocado y luego culpa a los rayos cósmicos.

Tarea 3: Monta e inspecciona la ESP en WinRE (verificación básica)

cr0x@server:~$ diskpart
DISKPART> sel vol S
Volume 1 is the selected volume.

DISKPART> assign letter=Z
DiskPart successfully assigned the drive letter or mount point.

DISKPART> exit

cr0x@server:~$ dir Z:\EFI
 Volume in drive Z is SYSTEM
 Volume Serial Number is 8C2A-4E1D

 Directory of Z:\EFI

01/15/2026  10:18 AM    <DIR>          .
01/15/2026  10:18 AM    <DIR>          ..
01/15/2026  10:19 AM    <DIR>          Microsoft
01/15/2026  10:19 AM    <DIR>          ubuntu

Qué significa: La ESP existe, es legible y tiene directorios Microsoft y ubuntu. Eso es bueno. Si \EFI\Microsoft falta, probablemente la recrearás.

Decisión: Si la ESP se monta y lista archivos, prefiere la reparación mediante reconstrucción de archivos de arranque (bcdboot) antes que formatear la ESP. Formatear es el último recurso.

Tarea 4: Reconstruir archivos de arranque de Windows en la ESP con bcdboot (UEFI)

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

Qué significa: Los archivos de arranque de Windows se copiaron en la ESP y puede que se haya registrado una entrada de arranque. Esto arregla sorprendentemente a menudo el error de “Windows Boot Manager faltante”.

Decisión: Reinicia y selecciona “Windows Boot Manager” en el firmware. Si sigue arrancando en GRUB solamente, revisa el orden de arranque y las entradas NVRAM.

Tarea 5: Listar entradas de arranque del firmware desde un medio live de Linux (verificación UEFI)

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

Qué significa: El firmware ve entradas tanto para Windows Boot Manager como para ubuntu, y ambas apuntan a archivos en la misma ESP. Bien. Si falta la entrada de Windows o apunta al disco/partición equivocada, ya encontraste el problema.

Decisión: Si la entrada de Windows existe pero no es la primera, ajusta el orden de arranque. Si no existe, vuelve a ejecutar bcdboot o crea una entrada (avanzado).

Tarea 6: Confirma la partición ESP y el sistema de archivos desde Linux (no adivines)

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,PARTLABEL,PARTUUID,MOUNTPOINTS
NAME        SIZE TYPE FSTYPE PARTLABEL            PARTUUID                             MOUNTPOINTS
nvme0n1   476.9G disk
├─nvme0n1p1 100M part vfat   EFI System Partition  7C1B-...-...                        /mnt/esp
├─nvme0n1p2  16M part        Microsoft reserved   1a2b-...-...
└─nvme0n1p3 476G part ntfs   Basic data partition 3c4d-...-...                        /mnt/win

Qué significa: La ESP es vfat y pequeña (100M), Windows es NTFS. Si tu ESP está montada en un sitio extraño o está en un disco distinto al esperado, detente y mapea todo.

Decisión: Usa la ESP desde la que realmente arrancas, no la que desearías usar.

Tarea 7: Monta la ESP y verifica la ruta de arranque de Microsoft desde Linux

cr0x@server:~$ sudo mkdir -p /mnt/esp
cr0x@server:~$ sudo mount /dev/nvme0n1p1 /mnt/esp
cr0x@server:~$ ls -R /mnt/esp/EFI/Microsoft/Boot | head
/mnt/esp/EFI/Microsoft/Boot:
BCD
BCD.LOG
bootmgfw.efi
bootmgr.efi
memtest.efi

Qué significa: Los archivos existen. Si bootmgfw.efi está ausente, Windows no puede cargarse. Si solo existen directorios de Linux, los archivos de arranque de Windows fueron eliminados o nunca se crearon en esa ESP.

Decisión: Si faltan, prefiere bcdboot desde WinRE. Copiar .efi al azar desde Internet es la forma de acabar con “violación de Secure Boot” y un mal día.

Tarea 8: En WinRE, comprueba el estado de BitLocker antes de “arreglar” nada

cr0x@server:~$ manage-bde -status C:
BitLocker Drive Encryption: Configuration Tool version 10.0.19041
Volume C: [Windows]
    Size:                 475.00 GB
    BitLocker Version:    2.0
    Conversion Status:    Fully Encrypted
    Percentage Encrypted: 100.0%
    Protection Status:    Protection On
    Lock Status:          Unlocked
    Identification Field: Unknown
    Key Protectors:
        TPM
        Numerical Password

Qué significa: BitLocker está activado. Los cambios en la ruta de arranque pueden desencadenar solicitudes de clave de recuperación. No es un desastre, pero es un problema de coordinación si no tienes la clave.

Decisión: Si no tienes la clave de recuperación, pausa y recupérala desde tu cuenta/IT. Proceder sin ella es jugar con el acceso.

Tarea 9: Usa bootrec para escanear instalaciones de Windows (útil en BIOS/MBR, a veces en UEFI)

cr0x@server:~$ bootrec /scanos
Scanning all disks for Windows installations.

Please wait, since this may take a while...

Successfully scanned Windows installations.
Total identified Windows installations: 1
[1]  C:\Windows

Qué significa: WinRE puede ver una instalación de Windows. Si encuentra cero, puede que tengas un problema con drivers de almacenamiento/RAID, un volumen BitLocker bloqueado o corrupción del sistema de archivos.

Decisión: Si hay cero instalaciones, no reconstruyas BCD todavía. Primero haz visible y legible el volumen de Windows.

Tarea 10: Reconstruir BCD de forma limpia (UEFI y BIOS)

cr0x@server:~$ bcdedit /enum
The boot configuration data store could not be opened.
The system cannot find the file specified.

Qué significa: La tienda BCD falta o no está donde WinRE la espera. Esto es común tras cambios en la ESP.

Decisión: Usa bcdboot para regenerar un BCD nuevo en la partición del sistema/ESP correcta en lugar de intentar resucitar una tienda medio rota.

Tarea 11: Comprueba la salud del sistema de archivos en la partición de Windows desde WinRE

cr0x@server:~$ chkdsk C: /f
The type of the file system is NTFS.
Volume label is Windows.

Stage 1: Examining basic file system structure ...
File verification completed.
Stage 2: Examining file name linkage ...
Index verification completed.
Stage 3: Examining security descriptors ...
Security descriptor verification completed.
Windows has made corrections to the file system.
No further action is required.

Qué significa: El sistema de archivos tenía problemas menores y fueron corregidos. Si ves muchos sectores defectuosos o “no se puede recuperar”, tienes un problema de disco que se hace pasar por un problema de arranque.

Decisión: Si la salud del disco es cuestionable, deja de perseguir cargadores y empieza a planear preservación de datos y reemplazo de la unidad.

Tarea 12: Verifica que los archivos de arranque de Windows existan en la ESP tras la reparación

cr0x@server:~$ dir Z:\EFI\Microsoft\Boot
 Volume in drive Z is SYSTEM
 Volume Serial Number is 8C2A-4E1D

 Directory of Z:\EFI\Microsoft\Boot

01/15/2026  10:32 AM    <DIR>          .
01/15/2026  10:32 AM    <DIR>          ..
01/15/2026  10:32 AM           1,048,576 bootmgfw.efi
01/15/2026  10:32 AM              12,288 BCD

Qué significa: Los archivos clave están presentes. Si no lo están, la ESP no era la que creías o la copia falló por permisos/problemas del sistema de archivos.

Decisión: Si los archivos existen y aún no puedes arrancar Windows, el problema probablemente sea la entrada NVRAM, el comportamiento de Secure Boot/shim o requisitos de recuperación de BitLocker—no archivos faltantes.

Tarea 13: Desde Linux, verifica si instalaste Windows por accidente en modo BIOS (detección de modo mixto)

cr0x@server:~$ sudo parted -l | sed -n '1,120p'
Model: NVMe Device (nvme)
Disk /dev/nvme0n1: 512GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  106MB   105MB   fat32              boot, esp
 2      106MB   123MB   16.8MB                     msftres
 3      123MB   512GB   512GB   ntfs               msftdata

Qué significa: Este disco es GPT con una ESP. Eso es consistente con Windows UEFI. Si ves una tabla MBR (“msdos”) con una partición NTFS “activa” y sin ESP, eso es Windows en modo Legacy.

Decisión: Adecua tu estrategia de reparación a lo que hay realmente en disco. No intentes “convertir a UEFI” una instalación BIOS a mitad del incidente a menos que estés preparado para una interrupción más larga.

Tarea 14: Desde WinRE, marca la partición correcta como activa (solo BIOS/MBR)

cr0x@server:~$ diskpart
DISKPART> list disk

  Disk ###  Status         Size     Free     Dyn  Gpt
  --------  -------------  -------  -------  ---  ---
  Disk 0    Online          476 GB  1024 KB

DISKPART> sel disk 0
Disk 0 is now the selected disk.

DISKPART> list part

  Partition ###  Type              Size     Offset
  -------------  ----------------  -------  -------
  Partition 1    Primary            500 MB  1024 KB
  Partition 2    Primary            475 GB   501 MB

DISKPART> sel part 1
Partition 1 is now the selected partition.

DISKPART> active
DiskPart marked the current partition as active.

DISKPART> exit

Qué significa: Marcaste una partición como activa para que el código de arranque del BIOS sepa dónde buscar a continuación. En GPT/UEFI, esto es irrelevante y a veces engañoso.

Decisión: Haz esto solo si confirmaste modo MBR/Legacy. Si el disco es GPT, aléjate de active.

Ruta de reparación A: UEFI + GPT (la mayoría de sistemas modernos)

Si tu sistema es UEFI (y la mayoría de máquinas posteriores a 2012 lo son), trata la ESP como infraestructura compartida. Quieres que Windows Boot Manager se restaure en la ESP y que exista una entrada NVRAM que apunte a ella.

Paso 1: Entra al Símbolo del sistema de WinRE

Usa un USB de instalación de Windows o medios de recuperación. Elige “Repair your computer” → “Troubleshoot” → “Command Prompt”. Si el diseño del teclado está mal, arréglalo pronto; escribir claves de recuperación con un diseño incorrecto es una comedia que no quieres.

Paso 2: Identifica la ESP y la partición de Windows

Usa diskpart, list vol. La ESP será FAT32, pequeña (100–550MB típicamente) y marcada como “System”. La partición de Windows suele ser NTFS y grande.

Paso 3: Asigna letras y ejecuta bcdboot

Esta es la reparación UEFI más limpia en el mundo Windows: copia archivos de arranque en la ESP y crea una tienda BCD para la instalación que indiques.

cr0x@server:~$ diskpart
DISKPART> list vol

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

DISKPART> sel vol 1
Volume 1 is the selected volume.

DISKPART> assign letter=Z
DiskPart successfully assigned the drive letter or mount point.

DISKPART> exit

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

Qué acabas de hacer: Le dijiste a Windows: “Usa la instalación de Windows en C:\Windows, pon su cargador en Z: (la ESP) y hazlo compatible con UEFI.”

Paso 4: Confirma los archivos en la ESP

Si los archivos no aparecieron donde esperabas, no reinicies y esperes. Confirma.

Paso 5: Arregla el orden de arranque del firmware si es necesario

Si la máquina sigue arrancando en GRUB por defecto, puede que simplemente esté eligiendo la entrada ubuntu primero. Puedes reordenar en la configuración del firmware, o desde Linux con efibootmgr.

cr0x@server:~$ sudo efibootmgr
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001,0000
Boot0000* Windows Boot Manager
Boot0001* ubuntu

Decisión: Si quieres Windows primero, reordena. Si prefieres GRUB primero, déjalo. Pero decide, no dejes que suceda por deriva.

Realidades de Secure Boot y shim

Secure Boot complica el arranque dual porque el firmware solo cargará binarios EFI firmados. Muchas distribuciones de Linux usan un shim firmado (shimx64.efi) que luego carga GRUB. Windows usa el gestor de arranque firmado por Microsoft. Si reemplazas archivos de arranque con binarios no firmados o intentas encadenar mal los componentes, Secure Boot te bloqueará.

Regla: si Secure Boot está habilitado y no tienes una razón sólida para desactivarlo, mantenlo habilitado y usa rutas de arranque firmadas. La “razón sólida” suele ser “estoy desarrollando el kernel”, no “mi arranque falló y estoy impaciente”.

Ruta de reparación B: BIOS heredado + MBR

Esto es para sistemas más antiguos, o sistemas configurados intencionalmente en modo legacy. Aquí tus objetivos son: el código MBR, el sector de arranque de la partición activa y la tienda BCD.

Paso 1: Confirma que realmente estás en modo BIOS/MBR

En diskpart, la columna “Gpt” estará vacía para el disco del sistema. También verás el concepto de partición “activa” que importa.

Paso 2: Identifica la partición System Reserved (o la partición de arranque)

Diseño común: una partición NTFS de 100–500MB llamada “System Reserved” que contiene \Boot\BCD. Si falta, los archivos de arranque de Windows pueden estar en C: (no es ideal, pero ocurre).

Paso 3: Marca la partición correcta como activa

Solo una partición debe estar activa en un disco MBR. Si herramientas de Linux la cambiaron, el BIOS arrancará lo equivocado sin problemas.

Paso 4: Repara el MBR y el sector de arranque (sé preciso)

cr0x@server:~$ bootrec /fixmbr
The operation completed successfully.

cr0x@server:~$ bootrec /fixboot
The operation completed successfully.

Qué significa: Se escribió el código de arranque MBR y el sector de arranque de la partición. Si /fixboot devuelve “Access is denied”, puede que tengas que asignar una letra a la partición del sistema y ejecutar bootsect o usar bcdboot según la versión de Windows y el esquema.

Paso 5: Reconstruye BCD

cr0x@server:~$ bootrec /rebuildbcd
Scanning all disks for Windows installations.

Please wait, since this may take a while...

Successfully scanned Windows installations.
Total identified Windows installations: 1
[1]  C:\Windows
Add installation to boot list? Yes(Y)/No(N)/All(A): y
The operation completed successfully.

Decisión: Si /rebuildbcd no encuentra instalaciones, detente y averigua por qué Windows no es detectable (drivers, BitLocker, NTFS dañado).

Paso 6: Prefiere bcdboot cuando BCD está hecho un lío

En muchos casos, especialmente con historiales de particionado extraños, bcdboot es más determinista que bootrec /rebuildbcd. Señalas Windows y él genera lo que necesita en la partición del sistema.

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

Nota: Aquí S: sería la partición System Reserved a la que asignaste una letra. No adivines—confirma con dir S:\Boot.

Segundo chiste corto (y hemos terminado): MBR significa “Mostly Bad Regrets” cuando ejecutas fixmbr en el disco equivocado.

Cuidados posteriores: mantener estable el arranque dual

Haz la ESP aburrida de nuevo

La ESP es estado compartido. El estado compartido merece respeto: haz copia de seguridad (al menos del directorio EFI), mantenla pequeña y limpia, y no la montes en modo lectura-escritura en Linux a menos que estés haciendo algo intencional.

Decide quién “posee” el arranque por defecto

Elige una:

• Windows Boot Manager como predeterminado, y usa el menú de arranque del firmware para seleccionar Linux cuando haga falta.
• GRUB como predeterminado, y encadena la carga de Windows. Esto es amigable para flujos centrados en Linux pero puede verse afectado por actualizaciones de firmware o actualizaciones de Windows.

Lo que debes evitar: una situación donde las actualizaciones de Windows reinician el orden de arranque cada trimestre y lo vuelves a arreglar cada trimestre. Eso no es arranque dual; eso es trastorno afectivo estacional.

BitLocker: suspende antes de cambios grandes en el arranque

Si usas BitLocker, considera suspender la protección antes de cambios importantes en el cargador de arranque (actualizaciones de firmware, reconstrucción de la ESP, cambios significativos de particiones) y luego volver a habilitar después de confirmar un arranque limpio. Eso reduce las solicitudes sorpresa de recuperación.

Sistemas con múltiples discos: sé explícito sobre dónde vive la ESP

Si tienes dos unidades (por ejemplo NVMe para Windows, SSD SATA para Linux), tienes dos opciones que funcionan:

• ESP compartida en un disco (simple, pero acopla las unidades).
• ESP separada por disco (más resiliente, pero requiere entradas de firmware y disciplina del instalador).

Lo que no funciona: creer que el instalador “hará lo obvio”. Los instaladores hacen lo primero que encuentran.

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

1) Síntoma: “No hay dispositivo de arranque” después de instalar Linux

Causa raíz: El orden de arranque del firmware cambió, o la entrada NVRAM de Windows Boot Manager se eliminó/ sobrescribió.

Solución: Usa la configuración del firmware para seleccionar Windows Boot Manager; si falta, ejecuta bcdboot C:\Windows /s Z: /f UEFI después de montar la ESP.

2) Síntoma: Arranca directo a GRUB, Windows falta en el menú

Causa raíz: La configuración de GRUB no detecta Windows, o los archivos de Windows Boot Manager faltan en la ESP.

Solución: Confirma que los archivos de arranque de Windows existen en la ESP; si no, reconstruye con bcdboot. Si existen, regenera la configuración de GRUB desde Linux (específico de la distribución) o usa el menú del firmware para Windows.

3) Síntoma: Prompt de GRUB (grub>) o “minimal BASH-like line editing”

Causa raíz: GRUB no encuentra su configuración o partición raíz, a menudo después de mover particiones o cambiar UUIDs.

Solución: No luches contra GRUB si tu objetivo es Windows. Arranca WinRE y restaura el cargador de Windows como predeterminado; luego repara GRUB desde Linux cuando tengas tiempo.

4) Síntoma: Aparece Windows Boot Manager y luego pantalla azul al inicio

Causa raíz: No necesariamente relacionado con el cargador. Podría ser cambios en controladores de almacenamiento, corrupción del sistema de archivos o una actualización de Windows fallida.

Solución: Ejecuta chkdsk desde WinRE; considera reparaciones con sfc/dism (fuera del alcance de solo reparaciones de cargador). La reparación del cargador no arreglará un kernel roto.

5) Síntoma: “Boot configuration data file is missing” o errores de BCD

Causa raíz: Tienda BCD ausente/corrupta, partición del sistema incorrecta o ESP no utilizada.

Solución: Para UEFI, monta la ESP y ejecuta bcdboot. Para BIOS, asegúrate de la partición activa correcta y ejecuta bcdboot ... /f BIOS o bootrec /rebuildbcd.

6) Síntoma: “Access is denied” en bootrec /fixboot

Causa raíz: Común en algunos entornos de recuperación de Windows 10/11 debido a permisos de partición o partición objetivo incorrecta.

Solución: Usa bcdboot para recrear archivos de arranque en la partición correcta. Si es BIOS/MBR, asegúrate de que System Reserved tenga una letra asignada y sea la partición activa.

7) Síntoma: Windows solicita la clave de recuperación de BitLocker después de reparar el arranque

Causa raíz: Las mediciones TPM cambiaron porque la cadena de arranque cambió (nuevo binario EFI, nueva ruta, entrada de arranque distinta).

Solución: Introduce la clave de recuperación, arranca con éxito y luego considera suspender y volver a habilitar BitLocker para “enseñar” al TPM el nuevo estado de arranque.

8) Síntoma: La reparación funciona una vez y luego falla tras una actualización de firmware

Causa raíz: La actualización de firmware restableció el orden de arranque o eliminó entradas NVRAM.

Solución: Recrea entradas usando bcdboot (Windows) o efibootmgr (Linux). Mantén el contenido de la ESP estable y respaldado.

9) Síntoma: Todo parece correcto, pero la entrada Windows Boot Manager apunta al disco equivocado

Causa raíz: Sistema con múltiples discos; los archivos de arranque de Windows se crearon en el disco A pero la entrada del firmware apunta al ESP del disco B (o viceversa).

Solución: Identifica la ESP que usa realmente el firmware; recrea archivos de arranque allí con bcdboot. Opcionalmente elimina entradas obsoletas y estandariza.

Tres microhistorias corporativas desde las trincheras del arranque

Incidente #1: La suposición equivocada (el cuento de “solo existe una ESP”)

Una empresa mediana tenía estaciones de trabajo dual-boot: Windows para herramientas corporativas y Linux para pipelines de compilación. Llegó un nuevo lote de hardware con dos discos por máquina: un NVMe pequeño y un SSD SATA más grande. El proceso de imagen instaló Windows en el NVMe. Linux se instaló en el SATA.

El equipo asumió que la ESP estaba en el disco de Windows. Razonable. También estaba equivocado. El instalador de Linux, con prisas, encontró una ESP existente en el SATA (resto de una imagen de prueba del proveedor) y la usó. Así la máquina quedó con dos ESP, y cuál prefería el firmware dependía del orden de enumeración sutil.

El incidente apareció como “Windows a veces desaparece”. Tras actualizaciones o ciclos de energía, la mitad de la flota arrancaba en GRUB sin opción a Windows; la otra mitad arrancaba Windows correctamente. Todos culparon a las actualizaciones de Windows porque eso hacemos cuando nos sentimos impotentes.

La solución fue aburrida: inventariar discos, identificar la ESP autoritativa por máquina, reconstruir los archivos de arranque de Windows en esa ESP con bcdboot y estandarizar el orden de arranque del firmware. También eliminaron la ESP huérfana tras confirmar que nadie dependía de ella. La causa real no fue un bug de Windows; fue una suposición que echó raíces.

Incidente #2: La optimización que salió mal (reducir la ESP para “ahorrar espacio”)

Otra organización tenía la costumbre de “apretujar” particiones para maximizar el espacio utilizable. Alguien vio una ESP de 500MB y la redujo a 100MB, porque “solo contiene archivos de arranque”.

Funcionó. Por un tiempo. Luego una actualización rutinaria de Linux añadió nuevos kernels y artefactos EFI. Las actualizaciones de Windows también refrescaron componentes de arranque. La ESP se llenó en silencio, porque la monitorización no incluía “espacio libre en la ESP”, por la misma razón por la que nadie vigila el espacio libre en el armario de la cocina.

Eventualmente, las actualizaciones comenzaron a fallar. Luego las reparaciones de arranque empezaron a fallar. Finalmente, un subconjunto de máquinas dejó de arrancar porque el sistema de archivos de la ESP quedó inconsistente tras escrituras parciales repetidas. La recuperación no fue difícil, pero sí disruptiva: expandir la ESP (no siempre fácil), o crear una nueva ESP y migrar entradas, luego limpiar cuidadosamente.

La lección fue simple: trata la ESP como un volumen de configuración compartido con margen. Ahorrar unos cientos de megabytes en un disco de cientos de gigabytes es una optimización que demuestra que puedes medir cosas, no que puedes operarlas.

Incidente #3: La práctica aburrida que salvó el día (una pequeña copia de la ESP)

Una empresa financiera tenía arranque dual en algunos portátiles especializados para pruebas de hardware. Su equipo SRE no lo quería, pero lo aceptó con reglas. Una de esas reglas era un procedimiento trimestral de “snapshot de la ESP”: arrancar en Linux, montar la ESP en modo lectura si es posible, y empaquetar el directorio EFI en un almacenamiento interno cifrado.

Un día, una actualización de firmware restableció entradas NVRAM y la máquina predeterminó una ruta no funcional. El operador no pudo arrancar Windows, y Linux arrancaba de forma inconsistente. Nadie entró en pánico. Arrancaron un USB live de Linux, montaron la ESP, la compararon con el último archivo conocido y restauraron directorios faltantes. Luego recrearon las entradas de arranque.

Lo que pudo haber sido un incidente de “portátil fuera de servicio” se convirtió en una reparación controlada de 40 minutos. Sin pérdida de datos, sin drama, sin heroísmos nocturnos. La práctica no era ingeniosa; era consistente.

Listas de verificación / plan paso a paso

Lista 1: Antes de tocar nada (cinturones de seguridad)

1. Confirma si Windows es UEFI o BIOS. Usa diskpart (estrella Gpt) y la presencia de una ESP.
2. Registra el diseño actual de discos/particiones. Capturas de pantalla o notas de list disk, list vol.
3. Si BitLocker está activado, asegúrate de tener la clave de recuperación. Si no la tienes, pausa.
4. En sistemas multi-disco, identifica qué disco prefiere arrancar primero el firmware. “Disk 0” en Windows no siempre es el disco preferido por el firmware.

Lista 2: Reparación mínima para sistemas UEFI (recomendado por defecto)

1. Arranca en WinRE Command Prompt.
2. Ejecuta diskpart → list vol, encuentra el volumen FAT32 “System” (ESP).
3. Asigna a la ESP una letra (por ejemplo, Z:).
4. Confirma la letra de la partición de Windows (C: u otra) comprobando \Windows.
5. Ejecuta bcdboot <WinLetter>:\Windows /s Z: /f UEFI.
6. Reinicia y selecciona Windows Boot Manager en el menú del firmware.
7. Si hace falta, reordena las entradas en el firmware o mediante efibootmgr desde Linux.

Lista 3: Reparación mínima para sistemas BIOS/MBR

1. Arranca en WinRE Command Prompt.
2. diskpart → confirma que el disco del sistema no tiene estrella Gpt.
3. Encuentra la partición System Reserved; asigna una letra (S:).
4. Marca la partición System Reserved como activa.
5. Ejecuta bootrec /fixmbr y bootrec /fixboot.
6. Ejecuta bootrec /rebuildbcd o bcdboot C:\Windows /s S: /f BIOS.
7. Reinicia y valida.

Lista 4: Si debes preservar también Linux

1. Después de que Windows arranque, decide el propietario del arranque por defecto (Windows Boot Manager vs GRUB).
2. Si GRUB fue sobrescrito o perdido, repara GRUB desde Linux (específico de la distribución) para restaurar el menú dual-boot.
3. Mantén una copia de los contenidos de la ESP tras estabilizar el sistema.
4. Documenta la ESP elegida y el orden de arranque para que el tú del futuro no vuelva a aprender esta lección.

Preguntas frecuentes (FAQ)

1) ¿Es seguro ejecutar bcdboot? ¿Eliminará Linux?

En sistemas UEFI, bcdboot escribe archivos de arranque de Windows en la ESP y actualiza la configuración de arranque de Windows. No elimina Linux por sí mismo, pero si tu ESP es pequeña y está llena, o si luego “limpias” directorios, puedes romper Linux. Úsalo, pero verifica el espacio libre de la ESP y no borres directorios de otros proveedores.

2) ¿Debería desactivar Secure Boot para arreglar el arranque dual?

No como primera medida. Secure Boot puede evidenciar rutas de arranque no firmadas/incorrectas, pero desactivarlo suele enmascarar el problema real y crear una nueva clase de problemas más adelante. Arregla la cadena de arranque correctamente; mantén Secure Boot activado a menos que tengas un requisito específico.

3) ¿Por qué Windows sigue recuperando el orden de arranque?

Las actualizaciones de Windows y algunas actualizaciones de firmware pueden restablecer el orden NVRAM para preferir Windows Boot Manager. No es algo personal; es la prioridad que definen los vendedores para soporte. Si quieres Linux primero, planea reasegurar GRUB como predeterminado ocasionalmente, o usa el menú de firmware para Linux.

4) Mi ESP falta. ¿Puedo crear una nueva?

Sí, pero no es la solución más rápida. Crear una nueva ESP implica cambios en particionado, formatear FAT32, establecer el tipo/flags GPT correctos, luego usar bcdboot para llenarla y efibootmgr/firmware para registrarla. Hazlo solo cuando la ESP original sea irreparable.

5) ¿Qué pasa si bootrec /scanos no encuentra instalaciones de Windows?

Eso es un problema de visibilidad, no de “cargador”. Causas comunes: volumen BitLocker bloqueado, drivers de almacenamiento faltantes (RAID/VMD) o NTFS corrupto. Desbloquea el volumen, carga drivers si es necesario y confirma que la partición de Windows es legible antes de reconstruir BCD.

6) ¿Puedo reparar el cargador de Windows solo desde Linux?

A veces puedes restaurar archivos EFI faltantes si tienes una copia conocida buena, y puedes recrear entradas NVRAM con efibootmgr. Pero el método más fiable para generar archivos de arranque/BCD correctos sigue siendo bcdboot desde WinRE.

7) ¿Reparar el cargador de arranque implica riesgo de pérdida de datos?

La mayoría de las reparaciones son metadatos y escrituras pequeñas en la ESP o la partición del sistema. El riesgo real de pérdida de datos viene de errores de particionado (formatear la partición equivocada, redimensionar el disco equivocado, “limpiar” particiones). Mantente en comandos mínimos primero y verifica cada objetivo.

8) Veo múltiples entradas “Windows Boot Manager” en el firmware. ¿Cuál es la real?

Bienvenido a la vida multi-disco. Cada entrada apunta a un disco/partición/ruta de archivo específica. Usa efibootmgr -v en Linux para ver cuál apunta a la ESP que realmente contiene \EFI\Microsoft\Boot\bootmgfw.efi. Elimina entradas obsoletas solo después de confirmar un arranque estable.

9) ¿Debería reinstalar Windows en su lugar?

Solo si el volumen del OS está corrupto más allá de la reparación o ya planeabas una reinstalación. Los problemas de cargador suelen repararse en menos de una hora. Reinstalar es una operación de mayor riesgo y tiempo que la gente elige porque se siente definitiva.

Próximos pasos (los prácticos)

Esto es lo que haría, en orden, si quiero la mayor probabilidad de una recuperación limpia:

1. Decidir si estás en UEFI o BIOS usando diskpart y la presencia de una ESP.
2. En UEFI: monta la ESP, ejecuta bcdboot, confirma que los archivos existen y luego arregla el orden de arranque.
3. En BIOS/MBR: marca la partición activa correcta, repara MBR/sector de arranque y reconstruye BCD.
4. Reinicia una vez y valida. Si falla, recopila el error exacto y reevalúa qué capa sigue rota.
5. Después de que arranque: estabiliza el arranque dual: elige el propietario por defecto, documenta la ubicación de la ESP y mantén una pequeña copia de seguridad de los contenidos de la ESP.

Si no te llevas nada más: deja de probar comandos al azar. Los fallos de arranque premian la calma, los mapas y un cambio deliberado a la vez.