Problema

En entornos de virtualización con Proxmox VE es frecuente que, después de aplicar actualizaciones del sistema o del firmware del host, el servidor deje de encontrar el disco de arranque y entre en un bucle de reinicio. El síntoma típico es “boot device not found” o “no bootable device” en la BIOS/UEFI, mientras que los discos siguen presentes y los volúmenes LVM aparecen intactos al iniciar desde un medio de rescate. El problema no se limita a un modelo de servidor concreto; cualquier nodo con discos pasados a través de PCIe, SSD de arranque y configuraciones EFI puede verse afectado.

Causa

Los fallos de arranque tras actualizaciones suelen deberse a una combinación de factores:

  1. Cambio inesperado del modo de arranque

    • Una actualización del kernel o del paquete pve-manager puede activar la firma de kernel (signed) y, si Secure Boot está habilitado, impedir que el loader sea aceptado.
    • Algunas BIOS/UEFI detectan la firma y cambian automáticamente a “UEFI only”, dejando sin efecto la entrada de arranque Legacy que apuntaba al disco SSD.

  2. Re‑generación de la tabla de particiones EFI

    • El instalador de Proxmox (ISO de rescate) a veces sobrescribe la partición ESP (/boot/efi) al crear una nueva entrada de arranque, especialmente si se desactiva Secure Boot manualmente.
    • Si la partición ESP está en un disco M.2 distinto al que contiene el root LVM, el firmware puede perder la referencia.

  3. LVM no activado en early boot

    • El initramfs incluye los módulos necesarios para montar volúmenes LVM. Un kernel nuevo que no incluya lvm2 o que tenga una versión de initramfs-tools desalineada puede fallar al activar los PV, dejando el root invisible.

  4. Actualización del firmware del controlador RAID/PCIe

    • En servidores Dell, una actualización del BIOS o del controlador PERC puede cambiar la enumeración de los discos, haciendo que la ruta de arranque (/dev/sda1) ya no coincida con la esperada.

  5. Conflicto entre discos pasados a Windows Storage Spaces y el host Proxmox

    • Si los discos están expuestos directamente a Windows y a Proxmox simultáneamente, una actualización de Windows puede alterar la tabla de particiones o los flags de arranque, provocando que el firmware ignore la partición ESP de Proxmox.

Solución

1. Verificar el estado de Secure Boot y del modo EFI

  • Accede al BIOS/UEFI y confirma que Secure Boot está deshabilitado.
  • Asegúrate de que el modo de arranque está en UEFI (no Legacy) y que la entrada de arranque apunta al archivo shimx64.efi o grubx64.efi del disco SSD de Proxmox.

2. Restaurar la entrada EFI manualmente

Desde un medio de rescate (ISO de Proxmox o cualquier live Linux con efibootmgr):

# Montar la partición ESP del SSD (asumiendo /dev/sda1)
mount /dev/sda1 /mnt
# Ver la estructura esperada
ls /mnt/EFI/Proxmox
# Crear o reparar la entrada EFI
efibootmgr --create --disk /dev/sda --part 1 \
  --label "Proxmox VE" --loader \\EFI\\Proxmox\\grubx64.efi
# Opcional: establecer como primera opción
efibootmgr --bootorder XXXX,YYYY

Reemplaza XXXX con el número que efibootmgr asignó a la nueva entrada.

3. Regenerar el initramfs con soporte LVM y EFI

Una vez arrancado en modo rescate, monta el root LVM y chroot:

vgchange -ay               # Activar todos los PV
mount /dev/mapper/pve-root /mnt
mount /dev/sda1 /mnt/boot/efi   # ESP
for d in proc sys dev; do mount --rbind /$d /mnt/$d; done
chroot /mnt
# Regenerar initramfs para el kernel activo
update-initramfs -c -k $(uname -r)
# Reinstalar GRUB en modo EFI
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Proxmox
update-grub
exit

Esto asegura que el initramfs incluya los módulos lvm2 y efivarfs, y que GRUB apunte a la ruta correcta.

4. Bloquear actualizaciones problemáticas (opcional)

Si la actualización que desencadenó el fallo es identificable (por ejemplo, pve-kernel-7.0.2-6-pve-signed), puedes marcarla como hold:

apt-mark hold pve-kernel-7.0.2-6-pve-signed

Posteriormente, prueba con la versión anterior (pve-kernel-7.0.2-2-pve-signed) para validar que el kernel es la causa.

5. Sincronizar la enumeración de discos

En servidores con controladores RAID o PCIe, verifica que los discos aparecen con los mismos IDs que antes de la actualización:

lsblk -o NAME,MODEL,SERIAL,SIZE,TYPE

Si cambian, actualiza /etc/fstab y los archivos de configuración de LVM (/etc/lvm/lvm.conf) para usar UUIDs en lugar de /dev/sdX.

6. Re‑activar el arranque después de cambios en Windows

Si los discos están compartidos con Windows, evita que Windows modifique la partición ESP de Proxmox. Una práctica segura es desconectar temporalmente los discos de Windows antes de aplicar actualizaciones de Proxmox, o usar discos dedicados para cada hipervisor.

Cuándo aplicar esta solución

  • Síntomas: el firmware indica “no boot device”, el nodo no aparece en la lista de clúster, pero los discos son visibles en la consola de rescate.
  • Entorno: Proxmox VE 9.x o superior, nodos con EFI, discos SSD para el OS y LVM para VMs/containers.
  • No aplica: fallos de arranque causados por corrupción del sistema de archivos raíz (/), errores de hardware físico (RAM/CPU) o pérdida total de energía del controlador RAID. En esos casos, la recuperación requiere reemplazo de hardware o restauración de backups.

Código

# 1. Activar volúmenes LVM y montar root
vgchange -ay
mount /dev/mapper/pve-root /mnt

# 2. Montar la partición EFI
mount /dev/sda1 /mnt/boot/efi

# 3. Preparar chroot
for d in proc sys dev; do mount --rbind /$d /mnt/$d; done
chroot /mnt

# 4. Regenerar initramfs y reinstalar GRUB
update-initramfs -c -k $(uname -r)
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Proxmox
update-grub

# 5. Salir y desmontar
exit
umount -R /mnt
reboot

Verificación

  1. BIOS/UEFI: la entrada “Proxmox VE” debe aparecer y estar en la posición de arranque primaria.
  2. POST: el nodo debe cargar el kernel y mostrar el prompt de login de Proxmox.
  3. Proxmox GUI: accede a https://<IP>:8006 y verifica que el clúster reconoce el nodo.
  4. LVM: ejecuta pvs, vgs y lvs para confirmar que todos los PV, VG y LV están activos.
  5. Logs: revisa journalctl -b -p err para asegurarte de que no hay errores de lvm o grub.

Notas adicionales

  • Mantén siempre una copia del archivo de configuración de GRUB (/etc/default/grub) antes de modificarlo.
  • Usa UUIDs en /etc/fstab y en la configuración de LVM; evitan problemas de renumeración de discos.
  • Cuando trabajes con servidores Dell, revisa la versión del BIOS después de cada actualización de Proxmox; a veces es necesario aplicar un BIOS rollback para mantener la compatibilidad con los controladores de arranque.
  • Si el nodo forma parte de un clúster HA, verifica que los recursos de alta disponibilidad no queden en estado “failed” tras el reinicio; de lo contrario, ejecuta ha-manager status y re‑asigna los recursos.

Con estos pasos, la mayoría de los fallos de arranque relacionados con actualizaciones de Proxmox, cambios en Secure Boot o problemas de LVM pueden resolverse sin necesidad de reinstalar el sistema. Mantener una rutina de backup de la partición ESP y de los metadatos de LVM reduce drásticamente el tiempo de inactividad.