Crear un USB arrancable que realmente arranque (UEFI/Legacy hecho bien)

El modelo mental: qué significa realmente “arrancable”

Cuando la gente dice “hacer un USB arrancable”, normalmente quiere decir: “Poner un ISO en una unidad para que el firmware lo encuentre, cargue un cargador de arranque y el cargador cargue un kernel o instalador.” Esa frase oculta tres sistemas independientes que fallan de forma independiente:

• El medio USB y el particionado: ¿presenta la unidad una tabla de particiones y sistemas de ficheros que el firmware pueda leer?
• La ruta de arranque del firmware: UEFI o BIOS (Legacy). Cada uno tiene expectativas distintas sobre particiones, sectores de arranque y disposición de ficheros.
• La cadena del cargador de arranque: ejecutable EFI, GRUB/syslinux, gestor de arranque de Windows, etc. Debe coincidir con el modo de la máquina (UEFI vs Legacy) y la arquitectura de CPU.

La fiabilidad viene de controlar las variables. “Usé una herramienta gráfica y funcionó una vez” no es control. Control es: verificar el ISO, escribirlo en un modo apropiado para el tipo de ISO, confirmar la disposición de particiones de la unidad y confirmar que la máquina está intentando el modo de arranque correcto.

Además: tu firmware no es tu amigo. Es una bibliotecaria excesivamente confiada con un sistema de archivos estricto y sin empatía. O etiquetas los libros correctamente o no te atienden.

Hechos interesantes y contexto histórico

Entender por qué las cosas son como son te ayuda a dejar de adivinar. Aquí hay algunos hechos históricos concretos que aparecen en los problemas de arranque actuales:

1. El arranque BIOS vino de discos que no tenían particiones en absoluto. El modelo de sector de arranque original precede al particionado moderno. Por eso “código de arranque en los primeros 446 bytes” sigue importando en 2026.
2. La tabla de particiones MBR siempre fue limitada. Cuatro particiones primarias parecían generosas hasta que no lo fueron; por eso existen particiones extendidas y también por eso la gente migró a GPT.
3. UEFI estandarizó el arranque como “cargar un ejecutable EFI desde un sistema de ficheros”. Ese es un cambio enorme: el firmware puede leer sistemas FAT y ejecutar archivos como BOOTX64.EFI.
4. La “EFI System Partition” (ESP) suele ser FAT32 por una razón. FAT es simple y ampliamente soportado en firmware, a diferencia de ext4, NTFS o sistemas de ficheros con journaling avanzados.
5. Secure Boot no es cifrado; es aplicación de firmas. Rechaza ejecutar binarios EFI que no estén firmados por claves que el firmware confíe.
6. Existen ISOs híbridos porque los proveedores querían una imagen para múltiples caminos de arranque. Algunos ISOs de Linux son imágenes ISO9660 con tablas de particiones embebidas para que puedas ddlos directamente al USB.
7. El medio de instalación de Windows tiene hace tiempo opiniones sobre FAT32 y tamaño de archivos. El archivo install.wim puede superar 4 GiB, que FAT32 no admite; muchas herramientas lo dividen o pasan a NTFS—con consecuencias para la compatibilidad UEFI.
8. Las entradas de arranque UEFI pueden ser “pegajosas” y engañosas. El NVRAM del firmware recuerda entradas que apuntan a dispositivos que ya no existen, lo que genera opciones de arranque fantasma y confianza falsa.
9. Las unidades USB mienten. Algunas son “disco fijo” frente a “removible” de formas que cambian cómo funcionan las herramientas de Windows; algunos controladores son inestables bajo escrituras sostenidas y corrompen datos en silencio.

Una cita que vale la pena tener en tu escritorio:

“idea parafraseada” — Gene Kranz: la disciplina rigurosa y procedimientos claros previenen fallos evitables.

Elige tu método de creación de USB (y por qué)

Método A: Escribir el ISO en bruto (ideal para ISOs híbridos de Linux)

Si el ISO está diseñado para escribirse “tal cual” en el USB (común en instaladores Linux), el método más fiable es una escritura en bruto. Estás clonando la disposición de imagen que el distro probó. Sin reinterpretaciones creativas por parte de herramientas. Sin “ayuda” de reformateo que rompa el arranque UEFI.

Usa esto cuando:

• El ISO es un instalador moderno de Linux y el proveedor admite explícitamente dd o imagen en bruto.
• Quieres la cadena de custodia más simple: checksum → escribir → arrancar.

Evita esto cuando:

• Estás creando un medio de instalación de Windows desde un ISO (escribir Windows en bruto normalmente no produce un USB arrancable como esperas).
• Necesitas almacenamiento persistente en el mismo USB sin pasos adicionales.

Método B: Copia de archivos en un ESP preparado (mejor cuando controlas la disposición)

Para arranque UEFI, lo que importa es: una partición FAT32 con \EFI\BOOT\BOOTX64.EFI (o el equivalente de arquitectura). Puedes construir eso deliberadamente. Esto es ideal cuando necesitas cargadores personalizados, argumentos de kernel personalizados o estás construyendo medios de rescate en un entorno controlado.

Método C: Usar una herramienta multiboot (estilo Ventoy) cuando valoras flexibilidad

Estas herramientas instalan un cargador una vez y luego copias ISOs como archivos. Es cómodo y a menudo funciona, pero no es magia. Algunas configuraciones de Secure Boot lo bloquean, algunas implementaciones extrañas de firmware lo odian y algunos ISOs requieren manejo especial.

Esta es la opción “llevar muchas herramientas”. Excelente para trabajo de campo. No es mi primera opción para entornos con cumplimiento estricto.

Broma #1: Un USB arrancable es como un paracaídas—si es “probablemente está bien”, aprenderás algo nuevo muy rápido.

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

Estas son tareas probadas en campo. Cada una incluye el comando, salida de ejemplo, qué significa la salida y la decisión que tomas. Ejecuta en Linux; si estás en macOS o Windows, traduce las ideas, no la sintaxis.

Tarea 1: Identificar correctamente el dispositivo USB (antes de destruir un disco)

cr0x@server:~$ lsblk -o NAME,SIZE,MODEL,TRAN,RM,FSTYPE,MOUNTPOINTS
NAME   SIZE MODEL            TRAN RM FSTYPE MOUNTPOINTS
sda   953.9G Samsung_SSD      sata  0        
├─sda1  512M                  0    vfat   /boot/efi
├─sda2  200G                  0    ext4   /
└─sda3  753G                  0    ext4   /var
sdb    28.9G SanDisk_Ultra     usb  1        
└─sdb1 28.9G                   1    exfat  /media/cr0x/USB

Qué significa: sdb es removible (RM=1) y con transporte USB. Ese es tu objetivo.

Decisión: Si el objetivo no es claramente un USB removible, detente. Vuelve a ejecutar con la unidad desenchufada/enchufada para confirmar la diferencia.

Tarea 2: Confirmar que nada está montado desde el dispositivo objetivo

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

Qué significa: El sistema operativo está usando activamente el sistema de ficheros.

Decisión: Desmonta antes de crear la imagen; de lo contrario arriesgas corrupción y “escribió bien pero no arranca”.

Tarea 3: Desmontar limpiamente

cr0x@server:~$ sudo umount /dev/sdb1
cr0x@server:~$ echo $?
0

Qué significa: El código de salida 0 indica éxito.

Decisión: Si el desmontaje falla por “busy”, cierra gestores de archivos, terminales con cd al medio, o usa lsof para encontrar bloqueadores.

Tarea 4: Verificar la suma de verificación del ISO (no depurar una descarga corrupta)

cr0x@server:~$ sha256sum ubuntu-24.04.1-live-server-amd64.iso
d7b1e3c3f8f2b6d7d8a4c1c6f0d2a0b3a4d7c5a0b8f2e1d3c4b5a6f7e8d9c0b1  ubuntu-24.04.1-live-server-amd64.iso

Qué significa: Tienes un hash determinista que puedes comparar con el valor publicado por el proveedor.

Decisión: Si no coincide, borra y vuelve a descargar. No “intentes de todos modos”. Así es como se pierden tardes.

Tarea 5: Inspeccionar si el ISO es una imagen híbrida (indicador para escritura en bruto)

cr0x@server:~$ file ubuntu-24.04.1-live-server-amd64.iso
ubuntu-24.04.1-live-server-amd64.iso: ISO 9660 CD-ROM filesystem data (DOS/MBR boot sector) 'Ubuntu-Server 24.04.1 LTS amd64'

Qué significa: “DOS/MBR boot sector” sugiere un ISO híbrido con estructuras de arranque embebidas.

Decisión: Prefiere la escritura en bruto (dd o equivalente) para este tipo de imagen.

Tarea 6: Escribir el ISO en bruto al USB (Linux)

cr0x@server:~$ sudo dd if=ubuntu-24.04.1-live-server-amd64.iso of=/dev/sdb bs=4M conv=fsync status=progress
1562378240 bytes (1.6 GB, 1.5 GiB) copied, 32 s, 48.8 MB/s
2971666432 bytes (3.0 GB, 2.8 GiB) copied, 61 s, 48.7 MB/s
4026531840 bytes (4.0 GB, 3.8 GiB) copied, 83 s, 48.5 MB/s
4630511616 bytes (4.6 GB, 4.3 GiB) copied, 96 s, 48.2 MB/s
1103+1 records in
1103+1 records out
4630511616 bytes (4.6 GB, 4.3 GiB) copied, 96.1312 s, 48.2 MB/s

Qué significa: La imagen se escribió completamente, y conv=fsync fuerza el vaciado de datos.

Decisión: Después de dd, no arranques la unidad inmediatamente. Deja que udev asiente y luego valida la disposición.

Tarea 7: Forzar al kernel a releer la tabla de particiones

cr0x@server:~$ sudo partprobe /dev/sdb
cr0x@server:~$ lsblk -f /dev/sdb
NAME   FSTYPE FSVER LABEL       UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sdb                                                                   
├─sdb1 iso9660      Ubuntu-Server 2024-08-28-14-10-41-00             0     100%  
└─sdb2 vfat   FAT16 UEFI_BOOT   2A1B-3C4D                            

Qué significa: Ahora tienes una partición ISO9660 y una pequeña partición FAT para arranque UEFI. Esto es típico de muchas imágenes híbridas.

Decisión: Si no ves una partición FAT y esperas arranque UEFI, inspecciona el ISO; algunas imágenes son solo Legacy o dependen de otras estructuras.

Tarea 8: Confirmar que existe la ruta de fallback UEFI en la unidad

cr0x@server:~$ sudo mkdir -p /mnt/usb-uefi
cr0x@server:~$ sudo mount /dev/sdb2 /mnt/usb-uefi
cr0x@server:~$ sudo find /mnt/usb-uefi/EFI -maxdepth 2 -type f
/mnt/usb-uefi/EFI/BOOT/BOOTX64.EFI
/mnt/usb-uefi/EFI/BOOT/grubx64.efi

Qué significa: El firmware que no puede o no quiere usar entradas NVRAM aún puede arrancar mediante la ruta por defecto \EFI\BOOT\BOOTX64.EFI.

Decisión: Si falta BOOTX64.EFI, el arranque UEFI probablemente no funcione a menos que el proveedor proporcione una ruta diferente y añadas una entrada manualmente.

Tarea 9: Validar que el ISO se escribió correctamente muestreando bytes

cr0x@server:~$ sudo cmp -n 1048576 ubuntu-24.04.1-live-server-amd64.iso /dev/sdb && echo "first 1MiB matches"
first 1MiB matches

Qué significa: El inicio del dispositivo coincide con el ISO. Esto detecta una buena cantidad de problemas “el controlador mintió”.

Decisión: Si difiere, prueba otro puerto USB, desactiva la suspensión selectiva USB o reemplaza la unidad. Depurar un dispositivo de $8 es un pasatiempo, no operaciones.

Tarea 10: Comprobar GPT vs MBR en el USB (ayuda a explicar el comportamiento del firmware)

cr0x@server:~$ sudo fdisk -l /dev/sdb | sed -n '1,20p'
Disk /dev/sdb: 28.9 GiB, 31016853504 bytes, 60579840 sectors
Disk model: SanDisk Ultra
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x6e9b2a1c

Qué significa: Esta unidad usa una etiqueta MBR (“dos”). Muchos ISOs híbridos lo hacen.

Decisión: Si necesitas GPT explícitamente (algunos firmwares empresariales se comportan mejor), considera un método de copia de archivos con tabla de particiones GPT y una ESP FAT32.

Tarea 11: Crear deliberadamente GPT + ESP FAT32 (para medios UEFI personalizados)

cr0x@server:~$ sudo wipefs -a /dev/sdb
cr0x@server:~$ sudo parted -s /dev/sdb mklabel gpt
cr0x@server:~$ sudo parted -s /dev/sdb mkpart ESP fat32 1MiB 1025MiB
cr0x@server:~$ sudo parted -s /dev/sdb set 1 esp on
cr0x@server:~$ sudo mkfs.vfat -F32 -n UEFI_INSTALL /dev/sdb1
mkfs.fat 4.2 (2021-01-31)

Qué significa: Ahora tienes una partición FAT32 de tamaño ESP limpia con la bandera GPT correcta.

Decisión: Usa esto cuando construyas medios manualmente (binarios EFI personalizados, shims firmados, un entorno de rescate específico del proveedor).

Tarea 12: Copiar el cargador EFI en la ruta de fallback

cr0x@server:~$ sudo mount /dev/sdb1 /mnt/usb
cr0x@server:~$ sudo mkdir -p /mnt/usb/EFI/BOOT
cr0x@server:~$ sudo cp BOOTX64.EFI /mnt/usb/EFI/BOOT/BOOTX64.EFI
cr0x@server:~$ sudo ls -l /mnt/usb/EFI/BOOT
total 1312
-rwxr-xr-x 1 root root 1343488 Feb  4 09:10 BOOTX64.EFI

Qué significa: El firmware tiene un lugar estándar donde buscar, independientemente del estado del NVRAM.

Decisión: Si soportas hardware mixto, incluye siempre la ruta de fallback. Es un seguro barato.

Tarea 13: Verificar que la máquina arrancó en modo UEFI (desde el entorno live)

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

Qué significa: Linux expone servicios de runtime UEFI vía /sys/firmware/efi.

Decisión: Si esperabas UEFI pero obtuviste Legacy, deja de culpar al USB. Arregla la selección del modo de arranque en el firmware.

Tarea 14: Inspeccionar entradas de arranque UEFI existentes (útil cuando el firmware está confundido)

cr0x@server:~$ sudo efibootmgr -v
BootCurrent: 0007
Timeout: 1 seconds
BootOrder: 0007,0003,0001
Boot0001* ubuntu	HD(1,GPT,2f1c...,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)
Boot0003* UEFI: SanDisk, Partition 2	PciRoot(0x0)/Pci(0x14,0x0)/USB(0x5,0x0)/HD(2,MBR,0x6e9b2a1c,0x3a00,0x8000)/File(\EFI\BOOT\BOOTX64.EFI)
Boot0007* UEFI: Built-in EFI Shell	FvFile(7C04...)

Qué significa: El firmware ve la ruta EFI del USB y puedes confirmar cuál arrancó realmente (BootCurrent).

Decisión: Si la entrada del USB no está presente pero la unidad tiene \EFI\BOOT\BOOTX64.EFI, usa el menú de arranque de una sola vez; algunos firmwares no la inscribirán automáticamente.

Tarea 15: Detectar el estado de Secure Boot (culpable común de “falla instantánea”)

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

Qué significa: Los binarios EFI no firmados no se ejecutarán a menos que se inscriban claves (MOK) o estén en la DB del firmware.

Decisión: Si tu USB usa un cargador no firmado, o desactiva Secure Boot para la instalación o usa una cadena basada en shim firmada.

UEFI vs Legacy: cómo decide la máquina qué arrancar

Arranque Legacy BIOS en un párrafo

El BIOS Legacy mira el primer sector del disco (MBR) y ejecuta código allí. Ese código luego encuentra una “siguiente etapa” del cargador de arranque en algún otro lugar. Por eso detalles pequeños—como dónde espera el cargador encontrar stage2—importan. También por eso el tipo de sistema de ficheros no importa directamente al BIOS al inicio: el BIOS no lee archivos; ejecuta código de arranque.

Arranque UEFI en un párrafo

UEFI lee particiones, monta un sistema de ficheros (normalmente FAT) y carga un ejecutable EFI. Puede hacerlo mediante entradas NVRAM (rutas explícitas) o mediante la ruta de fallback \EFI\BOOT\BOOTX64.EFI. UEFI es más limpio, pero las implementaciones del firmware varían enormemente, especialmente en soporte de sistemas de ficheros y comportamiento con medios removibles.

Las reglas clave de compatibilidad que debes seguir

• Si quieres arranque UEFI en todas partes: Proporciona una partición FAT32 que contenga \EFI\BOOT\BOOTX64.EFI.
• Si quieres arranque Legacy en todas partes: Asegúrate de que haya código válido en el MBR, y que el cargador soporte modo BIOS.
• Si quieres ambos: Usa ISOs híbridos provistos por el proveedor, o construye medios que soporten ambas cadenas. No asumas que “capaz de UEFI” funcionará en Legacy, o viceversa.
• No mezcles modos a mitad de instalación. Instalar un SO en modo UEFI normalmente requiere una ESP en el disco objetivo; instalar en Legacy usa sectores de arranque distintos. Mezclar lleva a la clásica tragedia “instaló pero no arranca”.

Broma #2: Los menús de configuración del firmware son el único lugar donde “Guardar y salir” se siente como una amenaza.

Secure Boot: cuando “funciona” pasa a ser “bloqueado”

Secure Boot es la razón por la que un USB arranca bien en un servidor antiguo pero se estrella en un portátil nuevo con imagen corporativa. El firmware verifica firmas de binarios EFI antes de ejecutarlos. Si el binario no está firmado por una clave de confianza, no se ejecuta. Algunos firmwares muestran un mensaje; otros rechazan en silencio y vuelven a la siguiente opción de arranque, lo que parece “USB no detectado”. Sí fue detectado. Fue rechazado.

Qué hacer en entornos reales

• Para instaladores Linux mainstream: usa imágenes que incluyan un shim firmado y GRUB firmado. La mayoría lo hace.
• Para herramientas de rescate personalizadas: firma tus binarios EFI e inscribe tu clave (MOK o DB del firmware), o planifica un procedimiento controlado de desactivación de Secure Boot.
• Para medios Windows: sigue la ruta oficial de creación, porque los componentes de arranque de Windows están firmados y se espera que coincidan.

En un entorno empresarial, desactivar Secure Boot puede estar prohibido salvo procedimientos de emergencia. En ese caso, tu método de creación de USB no es una preferencia personal; es una restricción de cumplimiento.

Tres microhistorias corporativas (anonimizadas, plausibles y técnicamente reales)

Incidente #1: La suposición equivocada (¿UEFI es “básicamente BIOS”, verdad?)

Una empresa mediana desplegó una nueva flota de portátiles para desarrolladores. El equipo de builds creó un USB interno “golden” con un instalador Linux. Arrancaba en el banco de pruebas, que consistía en unos escritorios más antiguos configurados en BIOS Legacy porque así siempre había sido el banco.

En los portátiles nuevos, el USB aparecía en el menú de arranque de una sola vez—dos veces, incluso: una como “UEFI: USB” y otra como “USB HDD”. Los técnicos eligieron la que sonaba familiar. “USB HDD” daba confianza. Se iniciaba en una pantalla negra y luego volvía al menú de arranque. Concluyeron que la imagen estaba mala.

Rehicieron el USB. Mismo resultado. Probaron con distintos sticks. Mismo resultado. El problema real: los portátiles estaban configurados para prohibir el arranque Legacy por completo. “USB HDD” era la ruta Legacy. La entrada UEFI funcionaba, pero solo si se seleccionaba. Nadie le había dicho al equipo de builds que la nueva flota era solo UEFI y con Secure Boot activado.

Una vez que seleccionaron “UEFI: USB”, el instalador cargó inmediatamente. La solución operativa fue: actualizar el runbook para instruir explícitamente a los técnicos a elegir la entrada UEFI y actualizar el proceso de imagen para verificar /sys/firmware/efi en el entorno live antes de continuar. La conclusión del postmortem no fue “la gente debería saberlo mejor”. Fue “enviamos un proceso que dependía del conocimiento tribal”.

Incidente #2: Una optimización que salió mal (NTFS por velocidad, UEFI por tristeza)

Otra organización construyó USBs instaladores de Windows para un programa de renovación interna. Alguien notó que escribir una unidad FAT32 era más lento y a veces fallaba cuando install.wim superaba 4 GiB. La “optimización” fue formatear el USB como NTFS y copiar los archivos, porque NTFS maneja archivos grandes y copiar es más rápido que escribir una imagen.

Funcionó en la mayoría de escritorios. Luego llegó a un lote de máquinas de factor de forma pequeño con firmware que se negaba a arrancar UEFI desde NTFS en medios removibles. El menú de arranque aún listaba la unidad, pero al seleccionarla simplemente volvía al menú. Los técnicos culparon al lote de hardware y abrieron un caso con el proveedor.

La respuesta del proveedor fue aburrida: “El firmware UEFI solo está obligado a soportar FAT para arranque desde medios removibles.” El soporte NTFS es opcional. Sus dispositivos no lo implementaban. La “optimización” fue efectivamente una regresión de compatibilidad. La flota ahora tenía dos clases de hardware, y el USB funcionaba en una clase.

La solución también fue aburrida: volver a FAT32 y dividir el WIM, o usar una herramienta que construya una unidad de dos particiones (una pequeña ESP FAT32 para el arranque + partición NTFS para archivos grandes) con un cargador que lea NTFS. La lección del postmortem: las optimizaciones de velocidad que cambian el sistema de ficheros no son optimizaciones; son decisiones de producto con radio de impacto.

Incidente #3: La práctica aburrida que salvó el día (checksums y un stick conocido-good)

Un equipo de servicios financieros mantuvo un kit USB “break-glass” para recuperación de servidores. El kit incluía un ISO de rescate Linux verificado y dos modelos específicos de stick USB comprados al por mayor. El runbook requería verificar el hash del ISO, luego escribir la imagen en bruto y después verificar el primer MiB con cmp.

Parecía ceremonia. Lo era. Y funcionó.

Durante una caída fea, necesitaban arrancar una máquina con el cargador corrupto tras un reemplazo de disco fallido. El primer USB que cogieron no arrancó. En lugar de entrar en pánico, el de guardia siguió el runbook: comprobaron la disposición del stick, confirmaron modo UEFI y probaron el stick en un segundo host. También falló allí.

Pasaron al segundo stick—mismo ISO, mismo procedimiento—y arrancó inmediatamente. El primer stick fallaba físicamente. Porque tenían pasos de verificación deterministas y un modelo conocido-bueno de repuesto, no perdieron una hora reinventando culpables. Restauraron el cargador y cerraron el incidente. La lección no era sexy: redundancia y verificación en lo “simple” reduce el MTTR como nada más.

Guion de diagnóstico rápido

Este es el orden que encuentra el cuello de botella rápidamente. No improvises. Sigue la cadena desde “puede el firmware verlo” hasta “puede ejecutarlo” hasta “puede continuar el cargador”.

Primero: confirma el modo y la política de arranque de la máquina

• Revisa la configuración del firmware: ¿Está deshabilitado el arranque Legacy? ¿Está habilitado Secure Boot? ¿Se permite arranque USB?
• En el menú de arranque: ¿ves entradas separadas para UEFI vs Legacy para el mismo stick?
• Decisión: Si el entorno es solo UEFI, deja de intentar medios Legacy. Si Secure Boot está aplicado, deja de intentar cargadores no firmados.

Segundo: confirma que el USB se escribió correctamente (no “copiado” incorrectamente)

• Verifica la suma del ISO.
• Confirma la disposición del stick con lsblk y fdisk -l.
• Confirma la presencia de \EFI\BOOT\BOOTX64.EFI para arranque UEFI.
• Decisión: Si la disposición es incorrecta, recrea el stick usando el método apropiado para ese ISO.

Tercero: determina en qué clase de fallo estás

• USB no listado en absoluto: hardware/puerto, arranque USB deshabilitado en firmware, stick muerto.
• USB listado pero vuelve al menú: rechazo por Secure Boot, EFI de arquitectura incorrecta, falta la ruta de fallback, firmware no puede leer el sistema de ficheros.
• El cargador inicia y luego da error: escritura corrupta, archivos faltantes, desajuste kernel/initrd, mala configuración, ISO corrupto.
• El instalador inicia pero no ve discos: controladores de almacenamiento, modo RAID/HBA, VMD, RST o configuraciones del controlador—no es un problema del USB.

Cuarto: valida desde un entorno live que funcione

• Confirma el modo con /sys/firmware/efi.
• Revisa el estado de Secure Boot con mokutil.
• Inspecciona entradas UEFI con efibootmgr (si está instalado).
• Decisión: Si tu modo no es el que crees, arregla eso antes de cualquier otra cosa.

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

1) Síntoma: el USB no aparece en el menú de arranque

Causa raíz: Arranque USB deshabilitado, puerto malo (los hubs frontales pueden fallar), stick muerto o el firmware solo enumera USB al arranque en frío.

Solución: Habilita arranque USB en el firmware; prueba un puerto trasero de la placa; prueba un puerto USB 2.0 si está disponible (algunos firmwares fallan al inicializar USB 3.x); realiza un ciclo completo de energía; prueba el stick en otro host.

2) Síntoma: el USB aparece, pero al seleccionarlo vuelve inmediatamente al menú

Causa raíz: Rechazo por Secure Boot, falta de BOOTX64.EFI, arquitectura EFI equivocada (x86_64 vs ARM64), o UEFI no puede leer el sistema de ficheros (NTFS/exFAT).

Solución: Usa FAT32 para la ESP; asegúrate de que \EFI\BOOT\BOOTX64.EFI exista; usa una cadena firmada o desactiva Secure Boot (si está permitido); asegúrate de tener el ISO correcto para la arquitectura del hardware.

3) Síntoma: arranca en una máquina, no en otra

Causa raíz: Una arranca en modo Legacy, la otra en UEFI; o una aplica Secure Boot; o un firmware soporta arranque desde NTFS y el otro no.

Solución: Estandariza en arranque UEFI y ESP FAT32 con ruta de fallback; documenta qué entrada del menú de arranque seleccionar; evita suposiciones de arranque UEFI solo con NTFS.

4) Síntoma: GRUB inicia, luego “unknown filesystem” o “file not found”

Causa raíz: Escritura parcial, stick defectuoso o la configuración de GRUB apunta al UUID/dispositivo equivocado porque la disposición del medio difiere.

Solución: Re-crea el stick con escritura en bruto; verifica con cmp; reemplaza hardware sospechoso; evita “remixar manualmente” contenidos del ISO a menos que entiendas la configuración del cargador.

5) Síntoma: el USB instalador de Windows arranca en Legacy pero no en UEFI

Causa raíz: Stick formateado NTFS sin ESP FAT32; el firmware requiere FAT32 para arrancar UEFI desde medios removibles.

Solución: Construye el medio Windows con una partición de arranque FAT32; si los archivos superan 4 GiB, divide el WIM o usa un enfoque de dos particiones con FAT32 para el arranque.

6) Síntoma: el instalador arranca, pero el disco objetivo no es visible

Causa raíz: Modo del controlador de almacenamiento (RAID/VMD/RST), controlador faltante o NVMe detrás de una abstracción del proveedor.

Solución: Ajusta el modo de almacenamiento en BIOS (AHCI vs RAID) según sea necesario; carga el controlador del proveedor en el instalador; actualiza el firmware; valida con lspci y lsblk en el entorno live. Esto no se soluciona reescribiendo el USB cinco veces.

Listas de verificación / plan paso a paso

Plan A: Crear un USB instalador Linux que arranque UEFI de forma fiable (recomendado)

1. Descargar el ISO y el valor de checksum proporcionado por el proveedor.
2. Verificar checksum con sha256sum. Si no coincide: volver a descargar.
3. Identificar el dispositivo USB con lsblk. Confirma que es removible y que el tamaño coincide.
4. Desmontar particiones en ese dispositivo.
5. Escribir el ISO en bruto con dd usando conv=fsync.
6. Volver a leer particiones con partprobe y confirmar la disposición.
7. Confirmar que existe el archivo de arranque UEFI: monta la partición FAT y comprueba \EFI\BOOT\BOOTX64.EFI.
8. Probar en dos máquinas: una moderna solo UEFI y otra más antigua en modo mixto. Anota qué entrada del menú de arranque funciona.

Plan B: Construir un USB de arranque UEFI personalizado (para medios de rescate o herramientas internas)

1. Empieza con un modelo USB conocido-bueno. Compra varios. En serio.
2. wipefs -a el dispositivo para quitar firmas conflictivas.
3. Crear GPT y luego una partición ESP FAT32 (al menos 512 MiB; prefiero 1 GiB por conveniencia).
4. Coloca tu binario EFI en \EFI\BOOT\BOOTX64.EFI.
5. Si Secure Boot está habilitado en tu entorno, asegúrate de que el binario EFI esté firmado apropiadamente o proporciona una cadena shim firmada.
6. Valida desde un host de prueba usando efibootmgr -v y seleccionando “UEFI: USB” en el menú de arranque de una sola vez.

Plan C: Soportar UEFI y Legacy sin dramas

1. Prefiere ISOs híbridos del proveedor que explícitamente soporten ambos modos.
2. Si debes personalizar: crea sticks separados para UEFI y Legacy, etiquétalos físicamente y deja de fingir que uno sirve para todos los casos límite del firmware.
3. Documenta qué modo se requiere para instalar la imagen que distribuyes (se recomienda UEFI). Hazlo cumplir en la lista de instalación.

Higiene operativa (lo aburrido)

• Mantén un USB “conocido-bueno” sellado como control.
• Mantén hashes en tu runbook interno para imágenes aprobadas.
• Registra las configuraciones de firmware requeridas (política de Secure Boot, política Legacy, modo SATA/RAID).
• Al depurar, cambia una variable a la vez. El universo castiga las conjeturas paralelas.

Preguntas frecuentes

1) ¿Por qué escribir un ISO en bruto a veces crea múltiples particiones?

Porque muchos ISOs de instalador son imágenes “híbridas” que incluyen tablas de particiones (a menudo MBR, a veces GPT). Cuando se escriben en un disco, el SO ve esas particiones.

2) ¿Por qué no puedo simplemente copiar el archivo ISO en un USB y arrancarlo?

El firmware normalmente no arranca desde un archivo ISO sentado en un sistema de ficheros aleatorio. Arranca mediante sectores de arranque (Legacy) o ejecutables EFI en un sistema FAT (UEFI). Las herramientas multiboot añaden un cargador que entiende ISOs; el firmware simple normalmente no.

3) ¿GPT o MBR para un USB arrancable?

Para UEFI, GPT con una ESP es limpio y predecible. Para BIOS Legacy, MBR importa. Los ISOs híbridos de Linux suelen usar MBR porque es ampliamente compatible. Si construyes medios personalizados para flotas modernas, GPT + ESP FAT32 suele ser la opción por defecto correcta.

4) Mi USB es FAT32 pero aún no arranca en UEFI. ¿Por qué?

Razones comunes: falta \EFI\BOOT\BOOTX64.EFI, arquitectura equivocada (ARM vs x86_64), Secure Boot rechazando el binario, o firmware defectuoso que necesita que el stick esté insertado antes del encendido.

5) Secure Boot está habilitado. ¿Tengo que desactivarlo para arrancar instaladores Linux?

No necesariamente. Muchos instaladores mainstream incluyen un shim firmado y cargador firmado que funcionan con Secure Boot. Los binarios EFI personalizados a menudo no funcionarán a menos que los firmes y el firmware confíe en la clave de firma.

6) ¿Por qué el menú de arranque muestra dos entradas para el mismo USB?

Una es la ruta UEFI y otra es Legacy/CSM. Elige la que coincida con cómo pretendes instalar. Si quieres una instalación UEFI, selecciona la entrada etiquetada UEFI.

7) El instalador arranca, pero después de la instalación la máquina no arranca. ¿Es culpa del USB?

Generalmente no. Normalmente es una descoordinación del modo de instalación (instalado en Legacy sin configuración MBR adecuada, o instalado en UEFI sin una ESP), o problemas del orden de arranque/NVRAM del disco objetivo. Verifica si el instalador se ejecutó en modo UEFI y si el disco objetivo tiene una ESP.

8) ¿Por qué algunos métodos de creación de USB para Windows fallan en ciertos PCs?

UEFI está obligado a soportar FAT para arranque desde medios removibles, pero no está obligado a soportar NTFS. Un USB de Windows que dependa de arranque NTFS puede funcionar en algunos firmwares y fallar en otros.

9) ¿Es exFAT una buena opción para USB arrancables?

Para arranque UEFI: normalmente no. Muchas implementaciones de firmware no arrancan desde exFAT. Usa FAT32 para la partición de arranque.

10) ¿Cuál es la única mejor comprobación de cordura una vez que he escrito el USB?

Monta la ESP (o la partición FAT) y confirma que \EFI\BOOT\BOOTX64.EFI existe. Luego prueba el stick en una segunda máquina. Si solo funciona en un host, no has terminado.

Conclusión: siguientes pasos prácticos

Si quieres un USB arrancable que realmente arranque, deja de tratarlo como manualidades. Trátalo como un artefacto de despliegue. Verifica la entrada (checksum), usa el método de creación correcto según el tipo de ISO y confirma el contrato que el firmware espera: una disposición de particiones utilizable y una ruta de fallback UEFI válida.

Siguientes pasos que puedes hacer hoy:

• Elige un modelo de USB aprobado y compra un pequeño lote. Retira los sticks desconocidos.
• Estandariza en instalaciones UEFI salvo que tengas un requisito Legacy defendible.
• Añade tres comprobaciones a tu runbook: coincidencia de sha256sum, saneamiento con lsblk y presencia de \EFI\BOOT\BOOTX64.EFI.
• Cuando falle, sigue el guion de diagnóstico rápido en orden. El objetivo es aislar rápido, no inventar soluciones heroicas.

El mejor USB arrancable es el que probaste la semana pasada en dos máquinas distintas, no el que “hiciste una vez y guardaste en un cajón”. El firmware cambia. La gente cambia. Los cajones son eternos.