Arranque dual Windows + Linux: la configuración que no rompe las actualizaciones

Los principios: qué se rompe realmente y por qué

Los fallos de arranque dual normalmente no son “problemas de Linux” ni “problemas de Windows”. Son problemas de la cadena de arranque.
Dos sistemas operativos comparten unas pocas piezas de estado del firmware y metadatos del disco. Si no controlas deliberadamente esas piezas,
los instaladores y las actualizaciones “útiles” lo harán por ti.

La cadena de arranque, en términos sencillos

En PCs modernos deberías usar UEFI + GPT. El firmware carga una entrada de arranque (un registro NVRAM que apunta a un ejecutable EFI).
Ese ejecutable suele ser Windows Boot Manager o un gestor de arranque de Linux (GRUB o systemd-boot).
Desde ahí seleccionas un SO, cargas un kernel y solo entonces estás en la comodidad de tu sistema init conocido.

Lo que suele romperse durante las actualizaciones es normalmente una de las siguientes cosas:

• Cambios en el orden de arranque NVRAM de UEFI (a Windows le gusta promover su propia entrada).
• Cambios en el contenido de la partición del sistema EFI (ESP) (archivos añadidos/eliminados, a veces sobrescritos).
• Desajuste de la política de Secure Boot (claves, shims, firmas).
• Cambios en la identidad del disco (clonados, mover discos, actualizaciones de firmware que reordenan las unidades).
• Contención de acceso al sistema de archivos (Fast Startup de Windows e hibernación dejando NTFS “sucio”).

El diseño robusto no es “instala Linux junto a Windows y reza”. Es:
responsabilidades separadas, minimizar el estado compartido y poder reconstruir el arranque de forma determinista.

Si solo recuerdas una cosa: tu ESP no es un cajón de trastos. Trátalo como configuración de producción.
Hazle copia de seguridad. Mantenlo pequeño y aburrido. Sabe lo que hay dentro.

Broma #1: Una máquina con arranque dual es como tener dos jefes: todo va bien hasta que ambos “poseen” la agenda.

Hechos interesantes y un poco de historia

Algunos puntos de contexto que hacen que las recomendaciones de hoy sean menos arbitrarias:

1. UEFI sustituyó al BIOS legacy para modernizar el arranque, permitir Secure Boot y eliminar limitaciones antiguas como la tabla de particiones MBR.
2. MBR históricamente limitaba discos a ~2 TB y cuatro particiones primarias. GPT solucionó eso en gran medida, por eso los esquemas de arranque dual se volvieron más sensatos con el tiempo.
3. La ESP está estandarizada: suele ser FAT32 y está destinada a contener ejecutables EFI para varios SO —la coexistencia es el diseño, no un truco.
4. Windows Boot Manager se convirtió en el centro de gravedad en muchas configuraciones OEM; los fabricantes a menudo fijan preferencias de arranque hacia él.
5. Secure Boot empezó como una característica de seguridad pero se volvió una variable operativa: genial cuando es consistente, doloroso cuando se mezcla entre distros y kernels personalizados.
6. GRUB se popularizó en parte por su flexibilidad sobre muchos sistemas de archivos y detección multi-SO; systemd-boot ganó terreno por ser nativo UEFI y más sencillo.
7. BitLocker cambió las reglas: no es solo cifrado; también es un “sistema de detección de cambios” que reacciona a modificaciones en la ruta de arranque.
8. Fast Startup es básicamente hibernación ligera: deja NTFS en un estado que Linux no debería montar en lectura/escritura, por eso las particiones compartidas se corrompen misteriosamente.

Una cita que vale la pena tener en la cabeza durante cualquier trabajo con gestores de arranque: Idea parafraseada: “La esperanza no es una estrategia.” — General H. Norman Schwarzkopf, citada a menudo en círculos de operaciones.

Elige tu arquitectura: un disco, dos discos, una ESP, dos ESP

La opción más sólida: unidades físicas separadas

Si puedes, instala Windows en un SSD y Linux en otro SSD. Esto te da control del radio de impacto:
las actualizaciones de Windows solo pueden estropear lo que pueden ver y lo que arranque tu firmware primero.

En esta configuración prefiero dos ESP (una por unidad) cuando el firmware se comporta y quieres aislamiento máximo.
Si tu firmware es quisquilloso, puedes usar una sola ESP en la unidad de Windows y aun así mantener la raíz de Linux totalmente separada.

Por qué sobrevive a las actualizaciones: cada SO puede mantener sus propios archivos de arranque. Las entradas NVRAM pueden reordenarse, pero los archivos subyacentes permanecen intactos.

La opción más común: un disco, ESP compartida

Un disco está bien si eres disciplinado. Tendrás una ESP (FAT32) y luego particiones separadas para Windows y Linux.
El modo de fallo aquí no es “Linux sobrescribió Windows.” Es “la actualización de Windows se puso arriba y olvidaste cómo elegir la otra entrada.”

La ESP compartida no es inherentemente frágil; es frágil cuando no se gestiona. Hazle copia de seguridad y evita experimentos aleatorios con gestores de arranque.

GRUB vs systemd-boot: elige según tu presupuesto de complejidad

• GRUB: ideal cuando quieres un único menú que lo gobierne todo, soporte para muchos kernels, encadenar Windows y manejar sistemas de archivos raros. Más piezas en movimiento.
• systemd-boot: más simple, nativo UEFI. Lee entradas desde la ESP y arranca stubs EFI. Menos “scripts mágicos”, menos sorpresas.

Mi opinión: si usas una distro corriente en un portátil moderno con UEFI, systemd-boot es una vida más tranquila.
Si necesitas detección multiboot avanzada y cadenas personalizadas, GRUB sigue siendo la navaja suiza.

Comprobaciones previas antes de tocar particiones

Antes de volver a particionar nada, necesitas saber qué tienes realmente. No lo que crees que tienes.
La mitad de los “misterios” del arranque dual son alguien instalando en modo legacy en una máquina UEFI, o mezclando MBR y GPT como si fuera 2009.

Decide esto por adelantado

• Solo arranque UEFI (sin CSM/legacy)
• Particionado GPT
• BitLocker: activado o no, y si está activado, cómo gestionarás las claves de recuperación
• Secure Boot: activado (preferible) si tu distro lo soporta limpiamente; desactivado si usas kernels personalizados y no quieres gestionar claves
• Datos compartidos: sí o no (y si sí, usa una partición de datos dedicada con reglas claras)

Las configuraciones de arranque dual más fiables evitan la genialidad. “Ingenioso” es lo que haces justo antes de aprender por qué existe lo aburrido.

Planes de particionado que sobreviven a las actualizaciones

Esquema básico UEFI/GPT (disco único)

Un esquema aburrido y resistente a actualizaciones:

• ESP: 512 MiB a 1 GiB, FAT32, montada en /boot/efi en Linux
• MSR: Microsoft Reserved (Windows la crea)
• Windows: NTFS para C:
• Raíz de Linux: ext4 o btrfs
• Swap de Linux: opcional si usas swapfile; requerido si quieres hibernación fiable
• Datos compartidos (opcional): exFAT o NTFS, pero sigue las reglas abajo

Reglas para la partición de datos compartida (para no corromperla)

Si compartes una partición NTFS entre Windows y Linux:

• Desactiva Windows Fast Startup, o Linux verá el volumen como hibernado/sucio y montarlo en RW será un arma de fuego.
• Nunca montes volúmenes del sistema Windows hibernados en RW desde Linux. Usa una partición de datos separada si necesitas acceso RW.
• Prefiere exFAT para “almacenamiento simple” (fotos, instaladores) si no necesitas ACLs de NTFS. Es más simple entre sistemas.

Esquema de dos discos (recomendado si puedes)

Si tienes dos SSD:

• Disco 0 (Windows): ESP + MSR + Windows
• Disco 1 (Linux): ESP opcional (si quieres aislamiento) + raíz de Linux + swap opcional + /home opcional

La parte de “no rompe las actualizaciones” viene del aislamiento y de la capacidad de ajustar la prioridad de arranque del firmware a la unidad que prefieras.
En el peor de los casos, eliges la otra unidad desde el menú de arranque de una sola vez y sigues trabajando.

Orden de instalación y estrategia del gestor de arranque (lo que recomiendo)

Instala Windows primero, luego Linux

Los instaladores de Windows asumen que son el único SO en el mundo. Los instaladores de Linux suelen comportarse mejor con la coexistencia.
Así que instala Windows primero, actualízalo, luego reduce su partición e instala Linux.

Elige el gestor de arranque “principal” con intención

Tienes dos modelos sensatos:

• El gestor de Linux es principal: GRUB/systemd-boot ofrece un menú y encadena Windows.
• Windows Boot Manager es principal: Windows arranca normalmente y seleccionas Linux desde el menú del firmware o añadiendo una entrada de arranque de Windows.

Para la mayoría de la gente que usa Linux a diario, el primer modelo es mejor. Para dispositivos corporativos con políticas agresivas de Windows, el segundo modelo genera menos argumentos de cumplimiento.

Secure Boot y BitLocker: decide, no divagues

Secure Boot puede coexistir con Linux si tu distro usa shim + bootloaders firmados. BitLocker también puede coexistir, pero es sensible a cambios en la ruta de arranque.
Si habilitas BitLocker y luego empiezas a cambiar entradas EFI y gestores de arranque, espera solicitudes de recuperación.

La regla operativa: termina la configuración del gestor de arranque primero y luego habilita BitLocker (o suspéndelo mientras haces cambios).

Tareas prácticas: comandos, salidas y decisiones

Estas son tareas reales que harás durante la configuración y la recuperación. Cada una incluye: comando, salida típica, qué significa y qué decisión tomar.
Los comandos se muestran como si se ejecutaran desde Linux (USB live o sistema instalado) a menos que se indique lo contrario.

Task 1: Confirmar que arrancaste el instalador en modo UEFI

cr0x@server:~$ ls /sys/firmware/efi
config_table  efivars  esrt  fw_platform_size  fw_vendor  runtime  runtime-map  systab  vars

Qué significa: Si /sys/firmware/efi existe, estás arrancado en modo UEFI. Si no existe, estás en modo legacy/CSM.
Decisión: Si no es UEFI, detente y reinicia el USB en modo UEFI. Mezclar modos es como obtener “funciona hasta el reinicio”.

Task 2: Confirmar que el disco es GPT (no MBR)

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

Number  Start   End     Size    File system  Name                          Flags
 1      1049kB  538MB   537MB   fat32        EFI system partition          boot, esp
 2      538MB   672MB   134MB                Microsoft reserved partition  msftres
 3      672MB   300GB   299GB   ntfs         Basic data partition          msftdata
 4      300GB   1000GB  700GB

Qué significa: “Partition Table: gpt” es lo que quieres.
Decisión: Si es msdos/MBR y quieres un arranque dual UEFI moderno, planifica una conversión (o reinstalación). No pegotes una nueva Linux sobre boot legacy si puedes evitarlo.

Task 3: Identificar la partición del sistema EFI (ESP)

cr0x@server:~$ lsblk -o NAME,SIZE,FSTYPE,PARTTYPE,PARTFLAGS,MOUNTPOINTS
NAME        SIZE FSTYPE PARTTYPE                             PARTFLAGS MOUNTPOINTS
nvme0n1   931.5G
├─nvme0n1p1 512M vfat   c12a7328-f81f-11d2-ba4b-00a0c93ec93b boot,esp  /boot/efi
├─nvme0n1p2 128M        e3c9e316-0b5c-4db8-817d-f92df00215ae
├─nvme0n1p3 299G ntfs   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
└─nvme0n1p4 632G ext4   0fc63daf-8483-4772-8e79-3d69d8477de4 /

Qué significa: La ESP aparece como vfat con el tipo de partición GUID de EFI.
Decisión: Si no tienes una ESP, no puedes hacer un arranque UEFI limpio. Crea una (y prepárate para reparar entradas de arranque).

Task 4: Inspeccionar qué hay en la ESP (quién instaló qué)

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

Qué significa: Puedes ver artefactos de arranque de Windows y Linux conviviendo lado a lado.
Decisión: Si los archivos de Linux faltan tras una actualización, puedes restaurarlos desde la copia de seguridad o reinstalar el gestor de arranque. Si faltan los archivos de Microsoft, la recuperación de Windows los restaurará.

Task 5: Comprobar entradas de arranque UEFI y orden de arranque

cr0x@server:~$ sudo efibootmgr -v
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0000,0003,0001
Boot0000* Windows Boot Manager  HD(1,GPT,2c2d...,0x800,0x100000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)
Boot0001* UEFI: USB Disk  1.00
Boot0003* ubuntu  HD(1,GPT,2c2d...,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)

Qué significa: BootOrder decide qué ocurre sin intervención del usuario. Las actualizaciones de Windows a menudo mueven Boot0000 a la cima.
Decisión: Si Linux no está primero y quieres que lo esté, cambia BootOrder. Si Windows debe permanecer primero (corporativo), acéptalo y confía en la tecla de arranque de una sola vez.

Task 6: Poner la entrada de Linux primero (cuando quieras que GRUB/systemd-boot sea primario)

cr0x@server:~$ sudo efibootmgr -o 0003,0000,0001
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0000,0001

Qué significa: Has cambiado la ruta de arranque por defecto.
Decisión: Si BitLocker está activado, considera suspenderlo antes de hacer esto (ver tareas posteriores) o ten a mano las claves de recuperación.

Task 7: Detectar si Windows está hibernado / Fast Startup “sucio” en NTFS

cr0x@server:~$ sudo ntfsfix -n /dev/nvme0n1p3
Mounting volume... FAILED
Attempting to correct errors... FAILED
NTFS signature is missing.
FAILED

Qué significa: En la partición equivocada verás “NTFS signature missing.” Eso es una falla útil: apuntaste al dispositivo equivocado.
Decisión: Revisa el mapeo de particiones; no “arregles” particiones aleatorias.

cr0x@server:~$ sudo ntfsfix -n /dev/nvme0n1p3
Mounting volume... OK
Processing of $MFT and $MFTMirr completed successfully.
Checking the alternate boot sector... OK
NTFS volume version is 3.1.
NTFS partition /dev/nvme0n1p3 was processed successfully.

Qué significa: Los metadatos básicos parecen sanos. Esto no prueba que Windows se apagó limpiamente, pero reduce la sospecha.
Decisión: Si Linux aún se niega a montar RW por hibernación, arranca Windows, haz un apagado completo y desactiva Fast Startup.

Task 8: Confirmar particiones y banderas de Windows antes de redimensionar

cr0x@server:~$ sudo fdisk -l /dev/nvme0n1
Disk /dev/nvme0n1: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Disklabel type: gpt

Device           Start        End    Sectors   Size Type
/dev/nvme0n1p1     2048    1050623    1048576   512M EFI System
/dev/nvme0n1p2  1050624    1312767     262144   128M Microsoft reserved
/dev/nvme0n1p3  1312768  626000000  624687233 298.0G Microsoft basic data
/dev/nvme0n1p4 626000001 1953523711 1327523711 633.5G Linux filesystem

Qué significa: Puedes ver límites exactos. Esto es lo que consultarás cuando escribas comandos de recuperación más tarde.
Decisión: Si Windows está en p3 y Linux en p4, déjalos así. Evita entrelazar particiones que compliquen redimensionados futuros.

Task 9: Verificar el estado de Secure Boot desde Linux

cr0x@server:~$ mokutil --sb-state
SecureBoot enabled

Qué significa: Secure Boot está activado. Tu cadena de arranque de Linux debe estar firmada apropiadamente.
Decisión: Si planeas ejecutar kernels/módulos no firmados, o bien inscribe tus propias claves (avanzado) o desactiva Secure Boot. No lo hagas a medias.

Task 10: Hacer copia de seguridad de la ESP (este es tu botón “no entres en pánico”)

cr0x@server:~$ sudo mkdir -p /root/esp-backup
cr0x@server:~$ sudo tar -C /boot/efi -czf /root/esp-backup/esp-efi.tgz EFI
cr0x@server:~$ sudo ls -lh /root/esp-backup/esp-efi.tgz
-rw-r--r-- 1 root root 38M Feb  5 10:12 /root/esp-backup/esp-efi.tgz

Qué significa: Tienes una instantánea en el tiempo del contenido de la ESP.
Decisión: Copia este archivo fuera del equipo (USB, otro host). Si tu disco muere, las copias locales son posters motivacionales.

Task 11: Si falta GRUB, reinstálalo (modo UEFI)

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

Qué significa: Los binarios EFI de GRUB se escribieron en la ESP y es probable que se haya creado/actualizado una entrada de arranque.
Decisión: Sigue con la reconstrucción de la configuración. Si tu distro prefiere shim, asegúrate de que shim esté instalado también.

Task 12: Regenerar entradas del menú GRUB (detectar Windows)

cr0x@server:~$ sudo update-grub
Sourcing file `/etc/default/grub'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.0-41-generic
Found initrd image: /boot/initrd.img-6.8.0-41-generic
Found Windows Boot Manager on /dev/nvme0n1p1@/EFI/Microsoft/Boot/bootmgfw.efi
Adding boot menu entry for UEFI Firmware Settings ...
done

Qué significa: GRUB detectó Windows Boot Manager y lo añadió.
Decisión: Si Windows no se encuentra, suele ser porque la ESP no está montada o os-prober está deshabilitado. Arregla eso en lugar de editar scripts de GRUB al azar.

Task 13: Para usuarios de systemd-boot, listar e instalar entradas de arranque

cr0x@server:~$ bootctl status
System:
     Firmware: UEFI 2.70
  Secure Boot: enabled
   Setup Mode: no
 Boot into FW: supported

Current Boot Loader:
      Product: systemd-boot 255.4
     Features: ✓ Boot counting
               ✓ Menu timeout control
               ✓ One-shot menu timeout control
               ✓ Default entry control

Available Boot Loaders on ESP:
          ESP: /boot/efi (vfat)
         File: └─/EFI/systemd/systemd-bootx64.efi

Boot Loaders Listed in EFI Variables:
        Title: Linux Boot Manager
           ID: 0x0005
       Status: active, boot-order

Qué significa: systemd-boot está presente y registrado.
Decisión: Si no aparece en las variables EFI, puede que necesites bootctl install o una entrada con efibootmgr según la distro.

Task 14: Montar la ESP correctamente desde un live USB durante la rescate

cr0x@server:~$ sudo mount /dev/nvme0n1p4 /mnt
cr0x@server:~$ sudo mount /dev/nvme0n1p1 /mnt/boot/efi
cr0x@server:~$ mount | grep -E '/mnt|efi'
/dev/nvme0n1p4 on /mnt type ext4 (rw,relatime)
/dev/nvme0n1p1 on /mnt/boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)

Qué significa: Has montado la raíz de Linux y la ESP en el entorno de rescate. Ahora los comandos de reinstalación de gestores de arranque apuntarán al sitio correcto.
Decisión: Si montas la ESP equivocada (común con múltiples discos), “arreglarás” nada mientras te sientes productivo. Verifica los IDs de los dispositivos.

Task 15: Comprobar desde qué disco arranca realmente el firmware

cr0x@server:~$ sudo efibootmgr | sed -n '1,6p'
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0003
Boot0000* Windows Boot Manager
Boot0003* ubuntu

Qué significa: Actualmente has arrancado mediante Windows Boot Manager (BootCurrent 0000).
Decisión: Si esperas el gestor de Linux, cambia BootOrder o usa el menú de arranque de una sola vez para seleccionarlo y luego vuelve a comprobar.

Task 16: Hacer una instantánea de cómo queda la ESP tras actualizaciones de Windows

cr0x@server:~$ sudo sh -c 'cd /boot/efi && find EFI -maxdepth 3 -type f -printf "%p %s\n" | sort | tail -n 8'
EFI/Microsoft/Boot/bootmgfw.efi 1705984
EFI/Microsoft/Boot/bootmgr.efi 1050632
EFI/Microsoft/Boot/memtest.efi 1105920
EFI/ubuntu/grubx64.efi 2867200
EFI/ubuntu/shimx64.efi 1204224
EFI/ubuntu/mmx64.efi 845824
EFI/Boot/bootx64.efi 1204224
EFI/Boot/fbx64.efi 2252800

Qué significa: Tienes una vista rápida de “qué cambió”. Adiciones inesperadas como EFI/Boot/bootx64.efi pueden ser normales (cargadores de fallback), pero las eliminaciones repentinas no lo son.
Decisión: Si los archivos de Linux desaparecieron, restaura desde la copia de seguridad de la ESP o reinstala el gestor de arranque. Si la ESP se está llenando, amplíala ahora —no durante una caída del sistema.

Task 17: Diagnosticar desajustes de UUID de disco en fstab de Linux

cr0x@server:~$ sudo blkid /dev/nvme0n1p1 /dev/nvme0n1p4
/dev/nvme0n1p1: UUID="3A1B-2C3D" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="2c2d..."
/dev/nvme0n1p4: UUID="2b5c0b2b-0b5a-4d7f-9f41-6f2c9a2a1c77" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="9a12..."

Qué significa: Tienes identificadores de referencia.
Decisión: Si tu /etc/fstab hace referencia a un UUID que ya no existe (común después de clonar), arréglalo antes de reiniciar y quedar en initramfs.

Task 18: Validar que Windows Boot Manager existe en la ESP

cr0x@server:~$ sudo test -f /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi && echo OK || echo MISSING
OK

Qué significa: El archivo de arranque de Windows existe.
Decisión: Si falta, el medio de reparación de Windows es tu amigo. No “tomes prestados” binarios EFI aleatorios de internet; así es como consigues malware con excelente tiempo de actividad.

Broma #2: La ESP es FAT32, lo cual es apropiado, porque es donde tus problemas de arranque engordan.

Guía rápida de diagnóstico

Cuando un sistema de arranque dual no arranca, no empieces a reinstalar sistemas operativos como si te pagaran por la descarga.
Quieres acotar el cuello de botella rápido: selección del firmware, entrada de arranque, contenido de la ESP, kernel/initramfs o sistema de archivos.

Primero: firmware y modo de arranque

• Comprueba el modo de arranque: ¿Estás en UEFI? Si arrancaste por accidente una entrada legacy, lo demás es ruido.
• Usa el menú de arranque de una sola vez: Selecciona explícitamente “Windows Boot Manager” vs “ubuntu” vs “Linux Boot Manager” y observa el comportamiento.
• Si Secure Boot está activado: Nota si la falla es por verificación de firma (mensaje del firmware) frente a una falla de GRUB/kernel.

Segundo: salud y contenido de la ESP

• Desde un USB Linux live, monta la ESP y lista /EFI/Microsoft y tu directorio de Linux (/EFI/ubuntu, /EFI/fedora, etc.).
• Si la ESP falta o está corrompida, verás fallos de montaje o directorios vacíos. Eso no es un problema de “configuración de GRUB”. Es almacenamiento.
• Comprueba el espacio libre en la ESP: si está casi llena, las actualizaciones pueden fallar de formas extrañas.

Tercero: entradas de arranque NVRAM de UEFI

• efibootmgr -v te dice lo que el firmware cree que existe.
• Si la entrada de Linux apunta a un archivo que ya no existe, recréala reinstalando el gestor de arranque o usando efibootmgr.
• Si la entrada existe pero nunca se usa, arregla BootOrder o la configuración del firmware.

Cuarto: kernel de Linux y sistema raíz

• Si GRUB aparece pero Linux no arranca, comprueba si cambió el UUID de la raíz o si initramfs no encuentra el dispositivo raíz.
• Si cae a un shell initramfs, suele ser cambio de nombres/UUIDs del almacenamiento o falta de controladores (raro en portátiles; común en configuraciones RAID/HBA).

Quinto: fallo específico de Windows

• Si Windows falla pero Linux arranca, no “arregles Windows” desde Linux más allá de verificar que el archivo EFI de Windows existe.
• Si BitLocker solicita recuperación tras cambios de arranque, eso es un comportamiento esperado; recupera la clave y luego estabiliza la cadena de arranque.

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

1) “Tras la actualización de Windows, arranca directo a Windows”

Síntoma: El menú de GRUB/systemd-boot ha desaparecido; Windows se carga inmediatamente.
Causa raíz: Windows movió “Windows Boot Manager” a la cima de BootOrder o restableció los valores por defecto del firmware.
Solución: Desde Linux (o un USB live), ejecuta efibootmgr -v y vuelve a poner BootOrder como estaba. Si no puedes arrancar Linux, usa el menú de arranque de una sola vez del firmware para lanzar la entrada de Linux y luego arregla BootOrder de forma persistente.

2) “Linux arranca, pero falta la entrada de Windows en GRUB”

Síntoma: El menú de GRUB solo muestra kernels de Linux, sin opción de Windows.
Causa raíz: La ESP no estaba montada en /boot/efi durante update-grub, o os-prober está deshabilitado por defecto en la distro.
Solución: Monta la ESP, habilita os-prober si hace falta, vuelve a ejecutar update-grub. Valida que /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi exista.

3) “La partición de Windows es de solo lectura o no se monta en Linux”

Síntoma: Linux se niega a montar RW; los registros mencionan “hibernated” o “unsafe state”.
Causa raíz: Windows Fast Startup o hibernación dejó NTFS sucio.
Solución: Arranca Windows, desactiva Fast Startup, haz un apagado completo. No montes forzosamente en RW a menos que te guste la pérdida de datos como pasatiempo.

4) “Solicitud de clave de recuperación de BitLocker tras instalar Linux”

Síntoma: Windows pide la clave de recuperación en cada arranque tras cambios del arranque dual.
Causa raíz: La cadena de arranque cambió (entrada EFI, gestor de arranque, estado de Secure Boot). BitLocker lo interpreta como manipulación.
Solución: Arranca con la clave de recuperación una vez y luego estabiliza: mantén el estado de Secure Boot consistente, evita cambios frecuentes en el gestor de arranque y vuelve a sellar BitLocker suspendiéndolo y reanudándolo tras la configuración final.

5) “GRUB aparece, pero Linux cae a initramfs con ‘cannot find UUID’”

Síntoma: El kernel arranca y luego se detiene, pidiendo el dispositivo raíz manualmente.
Causa raíz: Cambió el UUID de la partición raíz (clonado, restaurado) o /etc/fstab referencia un UUID incorrecto; a veces la línea de comandos de GRUB apunta al root equivocado.
Solución: Usa blkid para encontrar los UUID correctos; actualiza /etc/fstab, regenera initramfs y verifica la configuración del gestor de arranque.

6) “Secure Boot activado: Linux no arranca tras una actualización del kernel”

Síntoma: El firmware o shim reporta problemas de verificación/firmas.
Causa raíz: Kernel/módulo no firmado, shim/MOK mal configurado, o mezclar compilaciones personalizadas con Secure Boot sin gestionar claves.
Solución: Usa kernels firmados por la distro, o inscribe tu Machine Owner Key y firma tus kernels/módulos, o desactiva Secure Boot (pero hazlo intencionalmente).

7) “La ESP se quedó sin espacio y ahora las actualizaciones fallan”

Síntoma: Las actualizaciones de kernel fallan, entradas de arranque inconsistentes o errores de montaje de la ESP con uso cercano al 100%.
Causa raíz: ESP demasiado pequeña (antiguo valor OEM de 100–200 MiB) más múltiples gestores de arranque/kernels/shims.
Solución: Aumenta el tamaño de la ESP (con cuidado) o limpia artefactos antiguos. La solución correcta suele ser redimensionar a al menos 512 MiB.

Tres micro-historias del mundo corporativo

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

Una empresa mediana desplegó portátiles de desarrollador con Windows para herramientas corporativas y Linux para pipelines de compilación. Lo habitual.
El documento de despliegue decía: “Instala Linux. GRUB mostrará Windows automáticamente.” Esa línea se estropeó con el tiempo.

En un lote de portátiles más nuevos, el instalador de Linux se arrancó en modo legacy (porque la memoria USB tenía dos opciones de arranque y la gente escogió la primera).
Linux se instaló bien. GRUB se instaló bien. La máquina incluso arrancó—hasta que una actualización de firmware llegó vía Windows Update y silenciosamente deshabilitó CSM.

A la mañana siguiente: pantalla negra y “No bootable device.” Windows seguía en disco. Linux seguía en disco.
Pero los gestores de arranque se habían instalado para arranque legacy, mientras que el firmware ahora exigía UEFI.

La solución no fue mágica. Reconstruyeron la cadena de arranque: crearon/validaron la ESP, reinstalaron el gestor de Linux en modo UEFI y aseguraron que Windows tuviera una entrada UEFI adecuada.
La solución real fue cultural: su checklist añadió “verificar modo UEFI” como puerta obligatoria antes de instalar, usando la comprobación exacta de /sys/firmware/efi.

Micro-historia 2: La optimización que salió mal

Otra organización intentó “optimizar” el uso de disco en SSDs de portátil finos. Reducieron la ESP al mínimo que habían visto en layouts OEM.
También consolidaron gestores de arranque eliminando archivos EFI “duplicados” siempre que los notaban.

Parecía ordenado. Por un tiempo. Luego una actualización de kernel de Linux necesitó refrescar archivos relacionados con shim, y una actualización de características de Windows refrescó sus componentes de arranque.
FAT32 no es sutil. La ESP se llenó, las escrituras fallaron parcialmente y el sistema quedó con artefactos de arranque descoordinados.

El síntoma inmediato fue inconsistente: algunos dispositivos arrancaban Linux pero no Windows, otros al revés, otros no arrancaban ninguno y caían al shell del firmware.
El equipo quemó horas porque cada portátil parecía “único”, cuando la causa era aburridamente uniforme: la ESP era demasiado pequeña.

Lo arreglaron redimensionando las ESP a una línea base sensata (512 MiB+) e instituyeron una regla:
no borrar manualmente dentro de la ESP a menos que puedas explicar exactamente por qué existe cada archivo y cómo se referencia.
El espacio en disco es más barato que el tiempo de incidente.

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

Una empresa orientada a la seguridad tenía dispositivos de arranque dual para equipos de respuesta a incidentes. Tenían BitLocker activado, Secure Boot activado y Linux con herramientas forenses.
Suena a receta para drama. No lo fue, porque trataban la configuración de arranque como infraestructura.

Cada dispositivo tenía: una copia de la ESP capturada tras el aprovisionamiento, un pequeño runbook impreso en el sobre del activo (sí, en papel) y claves de recuperación depositadas correctamente.
El runbook incluía exactamente tres comandos: efibootmgr -v, un montaje + listado de la ESP y una secuencia de reinstalación del gestor de arranque.

Durante un ciclo de actualización de características de Windows, algunos portátiles cambiaron BootOrder y empezaron a arrancar Windows por defecto.
Los usuarios lo notaron de inmediato porque su flujo de trabajo esperaba Linux primero. Nadie entró en pánico.

Usaron el menú de arranque de una sola vez para entrar en Linux, ejecutaron efibootmgr para restaurar BootOrder y siguieron con su trabajo.
No hubo reimágenes. No hubo “simplemente reinstala”. La práctica aburrida —copias de seguridad y un runbook mínimo— convirtió el evento en un error de redondeo.

Listas de verificación / plan paso a paso

Plan A: Mejor práctica para arranque dual en un disco (UEFI/GPT)

1. Actualiza el firmware BIOS/UEFI antes de la instalación.
   Las actualizaciones de firmware tras instalar pueden reordenar entradas de arranque o cambiar ajustes. Saca el caos de antemano.
2. Configura el firmware: solo UEFI (desactiva CSM), decide Secure Boot activado/desactivado, configura SATA en AHCI (a menos que necesites RAID).
3. Instala Windows primero. Déjalo crear ESP/MSR. Completa la configuración inicial y las actualizaciones.
4. Desactiva Fast Startup en Windows si planeas acceder a NTFS desde Linux.
5. Reduce la partición de Windows desde Administración de discos de Windows (más seguro que hacerlo desde Linux para NTFS).
6. Arranca el instalador de Linux en modo UEFI y confírmalo con ls /sys/firmware/efi.
7. Instala Linux en el espacio liberado. Monta la ESP existente en /boot/efi; no la formatees.
8. Elige el gestor de arranque: instala GRUB o systemd-boot como principal (mi preferencia: systemd-boot si la distro lo soporta limpiamente).
9. Reinicia y valida: ambas rutas de arranque, el BootOrder del firmware y que Windows arranque sin líos de BitLocker.
10. Haz copia de seguridad de la ESP y guarda el archivo fuera del dispositivo.

Plan B: Dos discos (máxima supervivencia)

1. Instala Windows en el Disco 0 con su propia ESP.
2. Instala Linux en el Disco 1, idealmente con su propia ESP también.
3. Configura el disco de arranque por defecto en el firmware al SO que quieras por defecto; deja el otro disponible mediante el menú de arranque.
4. Haz copia de seguridad de ambas ESP; etiquétalas por número de serie del disco.

Guías operativas (haz esto y tu yo futuro estará menos enfadado)

• Mantén la ESP ≥ 512 MiB. Las antiguas ESP OEM de 100 MiB son una trampa.
• No compartas la partición del sistema de Windows para uso RW desde Linux. Si compartes, usa una partición de datos dedicada.
• Haz un cambio a la vez. Cambios simultáneos en gestor de arranque + Secure Boot + BitLocker es cómo pierdes la causalidad.
• Registra tus entradas de arranque (copia la salida de efibootmgr -v en una nota). Cuando falle, querrás “antes vs después”.
• Mantén un USB live de Linux que pueda montar tus sistemas de archivos e incluya efibootmgr/mokutil.

Preguntas frecuentes (FAQ)

1) ¿Debería hacer arranque dual o usar solo una VM?

Si necesitas rendimiento de GPU, acceso completo al hardware o trabajas a nivel de kernel, el arranque dual es razonable.
Si principalmente necesitas las herramientas de usuario de Linux, una VM es operativamente más tranquila y mucho menos probable que se rompa con actualizaciones.

2) ¿Las actualizaciones de Windows pueden borrar GRUB?

Más comúnmente cambian BootOrder para preferir Windows Boot Manager. La eliminación real es más rara pero puede ocurrir si la ESP está corrupta, demasiado pequeña o “limpiada” por humanos.
Trata la ESP como estado crítico compartido y hazle copia de seguridad.

3) ¿Es seguro tener una ESP compartida?

Sí, si está dimensionada correctamente (512 MiB+), montada correctamente y no se modifica rutinariamente a mano.
La ESP compartida es el modelo estándar para lo que UEFI fue diseñado. La fragilidad viene de la mala higiene, no del concepto.

4) ¿Debería desactivar Secure Boot?

Si usas kernels de distro sin modificaciones, mantén Secure Boot activado. Es un control de seguridad real y generalmente funciona.
Si planeas ejecutar kernels/módulos personalizados y no quieres gestionar firmas, desactívalo. Elige uno y mantente con él.

5) ¿Cómo evito solicitudes de recuperación de BitLocker?

No cambies la cadena de arranque tras habilitar BitLocker a menos que lo suspendas primero. Estabiliza el gestor de arranque, la configuración del firmware y el estado de Secure Boot, luego habilita BitLocker.
Mantén las claves de recuperación accesibles porque “evitar solicitudes” es una meta, no una garantía.

6) GRUB o systemd-boot: ¿cuál es menos propenso a romperse?

systemd-boot tiene menos capas y suele ser más fácil de razonar en sistemas UEFI, lo que a menudo se traduce en menos sorpresas.
GRUB es más flexible y más documentado para configuraciones exóticas. Si necesitas flexibilidad, acepta la complejidad.

7) ¿Puedo instalar Linux sin tocar el gestor de arranque de Windows?

Puedes mantener Windows Boot Manager como predeterminado y arrancar Linux desde el menú del firmware, o añadir Linux como entrada del firmware sin convertirla en “primaria”.
Esto suele ser la opción menos conflictiva en dispositivos gestionados corporativamente.

8) ¿Qué tamaño deberían tener mis particiones de Linux?

Para una estación de trabajo de desarrollo, no escatimes: 50–100 GiB mínimo para root si compilas contenedores, SDKs o kernels.
Si usas btrfs con snapshots o mantienes muchos kernels, planifica más.

9) ¿Qué sistema de archivos debería usar en Linux: ext4 o btrfs?

ext4 es lo “menos sorprendente”. btrfs ofrece snapshots y rollback fácil, lo cual es genuinamente útil cuando las actualizaciones fallan.
Si eliges btrfs, aprende el flujo de trabajo de snapshot/rollback antes de necesitarlo a las 2 AM.

10) Si clono mi disco a un SSD más grande, ¿seguirá funcionando el arranque dual?

A veces. Clonar puede cambiar IDs de disco, UUIDs de partición o confundir entradas del firmware.
Planea verificar efibootmgr -v, blkid y que el contenido de la ESP coincida con lo esperado tras el clonado.

Conclusión: próximos pasos prácticos

La configuración de arranque dual que sobrevive a las actualizaciones no es magia. Es arquitectura e higiene:
UEFI/GPT, una ESP de tamaño adecuado, un gestor de arranque que comprendes y una ruta de recuperación que puedas ejecutar bajo estrés.

Próximos pasos que puedes hacer hoy:

• Confirma que estás en UEFI/GPT e identifica tu ESP.
• Haz copia de seguridad de la ESP fuera del equipo.
• Decide qué gestor de arranque será primario y ajusta BootOrder en consecuencia.
• Desactiva Fast Startup si compartes datos con NTFS.
• Anota la salida de efibootmgr -v y guarda un USB live a mano.

Si haces esas cinco cosas, la mayoría de los incidentes “la actualización de Windows rompió mi arranque dual” se convierten en una reparación de cinco minutos en lugar de un proyecto de fin de semana.
Y tu yo futuro podrá seguir enfadándose por problemas más interesantes.