Proxmox “Disco no arrancable”: orden de arranque BIOS/UEFI, flags de disco y una ruta rápida de recuperación

Guía rápida de diagnóstico

Este es el orden para “detener la hemorragia”. No improvises. No empieces a reinstalar Proxmox como si fuera un portátil de 2009.

1) Confirma el modo del firmware y el orden de arranque (la discrepancia BIOS/UEFI es el mayor consumidor de tiempo)

• Si la máquina está en modo UEFI, necesitas una Partición del Sistema EFI (ESP), una entrada de arranque EFI en NVRAM y binarios EFI que funcionen.
• Si la máquina está en modo BIOS heredado, necesitas GRUB en el MBR (o una partición de arranque BIOS para GPT), y el disco debe estar marcado como arrancable de la forma que el firmware espera.

Decisión: elige un modo y mantente en él. Las configuraciones de arranque mixtas “funcionaban antes” hasta que dejaron de hacerlo, casi siempre después de un reinicio del firmware.

2) Confirma que el disco está detectado y que el correcto es el primero

El orden de arranque del firmware no es estable. Cambia un cable SATA o agrega un NVMe y de pronto tu disco de arranque se convierte en “el otro”.

Decisión: si el disco falta a nivel de hardware, detente. Esto no es un problema de GRUB.

3) Desde un medio de rescate, valida las particiones: ESP/bios_grub, raíz y lo que Proxmox realmente instaló

No adivines. Inspecciona tablas de particiones, flags y sistemas de archivos. Si usas ZFS, confirma que el pool se importa.

Decisión: si falta la ESP o no está montada, repárala/restáurala. Si el pool ZFS no se importa, el trabajo del gestor de arranque es irrelevante hasta que el almacenamiento esté sano.

4) Repara el gestor de arranque y las entradas EFI (el cambio mínimo que te devuelve el servicio)

• UEFI: monta la ESP, reinstala los componentes EFI, recrea las entradas NVRAM con efibootmgr si es necesario.
• BIOS: reinstala GRUB en el disco correcto y regenera la configuración.

Decisión: no reinstales Proxmox a menos que tu partición del sistema operativo esté realmente perdida o irrecuperablemente corrupta.

5) Haz el arranque redundante (para que no sea una reunión recurrente)

Las entradas UEFI y las ESP pueden ser puntos únicos de fallo incluso en espejos ZFS. Arregla eso después de que el nodo arranque, no antes.

Una idea parafraseada frecuentemente citada en círculos SRE: “La esperanza no es una estrategia”. Usa listas de verificación, no vibras.

Qué significa realmente “not a bootable disk”

El mensaje es una queja del firmware, no de Proxmox. Significa que el firmware intentó sus objetivos de arranque configurados y no pudo encontrar algo que considere arrancable.

Dónde falla en la cadena

1. Detección de hardware: ¿ve el firmware el disco en absoluto?
2. Selección de arranque del firmware: ¿está intentando el disco correcto y el modo correcto (UEFI vs legado)?
3. Ubicación del código de arranque:
   • Legacy BIOS: MBR/sector de arranque → GRUB stage1 → imagen core de GRUB → /boot/grub
   • UEFI: entrada NVRAM → ESP FAT32 → binario EFI (shim/grub/systemd-boot) → kernel/initramfs
4. Entrega al SO: el kernel monta el sistema de archivos raíz; en ZFS puede importar el pool temprano.

La mayoría de los incidentes “no arrancable” en Proxmox son uno de estos:

• El firmware se restableció silenciosamente a los valores por defecto (a menudo cambiando el comportamiento UEFI/legacy).
• El orden de arranque cambió tras añadir/quitar discos.
• La ESP fue sobreescrita, no montada, o creada solo en un disco del espejo.
• GRUB se instaló en el dispositivo equivocado (común tras reemplazar un disco).
• Las entradas NVRAM UEFI se borraron (actualización de firmware, reinicio del CMOS, algunas travesuras de gestión remota).

Broma #1: El orden de arranque del firmware es como la asignación de asientos en la oficina: puedes ser “el importante” hasta que Mantenimiento mueva una planta.

Datos interesantes y contexto histórico (porque el pasado sigue rompiendo tu presente)

• El BIOS es anterior a tu carrera: las convenciones del BIOS del IBM PC datan de los años 80, y gran parte de la “magia de arranque” sigue siendo cinta adhesiva para compatibilidad hacia atrás.
• UEFI fue diseñado para reemplazar BIOS: formalizó el arranque como la carga de binarios EFI desde un sistema de archivos FAT, no desde sectores de arranque opacos.
• GPT vs MBR no es solo número de particiones: GPT empareja naturalmente con UEFI, mientras que el arranque BIOS desde GPT necesita una partición dedicada “bios_grub” para GRUB.
• La ESP es solo FAT32: tu “host de virtualización de alta disponibilidad” a menudo arranca desde un sistema de archivos diseñado para cámaras y pendrives.
• Las entradas NVRAM son frágiles: las actualizaciones de firmware, reinicios de CMOS y a veces eventos de energía pueden borrarlas, aun cuando los discos estén perfectos.
• Secure Boot cambió expectativas: las máquinas cada vez más inician por defecto con Secure Boot activado; despliegues de Proxmox suelen desactivarlo salvo que gestiones cadenas de arranque firmadas.
• Los gestores de arranque de Linux evolucionaron: LILO dio paso a GRUB, luego a GRUB2; cada uno mejoró flexibilidad añadiendo nuevas formas de malconfigurar un entorno de arranque.
• El arranque con ZFS está “soportado”, no “simplificado”: ZFS añade fiabilidad para los datos, pero el arranque sigue dependiendo de piezas diminutas no ZFS: ESPs, GRUB, módulos initramfs.
• Los nombres de dispositivo no son estables: /dev/sda hoy puede ser /dev/sdb mañana tras cambios en el HBA; la práctica moderna usa rutas by-id por una razón.

Tareas prácticas: comandos, qué significa la salida y la decisión que tomas

Estas son tareas de campo que puedes ejecutar desde un shell de Proxmox, un ISO live de Debian o el instalador de Proxmox en modo rescate (cuando esté disponible). El objetivo es pasar de “no arranca” a “sé exactamente qué capa falló”.

Task 1: Confirmar si arrancaste el entorno de rescate en modo UEFI o BIOS

cr0x@server:~$ [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
UEFI

Significado: Si esto imprime UEFI, tu sesión de rescate es UEFI. Eso debe coincidir con cómo pretendes que arranque el nodo.

Decisión: Si la máquina antes arrancaba en BIOS heredado y ahora estás en UEFI (o viceversa), arregla la configuración del firmware antes de tocar discos.

Task 2: Ver qué discos puede ver el OS (chequeo de hardware)

cr0x@server:~$ lsblk -e7 -o NAME,SIZE,MODEL,SERIAL,TYPE,FSTYPE,MOUNTPOINTS
NAME      SIZE MODEL            SERIAL           TYPE FSTYPE MOUNTPOINTS
sda     447.1G INTEL SSDSC2KB   BTWL1234567      disk
├─sda1    512M                  -                part vfat
├─sda2   1007K                  -                part
└─sda3  446.6G                  -                part zfs_member
sdb     447.1G INTEL SSDSC2KB   BTWL7654321      disk
├─sdb1    512M                  -                part vfat
├─sdb2   1007K                  -                part
└─sdb3  446.6G                  -                part zfs_member

Significado: Los discos son visibles, existen particiones y ya puedes identificar una ESP (vfat) y miembros ZFS.

Decisión: Si tu disco de arranque no aparece en la lista, detente y arregla cableado/HBA/detección en BIOS. El trabajo del gestor de arranque no convocará hardware faltante.

Task 3: Identificar cómo está particionado el disco (GPT vs MBR) y si existe una ESP

cr0x@server:~$ parted -l
Model: ATA INTEL SSDSC2KB (scsi)
Disk /dev/sda: 480GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End    Size   File system  Name  Flags
 1      1049kB  538MB  537MB  fat32              boot, esp
 2      538MB   539MB  1049kB                   bios_grub
 3      539MB   480GB  479GB

Model: ATA INTEL SSDSC2KB (scsi)
Disk /dev/sdb: 480GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End    Size   File system  Name  Flags
 1      1049kB  538MB  537MB  fat32              boot, esp
 2      538MB   539MB  1049kB                   bios_grub
 3      539MB   480GB  479GB

Significado: Discos GPT con esp y bios_grub son comunes en instalaciones de Proxmox que buscan flexibilidad. El flag ESP es la parte importante para el arranque UEFI.

Decisión: Si no hay ESP (boot, esp) pero el servidor está en modo UEFI, has encontrado la discrepancia.

Task 4: Comprobar integridad del sistema de archivos de la ESP (es FAT; trátalo como si fuera 1998)

cr0x@server:~$ fsck.vfat -n /dev/sda1
fsck.fat 4.2 (2021-01-31)
/dev/sda1: 12 files, 1646/130560 clusters

Significado: La comprobación en solo lectura pasó; no hay corrupción FAT obvia.

Decisión: Si ves errores FAT, planea reparar (-a) o recrear la ESP e instalar de nuevo los archivos EFI.

Task 5: Montar la ESP y verificar que existan binarios EFI

cr0x@server:~$ mkdir -p /mnt/esp && mount /dev/sda1 /mnt/esp && find /mnt/esp/EFI -maxdepth 2 -type f | sed -n '1,10p'
/mnt/esp/EFI/BOOT/BOOTX64.EFI
/mnt/esp/EFI/proxmox/grubx64.efi
/mnt/esp/EFI/debian/grubx64.efi

Significado: Hay archivos; existe la ruta de reserva EFI/BOOT/BOOTX64.EFI y rutas de proveedor.

Decisión: Si /mnt/esp/EFI está vacío o falta, reinstala el gestor de arranque y considera crear la ruta de reserva.

Task 6: Inspeccionar las entradas NVRAM UEFI (la “lista de marcadores” del firmware)

cr0x@server:~$ efibootmgr -v
BootCurrent: 0002
Timeout: 2 seconds
BootOrder: 0002,0001,0000
Boot0000* UEFI: PXE IPv4 Intel(R) I350
Boot0001* UEFI: Built-in EFI Shell
Boot0002* proxmox	HD(1,GPT,2b0c3f1a-9b2f-4a7e-9d64-3f3c3a0e2f21,0x800,0x100000)/File(\EFI\proxmox\grubx64.efi)

Significado: Hay una entrada Proxmox y es la primera. Perfecto—salvo que apunte al UUID de partición de un disco equivocado.

Decisión: Si no existe una entrada Proxmox, o apunta a un disco muerto, recréala con efibootmgr tras verificar la ESP correcta.

Task 7: Importar el pool ZFS desde rescate y confirmar que está sano para arrancar

cr0x@server:~$ zpool import
   pool: rpool
     id: 1234567890123456789
  state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

	rpool        ONLINE
	  mirror-0    ONLINE
	    sda3      ONLINE
	    sdb3      ONLINE

Significado: El pool root existe y es importable.

Decisión: Si el pool está DEGRADED, a menudo aún puedes arrancar, pero debes aprovechar la reparación del arranque para restaurar la redundancia también.

Task 8: Montar el sistema instalado y preparar un chroot para reparar

cr0x@server:~$ zpool import -R /mnt rpool
cr0x@server:~$ zfs mount -a
cr0x@server:~$ mount | grep -E '(/mnt|rpool)' | sed -n '1,8p'
rpool/ROOT/pve-1 on /mnt type zfs (rw,relatime,xattr,posixacl)
rpool/data on /mnt/rpool/data type zfs (rw,relatime,xattr,posixacl)

Significado: Tu dataset raíz está montado en /mnt.

Decisión: Si los montajes fallan, no procedas a reinstalar GRUB. Arregla la importación/montaje de ZFS primero.

Task 9: Bind-montar sistemas de tiempo de ejecución y chroot

cr0x@server:~$ for i in /dev /dev/pts /proc /sys /run; do mount --bind $i /mnt$i; done
cr0x@server:~$ chroot /mnt /bin/bash
root@server:/# cat /etc/os-release | head -2
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"

Significado: Estás dentro del entorno del sistema instalado; las herramientas de arranque se comportarán correctamente.

Decisión: Si chroot falla por binarios faltantes, tu sistema raíz no es lo que crees que es.

Task 10 (UEFI): Asegurar que la ESP esté montada en /boot/efi y reinstalar GRUB EFI

root@server:/# mkdir -p /boot/efi
root@server:/# mount /dev/sda1 /boot/efi
root@server:/# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=proxmox
Installing for x86_64-efi platform.
Installation finished. No error reported.

Significado: Los binarios GRUB EFI se instalaron en la ESP bajo la etiqueta proxmox.

Decisión: Si esto da error sobre “EFI variables not supported”, probablemente arrancaste el entorno de rescate en modo BIOS. Reinicia el rescate en UEFI.

Task 11 (UEFI): Regenerar el menú GRUB y el initramfs

root@server:/# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.12-2-pve
Found initrd image: /boot/initrd.img-6.8.12-2-pve
done
root@server:/# update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-6.8.12-2-pve

Significado: El menú de arranque apunta a kernels reales; el initramfs se reconstruyó.

Decisión: Si no se encuentran kernels, puede que estés chrooteado en el dataset raíz equivocado o que /boot no esté montado correctamente.

Task 12 (UEFI): Recrear una entrada NVRAM faltante

root@server:/# efibootmgr -c -d /dev/sda -p 1 -L "proxmox" -l '\EFI\proxmox\grubx64.efi'
BootCurrent: 0002
BootOrder: 0002,0001,0000,0003
Boot0003* proxmox	HD(1,GPT,2b0c3f1a-9b2f-4a7e-9d64-3f3c3a0e2f21,0x800,0x100000)/File(\EFI\proxmox\grubx64.efi)

Significado: Creaste una nueva entrada. Puede que aún no sea la primera.

Decisión: Ajusta BootOrder para que proxmox sea la primera, o confía en el cargador de reserva como cinturón y tirantes.

Task 13 (BIOS): Reinstalar GRUB en el MBR del disco (o área de arranque BIOS)

root@server:/# grub-install /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.
root@server:/# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.12-2-pve
Found initrd image: /boot/initrd.img-6.8.12-2-pve
done

Significado: GRUB legacy instalado en /dev/sda.

Decisión: Si estás en un espejo, instala GRUB en cada disco miembro desde el que puedas arrancar.

Task 14: Verificar que GRUB vea la raíz correcta y no haga referencia a nombres /dev/sdX

root@server:/# grep -R "root=" /boot/grub/grub.cfg | sed -n '1,5p'
linux	/boot/vmlinuz-6.8.12-2-pve root=ZFS=rpool/ROOT/pve-1 ro quiet

Significado: La raíz se referencia mediante dataset ZFS, no por rutas de disco inestables.

Decisión: Si ves root=/dev/sda3 en sistemas donde los nombres pueden cambiar, corrige /etc/default/grub y regenera.

Task 15: Construir una ruta EFI de reserva (porque la NVRAM no es de fiar)

root@server:/# mkdir -p /boot/efi/EFI/BOOT
root@server:/# cp -f /boot/efi/EFI/proxmox/grubx64.efi /boot/efi/EFI/BOOT/BOOTX64.EFI
root@server:/# ls -l /boot/efi/EFI/BOOT/BOOTX64.EFI
-rwx------ 1 root root 1536000 Dec 26 11:11 /boot/efi/EFI/BOOT/BOOTX64.EFI

Significado: Incluso si el firmware olvida las entradas NVRAM, a menudo puede arrancar la ruta por defecto.

Decisión: Haz esto en cada ESP desde la que esperes arrancar.

Task 16: Después del reinicio, confirma que el sistema realmente arrancó en el modo previsto

cr0x@server:~$ dmesg | grep -i "efi\|UEFI" | sed -n '1,6p'
[    0.000000] efi: EFI v2.70 by American Megatrends
[    0.000000] efi: ACPI=0x9bfe6000 ACPI 2.0=0x9bfe6014 SMBIOS=0x9c01c000

Significado: El kernel ve EFI; estás en arranque UEFI.

Decisión: Si querías arranque legado y ves EFI, has vuelto a “modo mixto”; arréglalo antes de la próxima ventana de mantenimiento que te vuelva a sorprender.

UEFI vs BIOS: elegir la vía de recuperación adecuada

La regla más simple

Si la máquina es capaz de UEFI (la mayoría lo es), prefiere UEFI en instalaciones nuevas. Pero no “conviertas” en un incidente en vivo a menos que disfrutes del tiempo de inactividad sorpresa. Recupera en el modo en que se instaló y luego planifica una migración controlada si hace falta.

Cómo suele disponer Proxmox las cosas

Proxmox VE se basa en Debian. El instalador creará particiones para:

• ESP (habitualmente 512MB FAT32) cuando se usa UEFI.
• bios_grub partición diminuta (alrededor de 1MB) cuando se arranca en BIOS desde GPT, para que GRUB tenga dónde incrustar.
• Sistema raíz en ext4, LVM o ZFS (común en configuraciones modernas de Proxmox).

Modos de fallo UEFI que parecen “disco no arrancable”

• ESP existe pero no se usa: el orden de arranque apunta a PXE o algún “UEFI: USB” por encima de tu disco.
• Entrada NVRAM faltante: el firmware olvidó tu entrada de arranque Proxmox. El disco está bien; la memoria del firmware no.
• Ruta de disco errónea en NVRAM: reemplazaste un disco del espejo y la entrada de arranque sigue señalando el UUID GPT del disco antiguo.
• ESP solo en un disco: el espejo ZFS mantiene tus datos seguros, pero aún tienes una sola ESP. Pierde ese disco y pierdes el arranque.

Modos de fallo BIOS que parecen “disco no arrancable”

• GRUB instalado en el disco equivocado: el sistema arranca por el primer disco en el orden del BIOS, pero GRUB está en el segundo.
• MBR sobrescrito: una operación de clonación, un instalador o una herramienta “útil” del proveedor pisó el sector de arranque.
• GPT sin bios_grub: GRUB legacy no puede incrustar su imagen core correctamente.

Broma #2: El BIOS no te odia. Solo expresa amor ignorando tus últimos tres cambios de configuración.

Proxmox + ZFS: dónde la redundancia de arranque ayuda y dónde no

ZFS hace el almacenamiento raíz robusto. No hace que el arranque sea automáticamente robusto. Tu espejo ZFS puede seguir sirviendo bloques perfectos mientras el firmware mira una lista NVRAM vacía como si nunca hubiera conocido tu servidor.

Qué protege ZFS

• Datasets raíz, discos de VM almacenados en el pool, coherencia de metadatos y detección de corrupción silenciosa.
• Recuperación operativa: reemplaza un disco fallado, resilveriza, sigue funcionando.

Qué no protege ZFS

• La ESP, a menos que crees ESPs en múltiples discos y las mantengas sincronizadas.
• Las entradas NVRAM UEFI, porque viven en el firmware, no en disco.
• El orden de arranque del firmware, porque es una configuración del firmware y puede restablecerse en el peor momento.

Qué deberías hacer en discos de arranque espejados

Si tienes dos discos y esperas sobrevivir perdiendo cualquiera de ellos, necesitas dos rutas de arranque:

• Dos ESPs (una por disco) y un plan para mantenerlas consistentes.
• Entradas UEFI para ambos, o un cargador de reserva robusto en EFI/BOOT/BOOTX64.EFI en ambos.
• Si arrancas en BIOS legado: GRUB instalado en ambos discos.

En entornos Proxmox, el enfoque pragmático y aburrido es: ESP por disco + cargador de reserva + chequeos periódicos de deriva. Lo elegante es opcional.

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

1) Síntoma: “No bootable device” después de una actualización de firmware

Causa raíz: Las entradas NVRAM UEFI se borraron o reordenaron; PXE o “UEFI Shell” quedaron por delante.

Solución: Usa la configuración del firmware para seleccionar la entrada UEFI correcta. Si falta, recréala con efibootmgr desde rescate y copia el BOOTX64.EFI de reserva.

2) Síntoma: Arranca solo cuando está presente un disco específico (existe espejo, pero un disco es “especial”)

Causa raíz: Solo un disco tiene ESP o solo un disco tiene GRUB instalado.

Solución: Crea ESP en el otro disco, móntala, instala GRUB EFI en ella (o GRUB BIOS en el disco), y agrega la ruta de reserva.

3) Síntoma: “EFI variables are not supported” durante la reparación

Causa raíz: Arrancaste el entorno de rescate en modo BIOS, así que efivars no están disponibles.

Solución: Reinicia el instalador/ISO live en modo UEFI y repite la instalación de GRUB EFI.

4) Síntoma: GRUB carga y luego cae a “grub rescue>”

Causa raíz: GRUB no encuentra sus módulos o configuración debido a particiones movidas, UUIDs cambiados o /boot donde no esperaba.

Solución: Desde rescate, chroot y vuelve a ejecutar grub-install + update-grub. Verifica /etc/fstab y que la ESP se monte correctamente.

5) Síntoma: “Not a bootable disk” justo después de añadir un disco nuevo

Causa raíz: El orden de arranque cambió; el firmware ahora intenta el disco nuevo primero. Algunos HBA también reordenan discos.

Solución: Reordena los objetivos de arranque; deshabilita el arranque desde discos no-OS si el firmware lo permite.

6) Síntoma: Funciona tras selección manual de arranque, falla en el siguiente reinicio

Causa raíz: El firmware guarda una anulación de un solo arranque pero no el orden permanente; o tu configuración permanente no se guarda por problemas con la pila CMOS.

Solución: Establece un orden de arranque persistente; revisa los logs del BIOS; cambia la pila CMOS si la configuración se desvanece.

7) Síntoma: Tras reemplazar un disco, el sistema no arranca pero el pool ZFS parece bien

Causa raíz: El disco nuevo carece de ESP/bootloader, o la entrada NVRAM apunta al GUID de partición del disco antiguo.

Solución: Particiona el disco nuevo apropiadamente, crea ESP, instala GRUB, actualiza las entradas efiboot y añade el cargador de reserva.

8) Síntoma: Quejas de Secure Boot o “invalid signature”

Causa raíz: Secure Boot activado pero tu cadena de arranque no está firmada de la forma que el firmware acepta.

Solución: Desactiva Secure Boot para despliegues típicos de Proxmox salvo que tengas un flujo firmado y probado.

Listas de verificación / plan paso a paso

Checklist A: Qué recopilar antes de empezar a cambiar cosas

1. ¿El nodo se instaló en modo UEFI o BIOS?
2. ¿Cambió algo? ¿Actualización de firmware, reemplazo de disco, nuevo HBA, movimiento de cables, evento de energía, manos remotas?
3. ¿Hay acceso a consola (iKVM/IDRAC/iLO) o solo SSH (probablemente no tienes SSH)?
4. ¿Cuál es el layout de almacenamiento: espejo ZFS, RAIDZ ZFS, ext4, LVM-thin?
5. ¿Qué disco debe ser arrancable? Identifícalo por número de serie, no por /dev/sdX.

Checklist B: Recuperación mínima (UEFI)

1. Arranca el medio de rescate en modo UEFI.
2. Confirma que los discos son visibles con lsblk.
3. Verifica que la ESP exista y sea FAT32 con parted -l.
4. Importa el pool ZFS (si aplica) y monta raíz en /mnt.
5. Bind-monta /dev, /proc, /sys, /run y haz chroot.
6. Monta la ESP en /boot/efi.
7. Ejecuta grub-install --target=x86_64-efi y update-grub.
8. Crea/verifica la entrada NVRAM con efibootmgr.
9. Copia el cargador de reserva a EFI/BOOT/BOOTX64.EFI.
10. Reinicia y verifica el modo de arranque vía dmesg.

Checklist C: Recuperación mínima (BIOS heredado)

1. Arranca el medio de rescate (el modo importa menos, pero sé consistente).
2. Confirma presencia de discos y particionado; si es GPT, asegúrate de que exista bios_grub.
3. Monta el sistema raíz (o importa ZFS) y chroot.
4. Ejecuta grub-install /dev/sdX en el disco correcto.
5. Ejecuta update-grub.
6. Si está espejado, repite grub-install en los otros discos.
7. Configura el orden de arranque del BIOS hacia un disco que realmente tenga GRUB.

Checklist D: Endurecimiento posterior a la recuperación (hazlo mientras aún recuerdas el dolor)

1. Haz redundantes las ESPs en discos espejados.
2. Anota el modo de firmware y las configuraciones BIOS requeridas en runbooks.
3. Deshabilita el arranque desde discos de datos y medios removibles aleatorios en el firmware.
4. Después de cualquier reemplazo de disco, reinstala el gestor de arranque en el disco nuevo como parte del procedimiento.
5. Añade una tarea periódica de “auditoría de cadena de arranque” (contenido ESP + salida de efibootmgr + estado de grub-install).

Tres micro-historias corporativas desde las trincheras de fallos de arranque

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

Tenían un clúster Proxmox donde cada nodo era “idéntico”. Identical es una palabra peligrosa en producción porque hace que la gente deje de mirar. Un nodo se negó a arrancar tras un apagado planificado: “not a bootable disk”. El responsable asumió fallo de disco y abrió ticket para reemplazo. Razonable, excepto que los discos estaban bien.

La causa real fue un reinicio del firmware durante mantenimiento. El servidor cambió de BIOS legado a UEFI-first, y el sistema instalado era legacy. Los discos eran GPT con una partición de arranque BIOS, y GRUB estaba correctamente instalado para i386-pc. Pero al firmware solo le importaban los binarios UEFI en una ESP que no existía.

La recuperación fue casi insultantemente simple: volver a poner el firmware en legacy, reiniciar y el nodo volvió. El “incidente” no era corrupción de almacenamiento ni una actualización del SO. Fue una descoincidencia de configuración creada por la suposición de que “UEFI está en todas partes”.

Lo que cambiaron después fue el proceso, no la tecnología. Añadieron un perfil de hardware de una página por nodo: modo de arranque, estado de Secure Boot, modo RAID/HBA y el serial del disco esperado de arranque. No fue glamuroso. También previno una repetición.

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

Otro equipo quiso arranques más rápidos tras actualizaciones de kernel. Recortaron lo que consideraron “artefactos extra” de arranque. La ESP se redujo a algo muy pequeño y eliminaron archivos EFI de reserva porque “ya tenemos una entrada NVRAM correcta”. También estandarizaron en una ESP única en el primer disco de un espejo ZFS, porque mantener dos les parecía “desperdicio”.

Entonces falló un disco. ZFS hizo su trabajo; el pool siguió en línea. Reemplazaron el disco, resilverizaron y planificaron un reinicio para validar todo. Al reiniciar, el firmware intentó arrancar desde el disco restante (ahora primero en los ojos del firmware) y no encontró una ruta EFI válida. La única ESP estaba en el disco retirado. La ruta de reserva había sido borrada durante la optimización.

El tiempo de inactividad no fue catastrófico, pero sí innecesario y molesto. La mayor parte del tiempo se gastó haciendo que manos remotas montaran medios y dieran acceso de consola, no arreglando software. La solución fue una estrategia de ESP espejo adecuada y reinstaurar el binario EFI de reserva.

La lección no fue “nunca optimizar”. Fue que la resiliencia de arranque es una propiedad del sistema, no de un disco. La redundancia ZFS no cubre la amnesia del firmware ni la falta de artefactos de arranque en el dispositivo sobreviviente.

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

Una empresa tenía la práctica, aparentemente excesiva, de reinstalar gestores de arranque y verificar ambas rutas de arranque tras cualquier reemplazo de disco en un host Proxmox. Siempre. Sin excepciones. Era el tipo de paso que hacía que la gente pusiera los ojos en blanco—hasta que pagó la renta.

Un fin de semana, un nodo perdió energía y luego se negó a arrancar. La consola mostraba al firmware escaneando unidades y rindiéndose. El responsable siguió el playbook: verificar modo UEFI, inspeccionar ESPs en ambos discos y comprobar efibootmgr. Las entradas NVRAM habían desaparecido, probablemente borradas por una peculiaridad del firmware durante la recuperación de energía.

Normalmente eso habría significado reconstruir entradas manualmente. Pero su práctica aburrida incluía copiar un cargador de reserva a EFI/BOOT/BOOTX64.EFI en ambas ESPs. El firmware, habiendo olvidado todo lo demás, todavía conocía la ruta por defecto. Arrancó sin que nadie tocara la NVRAM.

Restauraron las entradas de arranque después, pero el punto clave es que la recuperación fue rápida, sin acceso especial y sin conjeturas. No fue heroísmo. Fue disciplina rutinaria que hizo el sistema menos dramático.

Preguntas frecuentes

1) ¿“not a bootable disk” suele ser un disco muerto?

No. Los discos muertos ocurren, pero la realidad común es una discrepancia de orden o modo de arranque del firmware. Confirma detección del disco primero, luego el modo de arranque.

2) ¿Puedo arreglar esto reinstalando Proxmox?

Puedes, pero no deberías. Reinstalar es un instrumento contundente que puede borrar almacenamiento o romper expectativas de clúster. Repara el arranque primero; es más rápido y seguro si se hace con cuidado.

3) ¿Cómo sé si Proxmox se instaló en modo UEFI?

Si el sistema instalado tiene /sys/firmware/efi al ejecutarlo, arrancó vía UEFI. En disco, busca una ESP (FAT32, marcada esp).

4) ¿Por qué reemplazar un disco en un espejo ZFS rompe el arranque?

ZFS espeja tus particiones de datos, no automáticamente tu ESP o las entradas de arranque del firmware. Si la ESP o el gestor de arranque estaba solo en el disco retirado, el disco restante no arrancará por sí mismo.

5) ¿Necesito tanto una ESP como una partición bios_grub?

No siempre. UEFI necesita una ESP. El arranque BIOS legacy desde GPT se beneficia de una partición bios_grub. Algunos instaladores crean ambas para flexibilidad. La clave es: el modo de arranque activo debe tener sus piezas requeridas.

6) ¿Cuál es la acción más rápida para “simplemente arrancar algo” si las entradas NVRAM están rotas?

Crea la ruta de reserva EFI/BOOT/BOOTX64.EFI en la ESP. Muchas implementaciones de firmware la arrancarán incluso con NVRAM vacía.

7) ¿Debería activar Secure Boot en Proxmox?

Si no tienes una cadena de arranque firmada planificada y probada, Secure Boot tiende a generar fallos de arranque durante actualizaciones o reparaciones. Muchos despliegues de Proxmox lo desactivan deliberadamente.

8) ¿Por qué grub-install dice “EFI variables are not supported”?

Porque no estás arrancado en modo UEFI (o efivars no están disponibles). Arranca el medio de rescate en modo UEFI para que /sys/firmware/efi exista e inténtalo de nuevo.

9) ¿Necesito reinstalar GRUB tras cada actualización del kernel?

Normalmente no. Las actualizaciones del kernel regeneran la configuración de GRUB y el initramfs automáticamente. Reinstala GRUB cuando cambien discos, se reconstruyan ESPs o falten archivos del gestor de arranque.

10) ¿Puedo mantener las entradas de arranque estables ante cambios de hardware?

Algo de estabilidad viene de usar GUIDs de partición correctos y mantener ESPs consistentes, pero el comportamiento del firmware varía. Por eso los cargadores de reserva y las ESPs redundantes son prácticos.

Conclusión: próximos pasos prácticos

Si estás frente al mensaje “not a bootable disk”, trátalo como un incidente en el límite firmware/arranque, no como una invitación a reinstalar el SO. Empieza por modo y orden. Luego inspecciona particiones y contenido de ESP. Solo entonces reinstala GRUB o recrea entradas EFI. Esa secuencia evita los dos clásicos sumideros de tiempo: reparar la capa equivocada y “arreglar” un sistema para que arranque en un modo distinto sin quererlo.

Después de estar en línea, realiza el endurecimiento poco emocionante: haz redundantes las ESPs en discos espejados, copia un cargador EFI de reserva y documenta las configuraciones de firmware esperadas por nodo. El próximo reinicio debería ser aburrido. A producción le encanta lo aburrido.