La única forma correcta de crear un instalador USB de Windows 11 (UEFI + Secure Boot)

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

¿Te fue útil?

Algunos problemas son aburridos hasta que se vuelven costosos. Un USB instalador de Windows 11 que casi arranca es uno de ellos: aparece en el menú de arranque, parpadea y luego te devuelve al firmware como si no hubiera pasado nada. Mientras tanto miras una sala de conferencias llena de portátiles que “necesitan imagen antes de las 2 PM”.

Esta es la forma de grado de producción para crear un instalador USB de Windows 11 que arranque en sistemas UEFI modernos con Secure Boot activado. Sin folclore. Sin “funciona en mi máquina”. Solo la mecánica, los modos de fallo y las formas más rápidas de demostrar qué está realmente mal.

Qué significa “correcto” (realidad UEFI + Secure Boot)

“USB booteable” no es una sola cosa. Es un conjunto de requisitos que varían dependiendo de si arrancas en BIOS/CSM legado o en UEFI nativo, y si Secure Boot está aplicando políticas. Para Windows 11 en la realidad corporativa, “correcto” significa esto:

Arranque UEFI: El firmware carga un cargador EFI desde una partición FAT32 (normalmente \EFI\BOOT\BOOTX64.EFI).
Compatibilidad con Secure Boot: El cargador EFI está firmado por una clave confiada por el firmware (típicamente la CA UEFI de Microsoft / claves de producción de Windows en sistemas OEM).
Integridad del contenido del instalador: Los archivos de instalación de Windows coinciden con el ISO; sin “reempaquetados misteriosos”, sin archivos medio copiados, sin install.wim/install.esd corruptos.
Diseño de particiones correcto para medios extraíbles: Normalmente GPT funciona bien; MBR también puede arrancar UEFI si la partición FAT32 tiene los archivos correctos, pero GPT es la opción limpia por defecto para sistemas modernos.
Restricciones de FAT32 manejadas correctamente: FAT32 tiene un límite de archivo único de 4 GiB; las imágenes modernas de Windows a veces superan eso para install.wim.

Aquí está el problema: la mayoría de los fallos “mi USB no arranca” no son bugs místicos del firmware. Son uno de estos:

La unidad está formateada NTFS y el firmware del sistema no arranca desde NTFS en UEFI (muchos no lo hacen, algunos sí, y muchos son inconsistentes).
install.wim es mayor de lo que FAT32 soporta, así que alguien “lo arregló” cambiando todo a NTFS, rompiendo el arranque UEFI en la mitad de la flota.
La copia del ISO fue incompleta o está corrupta, y el error solo aparece después del primer reinicio del setup, cuando ya se ha culpado a “los controladores”.
Alguien cambió CSM/Legacy o ajustes de Secure Boot y se olvidó.

Una cita de ingeniería encaja aquí porque resume el juego en operaciones: La esperanza no es una estrategia. — Gene Kranz. Usa verificaciones, no corazonadas.

Broma #1: Secure Boot es como la seguridad del aeropuerto: no juzga tu carácter, juzga tu documentación.

Hechos interesantes y contexto histórico (breve, útil)

Estas son las pequeñas verdades que explican por qué el instalador USB “simple” sigue traicionando a la gente:

UEFI reemplazó al BIOS en cámara lenta. La transición comenzó a mediados de los 2000, pero muchos fabricantes enviaron “UEFI con disfraz de BIOS” (CSM) durante años.
Secure Boot llegó con el hardware de la era Windows 8. Se volvió común en sistemas OEM alrededor de 2012, y las empresas pasaron años aprendiendo qué herramientas de arranque dejaron de funcionar de repente.
El límite de 4 GiB de FAT32 es antiguo pero sigue siendo decisivo. La especificación UEFI requiere que el firmware lea FAT, y FAT32 es la opción más ampliamente soportada.
Antes los medios de instalación de Windows cabían cómodamente. Con el tiempo, más controladores internos, idiomas y funciones inflaron install.wim y hacer “simplemente formatear FAT32” dejó de ser trivial.
Muchos firmwares no pueden arrancar desde exFAT. exFAT es excelente para archivos, pésimo para “¿arrancará esto en un modelo aleatorio de portátil?”.
Algunos firmwares UEFI pueden arrancar NTFS, pero no confíes en ello. Algunos fabricantes añadieron controladores NTFS; otros no; algunos lo hacen solo en ciertas rutas de arranque.
La Media Creation Tool de Microsoft no es magia. Es buena, pero depende de I/O estable, redes estables y controladores USB que no fallen bajo cargas de escritura sostenida.
El “bit de medio extraíble” importaba más antes. Versiones antiguas de Windows se comportaban distinto según si un dispositivo reportaba ser extraíble. Hoy es menos dramático, pero supuestos heredados perduran en las herramientas.
GPT vs MBR no es solo estilo. GPT se alinea con el diseño de UEFI y evita algunos casos extraños con el descubrimiento de particiones en sistemas modernos.

Elección de herramientas: Media Creation Tool vs Rufus vs DIY

Elige herramientas como eliges sistemas de archivos: según los modos de fallo, no por popularidad.

Opción A (recomendada en Windows): Media Creation Tool

Si estás en una estación de administración Windows con internet razonable, la Media Creation Tool de Microsoft es la línea más directa. Tiende a crear medios que simplemente funcionan con Secure Boot porque sigue el camino aprobado.

Inconveniente: cuando falla, a menudo falla de formas que parecen “problema del USB” pero en realidad son inspección TLS, interferencia de proxy, protección de endpoints que intercepta escrituras en disco o un controlador USB inestable.

Opción B (recomendada cuando necesitas control): Rufus

Rufus es la herramienta a la que recurres cuando:

Ya tienes un ISO (tal vez obtenido de un recurso interno confiable).
Necesitas elegir GPT/MBR intencionalmente.
Necesitas arranque FAT32 con una imagen grande (Rufus puede dividir el WIM o usar shims UEFI:NTFS según tus opciones).

Inconveniente: la flexibilidad invita a opciones “ingeniosas”. Lo ingenioso es el enemigo de la fiabilidad en la flota.

Opción C (Linux o “no confío en GUIs hoy”): particionado manual + copia de archivos

La creación manual es la más determinista si la haces bien. También es la forma más fácil de crear un USB que arranque en tu máquina y falle en todas las demás si te saltas pasos (NTFS, exFAT, tipo de partición incorrecto, ruta EFI faltante).

Qué deberías evitar:

Hacer dd del ISO al USB y darlo por terminado. Esto funciona para muchas ISOs de Linux. Los ISOs de instalación de Windows no están diseñados como imágenes híbridas de forma que arranquen UEFI de forma fiable desde USB escrito en bruto en todos los fabricantes.
“Una partición NTFS, porque el WIM es grande.” Así obtienes una memoria que arranca en un modelo y falla en otro.

Guion de diagnóstico rápido (primero/segundo/tercero)

Cuando el USB no arranca, no tienes tiempo para danza interpretativa. Este es el orden de triaje que encuentra el cuello de botella rápido.

Primero: ¿el firmware lo ve como opción de arranque UEFI?

Si el menú de arranque muestra UEFI: <USB name> (o similar), al menos estás en el universo correcto.
Si solo muestra el dispositivo bajo entradas legacy/BIOS, probablemente tienes formato incorrecto, falta la ruta EFI o el firmware está en modo legacy.

Segundo: ¿la partición del sistema EFI es realmente FAT32 y está poblada correctamente?

Busca \EFI\BOOT\BOOTX64.EFI. Si falta, el USB podría ser “booteable” en teoría pero no de la forma que UEFI espera.

Tercero: interacción con Secure Boot

Si desactivar Secure Boot hace que arranque, no estás usando una ruta de arranque firmada por Microsoft (o tus claves de firmware son personalizadas/bloqueadas).
Si aún no arranca, no es Secure Boot; es el diseño del medio, corrupción o ajustes del firmware como CSM.

Cuarto: la trampa de FAT32 de 4 GiB

Si el USB es FAT32 pero el ISO contiene un install.wim mayor de 4 GiB, alguien o bien:

cambió a NTFS (rompiendo UEFI en muchos sistemas), o
dividió el WIM (correcto), o
usó install.esd (a menudo más pequeño), o
copió archivos parcialmente (peor, parece “bien” hasta que setup necesita el archivo).

Quinto: la propia memoria USB

Las memorias baratas fallan de formas aburridas: la caché de escritura miente, bloques defectuosos, reinicios del controlador. Si la verificación falla o la copia es inconsistente, deja de discutir con la física y cambia la memoria.

Broma #2: La memoria USB más barata es la que solo te cuesta la memoria, no tu tarde.

Listas de verificación / plan paso a paso (el camino aburrido y correcto)

Este es el plan que pondría en un runbook interno y esperaría que un nuevo contratado ejecute sin invocarme.

Checklist: prerequisitos

Un ISO de Windows 11 conocido y bueno de una fuente confiable (o salida de Media Creation Tool).
Una memoria USB de un proveedor reputado, 16 GB o más. 8 GB a veces funciona, a veces no, y siempre hace perder tiempo.
Una máquina para crear el medio con energía estable y puertos USB estables (prefiere puertos de placa base, no un hub tambaleante).
Sistemas objetivo configurados para arranque UEFI (CSM/Legacy desactivado) a menos que tengas una razón específica para lo contrario.

Checklist: cómo debe verse el USB cuando está “listo”

Tabla de particiones: GPT (preferido) o MBR (aceptable si se hace correctamente).
Al menos una partición FAT32 que contenga:
- \EFI\BOOT\BOOTX64.EFI
- \sources\boot.wim
- \sources\install.wim (o partes WIM divididas) / install.esd
Si install.wim es demasiado grande para FAT32: o lo divides o usas un enfoque de particiones duales (FAT32 para arranque + NTFS para la carga grande) solo si entiendes que tu flota de firmware lo soporta. En flotas mixtas, dividir el WIM es la elección conservadora.

Checklist: validación antes de irte

Verificar checksum del ISO o integridad de archivos.
Verificar que el USB tiene los archivos y tamaños esperados.
Probar el arranque en al menos dos modelos de hardware diferentes si esto es para una flota.
Mantener Secure Boot habilitado durante las pruebas. Si solo pruebas con Secure Boot desactivado, no has probado.

Métodos en Windows (recomendados y alternativos)

Método 1: Media Creation Tool (menos drama)

Ejecuta la herramienta, elige “Crear medios de instalación”, selecciona USB. Luego valida (no omitas la validación porque “Microsoft lo hizo”). Los problemas suelen venir del entorno: proxy, endpoint y estabilidad del USB.

Cuando termine, inspecciona la memoria: confirma FAT32 y confirma que existe la ruta de arranque EFI.

Método 2: Rufus con GPT + UEFI + FAT32 (mejor equilibrio)

Usa Rufus cuando ya tienes un ISO y quieres un resultado predecible.

Esquema de partición: GPT
Sistema objetivo: UEFI (sin CSM)
Sistema de archivos: FAT32 (por defecto para UEFI)

Si Rufus advierte que install.wim es demasiado grande para FAT32, elige la opción que divide el WIM (si está disponible) en lugar de cambiar todo a NTFS por conveniencia. La conveniencia es un préstamo a corto plazo con intereses terribles.

Método 3: Diskpart + montar ISO + copiar (para gente que quiere evidencias)

Esto es explícito y depurable. La contrapartida es que debes manejar el problema de 4 GiB de FAT32 tú mismo.

Métodos en Linux (cuando estás en un datacenter o jumpbox)

Si estás en Linux, puedes crear medios de instalación de Windows perfectamente buenos. El truco es aceptar que “escribir ISO al USB” no es el objetivo. El objetivo es: una partición EFI FAT32 con los archivos correctos, más una forma de llevar la imagen de instalación grande.

El enfoque más compatible es: una partición FAT32, copiar archivos, y si es necesario dividir install.wim en partes install.swm. Windows Setup entiende archivos WIM divididos.

Detalles de Secure Boot: qué comprueba y qué no

Secure Boot a menudo es culpado por problemas que no causó. Es exigente, pero no es aleatorio.

Secure Boot valida firmas en binarios EFI (cargadores, shims, algunas rutas de ROM de opción). Si el binario EFI no está firmado por una clave confiada, el firmware se niega a ejecutarlo.
Secure Boot no valida todo el contenido del USB. No calcula hashes de cada archivo en \sources. Eso es tu trabajo.
Los fallos de Secure Boot a menudo parecen “no pasa nada”. Algunos firmwares muestran un mensaje. Otros simplemente te devuelven al menú de arranque como un portero educado.
Existen claves de Secure Boot personalizadas. Las empresas a veces inscriben su propia Platform Key (PK) y bases de datos (db/dbx). Eso puede romper medios genéricos que funcionan en laptops de consumo.

Si estás en un entorno con políticas personalizadas de Secure Boot, la “única forma correcta” puede implicar usar medios aprobados por la empresa o procesos de firmado. Pero para conjuntos de claves OEM estándar, un medio de instalación de Windows 11 construido correctamente arrancará bajo Secure Boot.

Tres mini-historias del mundo corporativo (dolor con lección)

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

Estaban desplegando portátiles para una nueva oficina. El equipo tenía un USB de Windows 11 “conocido y bueno” hecho meses atrás, etiquetado con cariño y tratado como un artefacto sagrado. Funcionaba en los modelos antiguos. Luego llegó el nuevo lote y la mitad de las máquinas se negó a arrancarlo en UEFI.

La suposición era simple: “Si arranca en un portátil, es booteable.” Esa suposición ignora la fea verdad de que las implementaciones UEFI varían, especialmente alrededor de los controladores de sistema de archivos y cómo enumeran medios extraíbles.

Tras una hora alternando ajustes del BIOS y culpando a “un lote malo de portátiles”, alguien revisó el diseño del USB. Era una sola partición NTFS porque el creador había chocado con el muro de 4 GiB de FAT32 y lo resolvió cambiando a NTFS. Los modelos antiguos casualmente podían arrancar desde NTFS. Los nuevos no.

La solución fue aburrida: reconstruir el medio con una partición de arranque FAT32 y dividir install.wim. La lección entró en el runbook: nunca confíes en el soporte de arranque NTFS a menos que controles los modelos y versiones de firmware. “Funciona en uno” no es un plan de pruebas.

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

Otra organización se puso lista. Construían medios de instalación a escala y querían copias más rápidas. Alguien decidió formatear el USB como exFAT porque es “moderno” y soporta archivos grandes sin dividirlos. También suele ser más rápido que FAT32 para escrituras secuenciales grandes.

En el laboratorio fue genial. La copia fue más rápida y el problema del tamaño desapareció. Luego los técnicos de campo empezaron a reportar que el USB “no aparece” en el menú UEFI en varios sistemas. En algunos, aparecía pero fallaba al cargar el cargador.

El post-mortem fue predecible: el soporte de exFAT en firmware UEFI no es universal. Algunos fabricantes incluyen controladores exFAT; muchos no. Incluso dentro de un mismo fabricante puede variar entre generaciones.

Revirtieron a FAT32 y dividieron WIMs. El rendimiento empeoró ligeramente, la fiabilidad mejoró dramáticamente y el tiempo para imagen mejoró porque el proceso dejó de fallar aleatoriamente. Esa es la versión SRE de “optimización”: reducir la varianza primero.

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

Una empresa sensible a la seguridad tenía un estándar: cada ISO usado para instalación debía validarse, y cada USB creado para despliegue debía pasar una comprobación simple de manifiesto de archivos. No era sofisticado. Era un script que comprobaba la presencia y el tamaño de un puñado de archivos críticos, más un hash puntual del ISO almacenado internamente.

Una semana, una corrida de imágenes empezó a fallar después del primer reinicio. Windows Setup iniciaba, copiaba archivos y luego fallaba con un error tipo “no puede encontrar archivos requeridos”. Los técnicos culparon al hardware objetivo, luego a la red, luego a la fase lunar.

La comprobación del manifiesto señaló que \sources\boot.wim existía pero tenía un tamaño incorrecto en un subconjunto de memorias. Eso lo acotó inmediatamente: copia parcial o fallo de escritura. Encontraron un lote de memorias USB con controladores que se reiniciaban bajo escrituras sostenidas, truncando silenciosamente archivos grandes.

Cambiaron las memorias, volvieron a crear imágenes y el problema desapareció. La validación “aburrida” ahorró horas y evitó una tormenta de culpas entre ingeniería de escritorios y el equipo de seguridad de endpoints. También reforzó un principio: el medio extraíble es poco fiable hasta que se demuestre lo contrario.

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

Esta sección existe porque los mismos errores se repiten eternamente, como problemas de impresora y “no cambiamos nada”.

1) El USB no aparece en el menú de arranque UEFI

Síntoma: El USB es visible en el sistema operativo, pero el menú de arranque no tiene una entrada UEFI para él.
Causa raíz: No hay partición FAT32 con la ruta EFI; tabla de particiones/banderas incorrectas; memoria formateada solo en exFAT/NTFS; firmware en modo solo legacy.
Solución: Recrear con GPT + FAT32 y asegurar que \EFI\BOOT\BOOTX64.EFI existe. Desactivar CSM/Legacy y activar UEFI.

2) El USB aparece, pero al arrancar vuelve inmediatamente al firmware

Síntoma: Seleccionas el USB, la pantalla parpadea y estás de vuelta en BIOS/menú de arranque.
Causa raíz: Secure Boot rechazó el cargador; archivos EFI faltantes/corruptos; el firmware no puede leer el sistema de archivos con fiabilidad.
Solución: Confirmar FAT32 y archivos EFI; probar con Secure Boot temporalmente desactivado para aislar; reconstruir desde un ISO conocido bueno en otra memoria/puerto.

3) Windows Setup inicia, luego muestra errores “faltan controladores” o “no encuentra el medio”

Síntoma: La interfaz de Setup carga, luego pide un controlador o dice que no puede encontrar los archivos de instalación.
Causa raíz: Copia corrupta/ parcial; install.wim dañado; usar puertos USB 3 con controlador/firmware inestable; controladores raros del controlador de almacenamiento faltantes en el hardware objetivo.
Solución: Verificar tamaños/hashes de archivos; copiar de nuevo; probar otro puerto USB (a menudo puerto USB 2 es más tolerante); confirmar integridad del ISO; solo entonces considerar inyectar controladores.

4) Error al copiar archivos a FAT32: “archivo demasiado grande”

Síntoma: La copia falla en install.wim.
Causa raíz: Límite de archivo único de 4 GiB de FAT32.
Solución: Dividir WIM (dism /Split-Image) o usar un ISO que contenga install.esd (a menudo más pequeño). Evita cambiar todo el USB a NTFS a menos que controles el soporte de firmware.

5) Arranca en un modelo, falla en otro

Síntoma: La misma memoria, resultados distintos según el dispositivo.
Causa raíz: Diferencias de firmware (soporte NTFS/exFAT, peculiaridades de enumeración USB, conjuntos de claves de Secure Boot).
Solución: Estandarizar en la ruta de arranque UEFI FAT32; dividir WIM; probar en hardware representativo. Si hay claves personalizadas de Secure Boot desplegadas, usar medios/aprobaciones firmadas por la empresa.

Tareas prácticas con comandos, salidas y decisiones

Pides las tareas reales. Aquí están: no solo comandos, sino qué significa la salida y qué decisión tomas después. Los comandos se muestran como si se ejecutaran desde una caja admin Linux. Si estás en Windows, trata estos como comprobaciones equivalentes usando Disk Management, PowerShell o tu herramienta de imagen.

Tarea 1: Identificar el dispositivo USB de forma fiable (no borres el disco equivocado)

cr0x@server:~$ lsblk -o NAME,SIZE,MODEL,SERIAL,TRAN,FSTYPE,MOUNTPOINTS
NAME   SIZE MODEL            SERIAL        TRAN FSTYPE MOUNTPOINTS
sda    477G Samsung_SSD_860  S3Z...        sata
├─sda1 512M                 ...                 vfat   /boot/efi
├─sda2  50G                 ...                 ext4   /
└─sda3 426G                 ...                 ext4   /var
sdb   28.9G Ultra_Fit        4C53...       usb
└─sdb1  28G                 ...                 exfat  /media/cr0x/USB

Qué significa: sdb es la memoria USB de clase 32 GB (28.9G). Actualmente está en exFAT, lo cual es una señal de alerta para compatibilidad de arranque UEFI.

Decisión: Proceder a reparticionar /dev/sdb. Verifica el modelo/serial antes de tocarlo.

Tarea 2: Confirmar que el USB no está montado antes de borrar

cr0x@server:~$ mount | grep -E '^/dev/sdb'
/dev/sdb1 on /media/cr0x/USB type exfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000)

Qué significa: La partición está montada.

Decisión: Desmontarla limpiamente antes de particionar.

Tarea 3: Desmontar las particiones USB

cr0x@server:~$ sudo umount /dev/sdb1

Qué significa: No suele producir salida si tiene éxito.

Decisión: Verificar que ya no aparece en mount y continuar.

Tarea 4: Borrar firmas de tabla de particiones existentes (rápido y efectivo)

cr0x@server:~$ sudo wipefs -a /dev/sdb
/dev/sdb: 2 bytes were erased at offset 0x000001fe (dos): 55 aa
/dev/sdb: 8 bytes were erased at offset 0x00000438 (exfat): 45 58 46 41 54 20 20 20

Qué significa: Se borraron firmas DOS MBR y exFAT antiguas.

Decisión: Crear un nuevo GPT y particiones explícitamente.

Tarea 5: Crear una tabla de particiones GPT y una sola partición FAT32

cr0x@server:~$ sudo parted -s /dev/sdb mklabel gpt
cr0x@server:~$ sudo parted -s /dev/sdb mkpart primary fat32 1MiB 100%
cr0x@server:~$ sudo parted -s /dev/sdb set 1 esp on
cr0x@server:~$ sudo parted -s /dev/sdb print
Model: SanDisk Ultra Fit (scsi)
Disk /dev/sdb: 31.0GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  31.0GB  31.0GB               primary  boot, esp

Qué significa: GPT existe; la partición 1 está marcada ESP (EFI System Partition) y abarca el dispositivo.

Decisión: Formatearla como FAT32 y etiquetar el volumen de forma sensata.

Tarea 6: Formatear FAT32 y etiquetar el volumen

cr0x@server:~$ sudo mkfs.vfat -F 32 -n WIN11_USB /dev/sdb1
mkfs.fat 4.2 (2021-01-31)

Qué significa: Sistema de archivos FAT32 creado. Esto es lo que a UEFI le gusta para arrancar.

Decisión: Montarlo y copiar el contenido del ISO.

Tarea 7: Montar el ISO de Windows como solo lectura

cr0x@server:~$ sudo mkdir -p /mnt/winiso
cr0x@server:~$ sudo mount -o loop,ro Win11_23H2_English_x64.iso /mnt/winiso
cr0x@server:~$ ls /mnt/winiso
autorun.inf  boot  bootmgr  bootmgr.efi  efi  sources  support

Qué significa: ISO montado; contiene la estructura de instalación de Windows esperada.

Decisión: Comprobar el tamaño de install.wim o install.esd para decidir si necesitas dividirlo.

Tarea 8: Determinar si la imagen cabe en FAT32

cr0x@server:~$ ls -lh /mnt/winiso/sources/install.*
-r--r--r-- 1 root root 5.3G Jan 10 12:00 /mnt/winiso/sources/install.wim

Qué significa: install.wim tiene 5.3G. FAT32 no puede almacenar un archivo tan grande.

Decisión: Dividir el WIM en partes SWM (soportado por Windows Setup) y copiar todo lo demás normalmente.

Tarea 9: Dividir install.wim en partes install.swm

En Linux, la vía más sencilla es hacer la división en una máquina Windows con DISM. Pero aún puedes orquestar el flujo aquí; lo importante es que la salida debe ser varios archivos .swm bajo \sources.

Asumiendo que tienes una caja Windows disponible, ejecutarías:

cr0x@server:~$ printf '%s\n' "Run this on Windows:" "dism /Split-Image /ImageFile:D:\sources\install.wim /SWMFile:E:\sources\install.swm /FileSize:3800"
Run this on Windows:
dism /Split-Image /ImageFile:D:\sources\install.wim /SWMFile:E:\sources\install.swm /FileSize:3800

Qué significa: DISM creará install.swm, install2.swm, etc., cada uno de ~3.8 GB.

Decisión: Si no puedes hacer eso, usa Rufus (puede automatizarlo), u obtén un ISO con install.esd lo suficientemente pequeño para FAT32. No “soluciones” formateando todo el USB en NTFS a menos que controles el comportamiento del firmware.

Tarea 10: Copiar archivos al USB (excluyendo el WIM sobredimensionado)

cr0x@server:~$ sudo mkdir -p /mnt/usb
cr0x@server:~$ sudo mount /dev/sdb1 /mnt/usb
cr0x@server:~$ sudo rsync -avh --exclude='sources/install.wim' /mnt/winiso/ /mnt/usb/
sending incremental file list
./
autorun.inf
boot/
boot/boot.sdi
bootmgr
bootmgr.efi
efi/
efi/boot/
efi/boot/bootx64.efi
sources/
sources/boot.wim
sources/setup.exe
...
sent 1.02G bytes  received 18.4K bytes  54.2M bytes/sec
total size is 5.89G  speedup is 5.75

Qué significa: Se copió todo excepto install.wim. Observa que efi/boot/bootx64.efi existe: esta es la ruta crítica del cargador UEFI para medios removibles.

Decisión: Coloca los archivos divididos install*.swm en /mnt/usb/sources/. Luego verifica la presencia y tamaños de archivos.

Tarea 11: Verificar que la ruta de arranque EFI existe en el USB

cr0x@server:~$ ls -l /mnt/usb/EFI/BOOT/BOOTX64.EFI
-rwxr-xr-x 1 root root 1556480 Jan 10 12:00 /mnt/usb/EFI/BOOT/BOOTX64.EFI

Qué significa: El cargador canónico de arranque para medios removibles UEFI está presente.

Decisión: Si este archivo falta, no vale la pena probar: arregla la copia o reconstruye el medio.

Tarea 12: Comprobar el tipo de sistema de archivos y la etiqueta (atrapa “ups NTFS” temprano)

cr0x@server:~$ lsblk -f /dev/sdb
NAME   FSTYPE FSVER LABEL     UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sdb
└─sdb1 vfat   FAT32 WIN11_USB 2A3B-1C2D                             24.1G    22%  /mnt/usb

Qué significa: FAT32 está en su lugar. Bien.

Decisión: Proceder a desmontar limpiamente; no lo arranques a la fuerza durante una escritura.

Tarea 13: Vaciar escrituras y desmontar

cr0x@server:~$ sync
cr0x@server:~$ sudo umount /mnt/usb

Qué significa: Los datos se han vaciado y el sistema de archivos está limpio.

Decisión: Ahora puedes probar el arranque. Si omites esto, mereces la próxima hora de tu vida.

Tarea 14: Verificar integridad del ISO con SHA256 (confía pero verifica)

cr0x@server:~$ sha256sum Win11_23H2_English_x64.iso
5f2a2b1d7d0c1f0c7b7c4d8e2d4f7a6d1c2b3a4f5e6d7c8b9a0f1e2d3c4b  Win11_23H2_English_x64.iso

Qué significa: Tienes un hash para comparar.

Decisión: Compáralo con el valor esperado de tu proceso interno de confianza. Si no puedes validar el ISO, estás instalando desde un artefacto desconocido: trátalo como un incidente de seguridad, no como un “meh”.

Tarea 15: Buscar errores silenciosos de E/S en el registro del sistema mientras escribes

cr0x@server:~$ dmesg --since "10 minutes ago" | tail -n 20
[  +0.000000] sd 6:0:0:0: [sdb] Attached SCSI removable disk
[  +2.143211] FAT-fs (sdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

Qué significa: El kernel notó un desmontaje no limpio en algún momento. Eso puede causar fallos “aleatorios” de arranque o archivos faltantes.

Decisión: Ejecutar una comprobación del sistema de archivos o reconstruir la memoria. Para medios de instalación, reconstruir suele ser más rápido que confiar en una FAT reparada.

Tarea 16: Ejecutar una comprobación del sistema de archivos FAT (cuando sospechas corrupción)

cr0x@server:~$ sudo fsck.vfat -a /dev/sdb1
fsck.fat 4.2 (2021-01-31)
Reclaimed 12 unused clusters (49152 bytes).
Performing changes.

Qué significa: Se corrigieron inconsistencias menores. Eso ya es un olor: los medios removibles no deberían necesitar reparaciones justo después de crearlos.

Decisión: Si esto ocurre repetidamente con el mismo modelo de memoria, retira ese lote. El medio es barato; la falla es cara.

Preguntas frecuentes

1) ¿Puedo simplemente formatear el USB en NTFS y copiar el contenido del ISO?

Puedes, y puede que arranque en algunos sistemas. En otros, el firmware UEFI no leerá NTFS en tiempo de arranque. Para una flota mixta, FAT32 es el sistema de archivos seguro para arranque. Maneja el WIM grande dividiéndolo.

2) ¿Por qué importa FAT32 si Windows soporta NTFS?

Porque Windows aún no está arrancando. El que arranca es el firmware. Se espera que el firmware UEFI lea sistemas FAT; el soporte NTFS es opcional e inconsistente entre fabricantes.

3) Mi ISO tiene install.esd en lugar de install.wim. ¿Está bien?

Sí. Windows Setup soporta install.esd. A menudo es más pequeño por compresión y puede caber dentro de los límites de FAT32. Si cabe, la vida es más fácil.

4) ¿Cuál es el diseño más compatible para un USB de instalación de Windows 11?

Tabla de particiones GPT, una sola partición FAT32 marcada como ESP, y los archivos de Windows copiados en ella. Si la imagen es demasiado grande, divide install.wim en install*.swm.

5) Si el USB solo arranca con Secure Boot desactivado, ¿qué debo hacer?

Eso indica que no estás usando una ruta de cargador confiada por Secure Boot (o tu organización usa claves personalizadas). Reconstruye usando Media Creation Tool o un ISO estándar + método conservador de creación. Si hay claves personalizadas, usa medios aprobados por la empresa.

6) ¿Ventoy es un método “correcto” para Windows 11 UEFI + Secure Boot?

Puede funcionar y es conveniente para llevar múltiples ISOs. Pero añade otra capa de arranque y superficie de políticas. Si estás creando imágenes para una flota y quieres la menor varianza, usa medios de instalación estándar. Si eres un ingeniero de laboratorio que prueba muchos ISOs, Ventoy puede estar bien—solo prueba el comportamiento de Secure Boot en tu entorno exacto.

7) ¿Por qué mi USB aparece dos veces en el menú de arranque?

A menudo verás una entrada legacy y una UEFI. Elige la UEFI. Si arrancas en legacy/CSM, puedes terminar con distintos valores por defecto de particionado y con interacciones inesperadas con BitLocker/TPM después.

8) Windows Setup dice que no puede encontrar un controlador para mi disco. ¿Mi USB está mal?

Tal vez, pero no siempre. Primero valida la integridad del contenido del USB (tamaños/hashes) y prueba otro puerto. Si el objetivo usa un controlador de almacenamiento que necesita drivers (raro en portátiles modernos, más común en servidores), entonces sí—puede que necesites proporcionar controladores. No empieces por ahí.

9) ¿Debo desactivar Fast Boot en la BIOS al arrancar USBs instaladores?

En algunos sistemas, sí. “Fast Boot” puede saltarse rutas de inicialización USB y hacer que los menús de arranque sean inestables. Si el USB aparece de forma intermitente, desactiva Fast Boot durante la fase de instalación.

10) ¿Importa GPT en el USB si es extraíble?

No estrictamente, pero reduce ambigüedad y se alinea con el diseño de UEFI. MBR aún puede funcionar para medios removibles UEFI, pero GPT es el defecto que yo estandarizaría en 2026.

Conclusión: próximos pasos que realmente reducen el riesgo

Si quieres un instalador USB de Windows 11 que arranque bajo UEFI con Secure Boot, deja de tratarlo como un problema de “copiar archivos a una memoria”. Trátalo como una cadena de arranque y un problema de restricciones de sistema de archivos.

Haz esto a continuación:

Estandariza un único método para tu organización: Media Creation Tool o Rufus con GPT/UEFI/FAT32 y división de WIM. Escríbelo.
Haz la validación obligatoria: comprueba \EFI\BOOT\BOOTX64.EFI, confirma FAT32, confirma estrategia de imagen (.esd o .swm dividido).
Prueba en al menos dos modelos de hardware con Secure Boot habilitado antes de declarar victoria.
Retira rápidamente medios defectuosos: si una memoria lanza errores de sistema de archivos o produce copias parciales, está fuera. No negociéis.

La única forma “correcta” es la que arranca siempre en el hardware que realmente posees, con las configuraciones de seguridad que realmente aplicas. Todo lo demás es una demostración.