No hay nada que anime más una rotación de guardia que un nodo Proxmox que no arranca después de una actualización rutinaria. Un minuto estás parchando por “seguridad”, y al siguiente te enfrentas a un prompt de grub, una pantalla negra o una consola que repite errores de dracut/initramfs mientras tus VM dejan de producir ingresos.
Esta es una guía de campo para recuperar ese nodo sin empeorarlo. Vamos a revertir kernels, reparar cargadores de arranque, recuperar almacenamiento respaldado por ZFS/LVM y reincorporar el nodo al clúster sin convertir un problema de un solo nodo en un trastorno de personalidad de todo el centro de datos.
Guía rápida de diagnóstico
Si no recuerdas nada más: tu objetivo es localizar la primera falla real en la cadena de arranque, no el último mensaje de error en el scrollback. Los fallos de arranque suelen mostrar “síntomas” lejos de su causa.
Primero: ¿Llega la máquina a un prompt de login?
- No, está atrapada antes del kernel (prompt de GRUB / shell EFI): esto es territorio del cargador de arranque/ESP. Salta a Reparar GRUB y EFI.
- No, el kernel hace panic o no puede montar la raíz: muy probablemente initramfs, controlador de almacenamiento faltante o UUID de raíz incorrecto. Ve a Initramfs y Almacenamiento.
- Sí, pero los servicios están rotos (pvedaemon, pveproxy, clúster): trátalo como “arranque exitoso, stack de Proxmox falló”. Ve a Tareas prácticas y Recuperación de clúster.
Segundo: ¿Está presente e importado el almacenamiento?
- Root en ZFS o almacenamiento ZFS para VM faltante: revisa la importación del pool, hostid, cachefile y nombres de dispositivos. ZFS suele decirte la verdad de forma contundente.
- LVM-thin desaparecido: revisa activación PV/VG, udev settle y si el initramfs incluye los módulos correctos para tu HBA/NVMe.
Tercero: ¿Es seguro reincorporar el nodo al clúster?
- Nodo único en un clúster y está caído: no “arregles” el quorum eliminando archivos al azar. Confirma qué nodo es la fuente de autoridad del estado del clúster.
- Dos nodos caídos: asume riesgo de split-brain. Pausa, elige una fuente de verdad y procede deliberadamente.
Y sí, puedes pasarte dos horas “depurando la red” cuando el problema real es que el sistema de archivos raíz está montado como solo lectura tras la recuperación del journal. Lo he visto. Lo he vivido.
Datos y contexto interesantes (por qué sigue pasando)
- Proxmox VE se apoya en la base de Debian. Cuando actualizas Proxmox, actualizas un sistema Debian más una pila curada: kernel(es), QEMU, LXC, ZFS y daemons de gestión.
- Tener múltiples kernels instalados es una característica, no basura. El empaquetado al estilo Debian suele mantener kernels antiguos para que puedas arrancar en uno conocido. Eliminar todos menos uno es como vender la rueda de repuesto para ahorrar peso.
- initramfs fue diseñado para resolver problemas de “controladores demasiado pronto”. Los sistemas modernos necesitan módulos de almacenamiento y criptografía antes de que exista el sistema de archivos raíz “real”; initramfs es ese andamiaje de userspace temprano.
- UEFI cambió los modos de fallo. Las fallas antiguas BIOS+MBR solían ser “GRUB está roto.” Con UEFI, puedes tener un sistema operativo perfecto y una partición del sistema EFI (ESP), una entrada NVRAM o una cadena shim rota.
- ZFS es conservador por defecto, pero poco indulgente con la identidad. Desajustes de hostid o cachefiles obsoletos pueden impedir la importación automática al arranque, especialmente después de clonar discos o mover pools entre máquinas.
- Corosync quorum es deliberadamente estricto. Está diseñado para evitar que ejecutes un clúster en split-brain aunque estés teniendo un “día productivo”.
- La interfaz web de Proxmox es solo un cliente. Cuando el nodo “parece muerto” en el navegador, puede que solo esté
pveproxycaído mientras las VM siguen ejecutándose debajo. - Las actualizaciones de kernel pueden romper módulos fuera del árbol. NVIDIA, algunos HBAs con controladores de proveedor y módulos construidos por DKMS pueden fallar en la compilación, dejándote sin controladores necesarios al arrancar.
Una idea de fiabilidad que merece estar pegada en tu monitor: la esperanza no es una estrategia
— atribuida en círculos operativos a James Cameron, suele repetirse cuando los equipos sustituyen el optimismo por planes de reversión.
Reglas de seguridad antes de tocar nada
El trabajo de recuperación es donde los buenos ingenieros se convierten en pirómanos accidentales. La forma más fácil de perder datos es “arreglar” las cosas rápido en el nodo equivocado, contra los discos equivocados y con suposiciones equivocadas.
Reglas que realmente sigo
- Prefiere cambios reversibles. Arrancar con un kernel antiguo es reversible. Reinstalar GRUB suele ser reversible. “Borrar e reinstalar Proxmox” no es un plan de recuperación; es una confesión.
- Anota lo que cambias. Notas con marca temporal superan a la memoria heroica siempre.
- No reincorpores un nodo al clúster hasta que esté estable. La membresía en el clúster multiplica los errores.
- Asume que tu almacenamiento es inocente hasta demostrar lo contrario. Los problemas de arranque a menudo parecen problemas de disco. No empieces a desactivar pools porque el initramfs no puede ver un HBA.
- Consigue acceso a la consola. IPMI/iKVM/consola física. SSH es fantástico hasta que deja de serlo.
Broma #1: Lo único más permanente que un parche temporal es un parche temporal hecho bajo presión.
Modos de fallo tras una actualización de Proxmox
“Falló tras la actualización” suele significar uno de estos bloques:
- Ruptura del cargador de arranque/EFI: menú GRUB ausente, entrada UEFI perdida, ESP no montado o initrd no encontrado.
- El kernel arranca, la raíz no se monta: controlador de almacenamiento faltante, UUID de raíz equivocado, initramfs roto, raíz cifrada que no se desbloquea.
- El sistema arranca, el stack de Proxmox falla: servicios pve no arrancan, sistemas de archivos de clúster atascados, problemas de corosync, certificados o permisos.
- El sistema arranca, red rota: bridges que no suben, modo de bond diferente tras actualización de controlador, desajustes de MTU, renombrado predecible de interfaces.
- El sistema arranca, almacenamiento faltante: pools ZFS no importan, volúmenes LVM no se activan, confusión de multipath, arreglos degradados que causan timeouts.
El truco es categorizar el fallo rápido. Luego eliges la solución menos invasiva que restaure el servicio.
Tareas prácticas de recuperación con comandos, salidas y decisiones
A continuación hay tareas prácticas que puedes ejecutar en un nodo roto o desde modo rescue/chroot. Cada una incluye qué significa la salida y qué decisión tomar a continuación.
Tarea 1: Identificar el kernel con el que arrancaste (o intentaste)
cr0x@server:~$ uname -a
Linux pve01 6.8.12-4-pve #1 SMP PREEMPT_DYNAMIC PMX 6.8.12-4 (2025-02-10T12:00Z) x86_64 GNU/Linux
Significado: Confirma la versión del kernel en ejecución. Si estás ejecutando el kernel más nuevo y las cosas están rotas, la reversión es tu primer paso.
Decisión: Si la falla se correlaciona con un salto de kernel, planea arrancar un kernel más antiguo desde GRUB y anclarlo temporalmente.
Tarea 2: Listar kernels instalados y paquetes de kernel de Proxmox
cr0x@server:~$ dpkg -l | egrep 'pve-kernel|linux-image' | awk '{print $1,$2,$3}'
ii pve-kernel-6.5.13-5-pve 6.5.13-5
ii pve-kernel-6.8.12-4-pve 6.8.12-4
ii proxmox-kernel-helper 8.1.1
Significado: Tienes al menos un kernel antiguo instalado. Eso es una tabla de salvación.
Decisión: Si existe un kernel anterior, pruébalo primero. Si no hay ninguno, necesitarás instalar uno (posiblemente desde rescue/chroot).
Tarea 3: Comprobar si el sistema entró en modo de emergencia y por qué
cr0x@server:~$ systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
pve-cluster.service loaded failed failed The Proxmox VE cluster filesystem
corosync.service loaded failed failed Corosync Cluster Engine
Significado: El SO está arriba, pero los servicios de clúster fallaron. Eso puede bloquear la gestión de Proxmox e incluso operaciones de VM que dependen del FS de clúster.
Decisión: No reinicies a ciegas. Extrae logs de la unidad fallida y decide si aislar el nodo (modo local) o arreglar corosync.
Tarea 4: Inspeccionar el journal para la primera falla real
cr0x@server:~$ journalctl -b -p err --no-pager | head -n 30
Feb 12 09:14:51 pve01 systemd[1]: Failed to start The Proxmox VE cluster filesystem.
Feb 12 09:14:51 pve01 pmxcfs[1203]: [main] unable to open cluster database (Connection refused)
Feb 12 09:14:51 pve01 corosync[1188]: [TOTEM ] Failed to bind to multicast address
Feb 12 09:14:51 pve01 corosync[1188]: [MAIN ] Corosync Cluster Engine exiting with status '2'
Significado: Esto no es “Proxmox está roto”, es un problema de binding de corosync, a menudo relacionado con la red (nombres de interfaz, cambios de IP, MTU, firewall).
Decisión: Verifica las interfaces de red y la config de corosync antes de tocar almacenamiento o reinstalar paquetes.
Tarea 5: Confirmar que los nombres de interfaz no cambiaron
cr0x@server:~$ ip -br link
lo UNKNOWN 00:00:00:00:00:00
enp4s0 UP 3c:ec:ef:12:34:56
enp5s0 DOWN 3c:ec:ef:12:34:57
vmbr0 DOWN 3c:ec:ef:12:34:56
Significado: El bridge está abajo. Eso puede ser tan simple como la NIC subyacente caída o la config del bridge fallando al aplicarse.
Decisión: Revisa /etc/network/interfaces e intenta un reinicio controlado de la red (o sube manualmente el bridge) antes de culpar a corosync.
Tarea 6: Validar que Proxmox monta /etc/pve (pmxcfs)
cr0x@server:~$ mount | grep /etc/pve
Significado: Ninguna salida significa que pmxcfs no está montado; el filesystem de clúster no está arriba.
Decisión: Si necesitas recuperación local, puedes iniciar Proxmox en un estado “sin clúster” temporalmente (se cubre más adelante). Si es un entorno multinodo, arregla corosync primero.
Tarea 7: Comprobar visibilidad de discos y estado de controladores del kernel
cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
sda 1.8T disk
├─sda1 512M part vfat /boot/efi
├─sda2 1G part ext4 /boot
└─sda3 1.8T part
└─pve-root 96G lvm /
nvme0n1 1.7T disk zfs_member
nvme1n1 1.7T disk zfs_member
Significado: Los discos están presentes; EFI y particiones de arranque están montadas; miembros ZFS visibles. Eso reduce las probabilidades de “hardware desaparecido”.
Decisión: Si faltan dispositivos, sospecha del kernel/HBA módulo/initramfs. Si están presentes pero pools/volúmenes faltan, céntrate en importación/activación.
Tarea 8: Comprobar estado de importación de pools ZFS (si usas ZFS)
cr0x@server:~$ zpool import
pool: tank
id: 1234567890123456789
state: ONLINE
action: The pool can be imported using its name or numeric identifier.
config:
tank ONLINE
mirror-0 ONLINE
nvme0n1 ONLINE
nvme1n1 ONLINE
Significado: El pool existe pero no está importado. El arranque pudo haber omitido la importación automática por hostid o timings.
Decisión: Imprórtalo en modo lectura/escritura solo si estás seguro de que este nodo es el propietario correcto. Si dudas (almacenamiento compartido, discos movidos), importa en solo lectura primero.
Tarea 9: Importar pool ZFS con cuidado y configurar cachefile para arranques futuros
cr0x@server:~$ zpool import -o cachefile=/etc/zfs/zpool.cache tank
cr0x@server:~$ zpool status tank
pool: tank
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
nvme0n1 ONLINE 0 0 0
nvme1n1 ONLINE 0 0 0
errors: No known data errors
Significado: Pool importado y sano. Configurar el cachefile ayuda a que initramfs/secuencia de arranque localice pools de forma fiable.
Decisión: Si la importación falla por hostid, aborda el hostid en lugar de forzar importaciones repetidas.
Tarea 10: Verificar estado de LVM (si usas LVM-thin)
cr0x@server:~$ pvs
PV VG Fmt Attr PSize PFree
/dev/sda3 pve lvm2 a-- <1.82t 0
cr0x@server:~$ vgs
VG #PV #LV #SN Attr VSize VFree
pve 1 3 0 wz--n- <1.82t 0
cr0x@server:~$ lvs -a
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
data pve twi-aotz-- <1.60t 72.11 2.40
root pve -wi-ao---- 96.00g
swap pve -wi-ao---- 8.00g
Significado: PV/VG/LVs existen y están activas (ao). Si faltan VGs o están inactivas, la activación de almacenamiento es tu problema.
Decisión: Si están inactivas, prueba vgchange -ay e inspecciona dmesg por errores de dispositivo antes de forzar reparaciones.
Tarea 11: Validar espacio libre en /boot y ESP (las actualizaciones fallan silenciosamente cuando /boot está lleno)
cr0x@server:~$ df -h /boot /boot/efi
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 1007M 983M 24M 98% /boot
/dev/sda1 511M 12M 500M 3% /boot/efi
Significado: /boot está prácticamente lleno. Eso puede producir instalaciones incompletas de initramfs/kernel y comportamiento de arranque extraño.
Decisión: Elimina kernels antiguos de forma limpia (después de tener un arranque conocido y estable) o amplía /boot. No borres archivos al azar en /boot como si fuera 1999.
Tarea 12: Buscar fallos de compilación DKMS/módulos que rompan controladores
cr0x@server:~$ journalctl -b --no-pager | grep -E 'dkms|module|firmware' | tail -n 20
Feb 12 09:10:22 pve01 kernel: i915 0000:00:02.0: firmware: failed to load i915/skl_dmc_ver1_27.bin (-2)
Feb 12 09:10:25 pve01 dkms[842]: Error! Bad return status for module build on kernel: 6.8.12-4-pve (x86_64)
Feb 12 09:10:25 pve01 dkms[842]: Consult /var/lib/dkms/.../build/make.log for more information.
Significado: Un módulo DKMS falló al compilar. Si ese módulo es necesario para almacenamiento o red, el arranque puede suceder pero los dispositivos no funcionarán.
Decisión: Revierte el kernel o arregla la compilación DKMS. Si no es crítico (por ejemplo, GPU en un host sin cabeza), silencia la alerta pero no ignores errores DKMS relacionados con almacenamiento.
Tarea 13: Confirmar salud de servicios de Proxmox (cuando el SO arranca pero la UI está muerta)
cr0x@server:~$ systemctl status pveproxy pvedaemon pvestatd --no-pager
● pveproxy.service - PVE API Proxy Server
Loaded: loaded (/lib/systemd/system/pveproxy.service; enabled)
Active: active (running) since Wed 2025-02-12 09:18:02 UTC; 2min ago
● pvedaemon.service - PVE API Daemon
Loaded: loaded (/lib/systemd/system/pvedaemon.service; enabled)
Active: active (running) since Wed 2025-02-12 09:18:00 UTC; 2min ago
● pvestatd.service - PVE Status Daemon
Loaded: loaded (/lib/systemd/system/pvestatd.service; enabled)
Active: active (running) since Wed 2025-02-12 09:18:01 UTC; 2min ago
Significado: Servicios centrales activos. Si la web UI sigue fallando, sospecha de firewall, problemas de certificados o caché del cliente.
Decisión: Si los servicios están caídos, revisa dependencias: montaje de /etc/pve, resolución DNS/nombre de host, desincronización de tiempo, disco lleno.
Tarea 14: Comprobar estado del clúster y quorum sin adivinar
cr0x@server:~$ pvecm status
Cluster information
-------------------
Name: prod-cluster
Config Version: 43
Transport: knet
Secure auth: on
Quorum information
------------------
Date: Wed Feb 12 09:21:12 2025
Quorum provider: corosync_votequorum
Nodes: 3
Node ID: 0x00000001
Ring ID: 1.2
Quorate: Yes
Significado: El quorum está presente. Eso cambia cuánto puedes ser agresivo: puedes reparar este nodo sin reescribir el estado del clúster.
Decisión: Si Quorate: No, evita cambios que requieran escrituras al clúster; considera modo local temporal o estrategia de restauración de quorum.
Reversión de kernel: la solución menos dramática
Cuando un nodo Proxmox falla justo después de una actualización, asume que el kernel más nuevo es el culpable hasta que se demuestre lo contrario. Revertir suele ser rápido, seguro y reversible. También te da tiempo para depurar correctamente.
Arrancar un kernel más antiguo desde GRUB
En el arranque, elige Opciones avanzadas y selecciona el pve-kernel anterior. Si no llegas a GRUB porque la pantalla pasa demasiado rápido, mantén Shift en sistemas BIOS o pulsa Esc en muchos sistemas UEFI durante el arranque.
Anclar el kernel conocido bueno (temporal)
Una vez arrancado en el kernel que funciona, evita que el sistema “amablemente” vuelva al más nuevo en el próximo reinicio.
cr0x@server:~$ proxmox-boot-tool kernel list
Manually selected kernels:
None.
Automatically selected kernels:
6.8.12-4-pve
6.5.13-5-pve
Pinned kernel:
None.
Significado: No hay kernel anclado; la selección por defecto puede preferir el más nuevo.
Decisión: Ancla el kernel que funciona hasta completar la investigación.
cr0x@server:~$ proxmox-boot-tool kernel pin 6.5.13-5-pve
Pinned kernel version '6.5.13-5-pve'
Si no estás en una configuración gestionada por proxmox-boot-tool, también puedes controlar los valores por defecto de GRUB, pero anclar con las herramientas de Proxmox suele ser más limpio cuando está disponible.
Reconstruir initramfs y refrescar GRUB tras la reversión
Incluso si el kernel antiguo arranca, refresca los artefactos de arranque para no tropezar con initramfs parcialmente escritos.
cr0x@server:~$ update-initramfs -u -k 6.5.13-5-pve
update-initramfs: Generating /boot/initrd.img-6.5.13-5-pve
Significado: initramfs reconstruido para el kernel elegido.
Decisión: Si esto falla por /boot lleno, detente y arregla la capacidad de /boot antes de continuar.
cr0x@server:~$ update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.12-4-pve
Found initrd image: /boot/initrd.img-6.8.12-4-pve
Found linux image: /boot/vmlinuz-6.5.13-5-pve
Found initrd image: /boot/initrd.img-6.5.13-5-pve
done
Significado: GRUB ve ambos kernels e initrds.
Decisión: Reinicia una vez que hayas anclado/seleccionado el kernel de confianza y confirma que permanece seleccionado.
Reparar GRUB y problemas de arranque EFI
Si caes en un prompt de GRUB, un shell EFI o “dispositivo no arrancable”, ya no estás depurando Proxmox. Estás depurando la cadena de arranque. Trátalo como una operación quirúrgica: verifica discos, particiones, monta correctamente y luego reinstala el cargador de arranque.
Decidir: ¿BIOS/MBR o UEFI?
cr0x@server:~$ [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
UEFI
Significado: Este host está arrancado en modo UEFI (o debería estarlo).
Decisión: Centra la atención en la EFI System Partition en /boot/efi y en las entradas NVRAM UEFI.
Comprobar que la ESP está presente y montable
cr0x@server:~$ lsblk -f | grep -E 'vfat|EFI|/boot/efi'
sda1 vfat FAT32 7A3B-1C2D /boot/efi
Significado: La ESP existe y está montada. Si falta o no se puede montar, no puedes reinstalar GRUB de forma fiable.
Decisión: Si no está montada, móntala. Si el montaje falla, ejecuta comprobaciones de sistema de ficheros desde modo rescue.
Validar entradas de arranque UEFI
cr0x@server:~$ efibootmgr -v
BootCurrent: 0002
Timeout: 1 seconds
BootOrder: 0002,0001
Boot0001* UEFI OS HD(1,GPT,...)File(\EFI\BOOT\BOOTX64.EFI)
Boot0002* proxmox HD(1,GPT,...)File(\EFI\proxmox\grubx64.efi)
Significado: La entrada de arranque existe y apunta a un binario GRUB EFI de Proxmox. Si apunta a la nada, entrarás en el shell EFI.
Decisión: Si falta, reinstala GRUB en la ESP y recrea la entrada de arranque.
Reinstalar GRUB en UEFI
cr0x@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 colocaron en la ESP.
Decisión: Sigue con update-grub y verifica la entrada con efibootmgr.
cr0x@server:~$ update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.5.13-5-pve
Found initrd image: /boot/initrd.img-6.5.13-5-pve
done
Si necesitas modo rescue + chroot (común)
Cuando el nodo no puede arrancar, arranca desde un ISO de rescate, monta tu sistema raíz y chroot. Los pasos exactos dependen de si la raíz es LVM o ZFS. Aquí hay un flujo representativo para raíz en LVM.
cr0x@server:~$ vgscan
Found volume group "pve" using metadata type lvm2
cr0x@server:~$ vgchange -ay
3 logical volume(s) in volume group "pve" now active
cr0x@server:~$ mount /dev/pve/root /mnt
cr0x@server:~$ mount /dev/sda2 /mnt/boot
cr0x@server:~$ mount /dev/sda1 /mnt/boot/efi
cr0x@server:~$ for i in /dev /dev/pts /proc /sys /run; do mount --bind $i /mnt$i; done
cr0x@server:~$ chroot /mnt /bin/bash
Significado: Ahora operas dentro del OS instalado, que es donde las herramientas de GRUB e initramfs esperan ejecutarse.
Decisión: Reinstala kernel/initramfs/GRUB desde dentro del chroot; luego sal, desmonta limpiamente y reinicia.
Initramfs, módulos faltantes y controladores de almacenamiento
El clásico “ladrillo” post-actualización: el kernel arranca y luego no encuentra el sistema de archivos raíz. Ves mensajes como “waiting for root device”, “unable to mount root fs” o te deja en un shell de initramfs.
Esto suele ser una de estas causas:
- initramfs no se generó correctamente (disco lleno, actualización interrumpida).
- Faltaron módulos necesarios para tu controlador de almacenamiento.
- El UUID de la raíz cambió (clonado, reemplazo de disco) pero la configuración de arranque no.
- Root en ZFS: el pool no se importó por hostid/problemas de cache.
Comprobar qué piensa el kernel que es tu dispositivo raíz
cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.8.12-4-pve root=/dev/mapper/pve-root ro quiet
Significado: La raíz apunta a un dispositivo mapper LVM. Si ese mapper nunca aparece, fallarás al montar la raíz.
Decisión: Verifica la activación de LVM en initramfs (o reconstruye initramfs con los bits LVM) y confirma que el PV subyacente sea visible temprano en el arranque.
Ver si el controlador de almacenamiento se cargó realmente
cr0x@server:~$ lsmod | egrep 'nvme|ahci|megaraid|mpt3sas|vfio' | head
nvme 61440 2
ahci 45056 0
Significado: El sistema en ejecución tiene módulos NVMe y AHCI. En escenarios de fallo, estos pueden estar ausentes en initramfs, no en el OS completo.
Decisión: Si sospechas módulos faltantes en initramfs, reconstruye initramfs y asegúrate de incluir los módulos necesarios.
Reconstruir initramfs para todos los kernels instalados
cr0x@server:~$ update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-6.5.13-5-pve
update-initramfs: Generating /boot/initrd.img-6.8.12-4-pve
Significado: Ambos initrds regenerados. Esto soluciona muchos fallos de arranque por “kernel medio instalado”.
Decisión: Si da error “No space left on device”, arregla /boot antes de nada.
Asegúrate de que /etc/initramfs-tools/modules incluya controladores raros pero necesarios
La mayoría de sistemas no lo necesita. Algunos sí. Especialmente si arrancas desde HBAs exóticos, iSCSI o tienes problemas estrictos de orden. Ejemplo de fragmento que podrías añadir:
cr0x@server:~$ sed -n '1,120p' /etc/initramfs-tools/modules
# List of modules that you want to include in your initramfs.
# They will be loaded at boot time in the order below.
nvme
ahci
Significado: Estos módulos se forzarán dentro del initramfs.
Decisión: Añade solo módulos que entiendas. Meter todo en initramfs hace que los arranques sean lentos y genera nuevos modos de fallo.
Recuperación de almacenamiento: ZFS y LVM-thin
El almacenamiento es donde lo “simple” se vuelve incidente. Si lo haces mal puedes crear corrupción real. Si lo haces bien, pareces un mago. La diferencia es principalmente disciplina.
ZFS: pools que no se importan tras la actualización
Razones comunes:
- Desajuste de hostid tras reinstalar, clonar o cambiar
/etc/hostid. - Cachefile faltante/obsoleto; initramfs no puede encontrar pools de forma fiable.
- Cambios en nombres de dispositivos (p. ej. orden SATA) y usaste rutas crudas /dev/sdX en lugar de by-id.
- El pool está ocupado o importado en otro sitio (en escenarios de disco compartido, esto es la sirena de advertencia).
Comprobar hostid y expectativas de ZFS
cr0x@server:~$ hostid
1a2b3c4d
cr0x@server:~$ ls -l /etc/hostid
-rw-r--r-- 1 root root 4 Feb 12 09:00 /etc/hostid
Significado: hostid existe. Si cambió recientemente, ZFS puede negarse a importar automáticamente o comportarse de forma distinta.
Decisión: Si los pools se movieron de otro host, establece hostid intencionalmente y documenta el cambio. No “te la juegues” con importaciones forzadas.
Verificar salud del pool una vez importado
cr0x@server:~$ zpool status -x
all pools are healthy
Significado: No hay problemas conocidos en ZFS.
Decisión: Procede a la recuperación de servicios de Proxmox. Si está degradado, atiende al resilver antes de reiniciar cargas de alto I/O.
LVM-thin: VMs faltantes, almacenamiento “inactivo” o errores de thin pool
LVM-thin suele fallar por problemas de orden de activación o timeouts en dispositivos subyacentes. Menos frecuentemente, la metadata thin se llena.
Activar volume groups y comprobar uso de metadata thin
cr0x@server:~$ vgchange -ay
3 logical volume(s) in volume group "pve" now active
cr0x@server:~$ lvs -o lv_name,vg_name,attr,lv_size,data_percent,metadata_percent
LV VG Attr LSize Data% Meta%
data pve twi-aotz-- <1.60t 72.11 2.40
root pve -wi-ao---- 96.00g
swap pve -wi-ao---- 8.00g
Significado: La metadata del thin pool está solo al 2.40%. Eso está bien.
Decisión: Si la metadata está cerca del 100%, detente. Ampliar/reparar metadata thin es delicado; no reinicies docenas de VMs y empeores la situación.
Comprobar errores de sistema de archivos si la raíz pasó a solo lectura
cr0x@server:~$ mount | grep ' / '
/dev/mapper/pve-root on / type ext4 (ro,relatime,errors=remount-ro)
Significado: La raíz está montada como solo lectura. Eso romperá la gestión de paquetes, el FS de clúster, los logs, todo.
Decisión: Reinicia en rescue y ejecuta fsck. No “simplemente remontes rw” y esperes; a menudo empeorarás daños en metadata.
Recuperación de clúster: quorum, corosync y reincorporación segura
La recuperación de clúster es donde ingenieros con buenas intenciones provocan semanas malas. Corosync es quisquilloso por diseño. Respétalo.
Decidir si tratas con:
- Un solo nodo roto mientras el resto del clúster está sano.
- Pérdida de quorum por múltiples nodos caídos o partición de red.
- Riesgo de split-brain (dos mitades que creen ser primarias).
Comprobar corosync y estado del clúster
cr0x@server:~$ systemctl status corosync --no-pager
● corosync.service - Corosync Cluster Engine
Loaded: loaded (/lib/systemd/system/corosync.service; enabled)
Active: failed (Result: exit-code) since Wed 2025-02-12 09:14:51 UTC; 8min ago
Process: 1188 ExecStart=/usr/sbin/corosync -f $COROSYNCOPTIONS (code=exited, status=2)
Significado: corosync no arrancó. La razón está en los logs; no adivines.
Decisión: Extrae logs detallados y verifica que la interfaz de red usada por corosync esté arriba y tenga la IP esperada.
cr0x@server:~$ journalctl -u corosync --no-pager | tail -n 40
Feb 12 09:14:51 pve01 corosync[1188]: [KNET ] host: 1 link: 0 is down
Feb 12 09:14:51 pve01 corosync[1188]: [KNET ] failed to bind to interface 'vmbr0'
Feb 12 09:14:51 pve01 corosync[1188]: [MAIN ] Corosync Cluster Engine exiting with status '2'
Significado: Corosync quiere vmbr0 pero está caído o falta. Arregla la config de red antes de tocar la config del clúster.
Decisión: Sube el bridge/interfaz y luego vuelve a intentar corosync.
Modo local temporal (usar con moderación)
A veces necesitas poner un nodo operativo (p. ej., para evacuar VMs mediante acceso a almacenamiento) aunque corosync no pueda formarse. Proxmox soporta ejecutarse sin comunicaciones de clúster, pero debes entender las compensaciones.
Un enfoque común es parar servicios de clúster y trabajar localmente. Esto puede permitirte acceder a almacenamiento y VMs locales, pero la configuración gestionada por clúster no se comportará normalmente.
cr0x@server:~$ systemctl stop pve-cluster corosync
cr0x@server:~$ systemctl status pve-cluster --no-pager
● pve-cluster.service - The Proxmox VE cluster filesystem
Loaded: loaded (/lib/systemd/system/pve-cluster.service; enabled)
Active: inactive (dead)
Significado: El FS de clúster está parado; ya no escribes estado de clúster.
Decisión: Usa esto para estabilizar el nodo y verificar almacenamiento/estado de VMs. No operes a largo plazo así en un clúster real salvo que disfrutes reuniones.
Broma #2: Split-brain es cuando ambas mitades de tu clúster se vuelven muy seguras de sí mismas y muy equivocadas.
Estrategia de reincorporación
Una vez que el nodo arranca bien, la red es estable y el almacenamiento es correcto, vuelve a habilitar corosync y pmxcfs y confirma el quorum. No “arregles” desajustes de versión de config copiando archivos al azar; alinea el nodo con la fuente de verdad del clúster.
Recuperación de red: bridges, bonds y “¿por qué vmbr0 está caído?”
Los problemas de red tras actualizaciones suelen provenir de cambios en controladores, renombrado de interfaces o una configuración de bridge/bond que depende de algo cuyo orden cambió.
Inspeccionar la configuración de red
cr0x@server:~$ sed -n '1,200p' /etc/network/interfaces
auto lo
iface lo inet loopback
auto enp4s0
iface enp4s0 inet manual
auto vmbr0
iface vmbr0 inet static
address 10.10.10.11/24
gateway 10.10.10.1
bridge-ports enp4s0
bridge-stp off
bridge-fd 0
Significado: vmbr0 depende de enp4s0. Si enp4s0 fue renombrada (p. ej., a enp3s0), vmbr0 no subirá.
Decisión: Compara con ip -br link y corrige nombres de interfaz. Luego sube la red con cuidado.
Subir el bridge manualmente para confirmar que la config es el problema, no el hardware
cr0x@server:~$ ip link set enp4s0 up
cr0x@server:~$ ifup vmbr0
Internet Systems Consortium DHCP Client 4.4.3-P1
ifup: interface vmbr0 already configured
Significado: O ya está configurada o ifupdown2 cree que lo está. Si permanece DOWN, inspecciona ip addr y los logs.
Decisión: Si el bridge se niega, busca gestores de red en conflicto o errores de sintaxis en la config.
Confirmar que la interfaz de bind de corosync existe y tiene la IP esperada
cr0x@server:~$ ip -br addr show vmbr0
vmbr0 UP 10.10.10.11/24
Significado: corosync puede bindear. A menudo esa es toda la solución para “clúster caído tras actualización”.
Decisión: Reinicia corosync y luego pve-cluster, en ese orden, y confirma con pvecm status.
Listas de verificación / plan paso a paso
Plan A: El nodo no arranca tras la actualización (lo más común)
- Consigue acceso a la consola (IPMI/iKVM). Captura el primer error en pantalla.
- Prueba las opciones avanzadas de GRUB: arranca el kernel anterior de Proxmox.
- Si el arranque funciona, ancla el kernel que funciona y reconstruye initramfs para todos los kernels.
- Revisa el espacio en /boot; si está casi lleno, elimina kernels antiguos solo después de confirmar arranque estable.
- Verifica almacenamiento: pools ZFS importados, LVM activo, sistema de archivos raíz montado en lectura-escritura.
- Confirma servicios de Proxmox: pveproxy/pvedaemon/pvestatd, luego servicios de clúster si aplica.
- Reinicia una vez para validar que la solución persiste.
Plan B: Fallo GRUB/UEFI (ni siquiera puedes alcanzar un kernel)
- Arranca ISO de rescate en el mismo modo (UEFI vs BIOS) que usa el sistema.
- Monta root, /boot y /boot/efi; bind-mount /dev,/proc,/sys,/run; chroot.
- Reinstala GRUB en la ESP (UEFI) o en el disco (BIOS) y ejecuta update-grub.
- Reconstruye initramfs para el kernel conocido bueno.
- Verifica entradas con efibootmgr; reinicia y prueba.
Plan C: El SO arranca, el stack de Proxmox está roto (UI web caída, clúster enojado)
- Revisa primero disco lleno, raíz montada en solo lectura y desfase de tiempo.
- Revisa unidades fallidas con
systemctl --failed. - Confirma estado de montaje de
/etc/pve; problemas del FS de clúster romperán la gestión. - Para fallos de corosync, valida interfaz de red y MTU, luego reinicia corosync y pve-cluster.
- Sólo si es necesario, opera temporalmente en modo local para recuperar VMs o almacenamiento, luego reincorpora correctamente.
Plan D: Almacenamiento faltante tras la actualización
- Confirma que el kernel ve los discos (
lsblk,dmesg). - Para ZFS: ejecuta
zpool import, importa con precaución, configura cachefile, revisa hostid. - Para LVM: ejecuta
vgscan,vgchange -ay, inspecciona uso de thin pool. - No fuerces importaciones/reparaciones hasta entender si los discos fueron movidos o compartidos.
Errores comunes (síntomas → causa raíz → solución)
1) Síntoma: “Arranca en shell de initramfs, no encuentra dispositivo raíz”
Causa raíz: initramfs sin drivers de almacenamiento o bits LVM; o initrd incompleto por /boot lleno.
Solución: Arranca un kernel antiguo; en rescue/chroot reconstruye initramfs (update-initramfs -u -k all), libera espacio en /boot, asegura incluir los módulos necesarios.
2) Síntoma: “Prompt de GRUB” o “dispositivo no arrancable” tras actualización
Causa raíz: montaje ESP roto, entrada EFI faltante, instalación de grub incompleta o corrupción de ESP.
Solución: Monta la ESP, reinstala GRUB para UEFI, ejecuta update-grub, verifica entradas con efibootmgr.
3) Síntoma: “El nodo arranca pero la interfaz web de Proxmox está inaccesible”
Causa raíz: pveproxy o pvedaemon no corren; /etc/pve no está montado; raíz en solo lectura; disco lleno.
Solución: Revisa systemctl status para servicios pve, verifica mount | grep /etc/pve, arregla estado del sistema de archivos, libera espacio en disco.
4) Síntoma: “El clúster muestra nodo offline; errores de pmxcfs”
Causa raíz: corosync no puede bindear porque el nombre de interfaz cambió o el bridge está caído.
Solución: Arregla /etc/network/interfaces para coincidir con los nombres reales de NIC, sube vmbr0, reinicia corosync y luego pve-cluster.
5) Síntoma: “Pool ZFS no se importa al arranque, pero los discos están presentes”
Causa raíz: desajuste de hostid o cachefile zpool obsoleto/faltante; cambios en rutas de dispositivo.
Solución: Importa con opción cachefile, confirma estabilidad de hostid, prefiere nombres por-id, reconstruye initramfs si la raíz es ZFS.
6) Síntoma: “La actualización tuvo éxito, pero tras el reinicio la red está rara”
Causa raíz: cambio de controlador de NIC, renombrado predecible de interfaces o desajuste de modo de bond tras actualización de módulo.
Solución: Confirma ip -br link y ajusta configuración de bridge/bond; revisa dmesg por errores de controlador; revierte kernel si es necesario.
7) Síntoma: “Todo parece bien, pero no se pueden instalar/retroceder paquetes”
Causa raíz: raíz montada en solo lectura o /var lleno; dpkg quedó con paquetes medio configurados tras una actualización interrumpida.
Solución: Resuelve el estado del sistema de archivos y luego ejecuta dpkg --configure -a y apt -f install desde un arranque estable.
8) Síntoma: “Faltan discos de VM en la vista de almacenamiento”
Causa raíz: backend de almacenamiento no activo (pool ZFS no importado, VG no activado), o pmxcfs no montado por lo que la config de almacenamiento no se carga.
Solución: Restaura primero el almacenamiento (importa/activa), luego asegúrate de que el FS de clúster esté montado y los servicios pve sanos.
Tres micro-historias del mundo corporativo (dolor, aprendizaje y una victoria aburrida)
Micro-historia 1: El incidente causado por una suposición equivocada
Una empresa mediana ejecutaba un clúster Proxmox de tres nodos con Ceph para discos de VM y un par de pools ZFS locales para backups. Llegó un fin de semana de actualizaciones. Un nodo no volvió. El ingeniero on-call vio “pool ZFS no importado” y asumió que era seguro forzar la importación porque “es local de todos modos”.
La suposición errónea: el pool “local” no era puramente local. Meses antes, el equipo de hardware había movido discos entre nodos durante un reemplazo de chasis. Nadie actualizó las notas de activos. El pool se había importado en otro nodo durante el movimiento, y la historia de hostid + cachefile era un desastre. Forzar la importación en el nodo roto hizo que pareciera disponible, pero no era la copia autorizada de todo.
No corrompieron inmediatamente el pool, pero hicieron algo casi igual de costoso: restauraron backups desde snapshots equivocados. Varias VM volvieron con datos obsoletos que parecían consistentes a primera vista. El incidente dejó de ser “nodo caído” y se convirtió en “integridad de datos en duda”, frase que provoca reuniones.
La solución fue mayormente de proceso. Documentaron dónde vivía cada pool físicamente, aseguraron importaciones con rutas by-id estables y trataron “force import” como una acción de emergencia que requiere una segunda mirada. Técnicamente, la jugada de recuperación habría sido: importar en sólo lectura, confirmar timestamps de datasets y luego decidir. Socialmente, la jugada fue: no asumas que algo es “local” salvo que puedas señalar la bahía.
Micro-historia 2: La optimización que salió mal
Otra organización tenía una iniciativa de rendimiento: reducir el tiempo de arranque y las ventanas de parcheo en hosts de virtualización. Alguien decidió “limpiar kernels antiguos” de forma agresiva para recuperar espacio en /boot y reducir mantenimiento. Pusieron automatización para conservar solo el kernel más reciente.
Funcionó hasta que no. Llegó un nuevo kernel con una regresión que afectaba su combinación específica de firmware de RAID. El host reinició en el kernel nuevo y no pudo ver su disco raíz. Al no haber un kernel anterior instalado, “arrancar el previo” dejó de ser opción. Tuvieron que hacer el baile del ISO de rescate durante una ventana de mantenimiento ya sobrecosteada.
La recuperación tomó más tiempo del necesario, en parte porque la ruta on-call estaba diseñada alrededor de la reversión: arrancar kernel antiguo, reunir logs y decidir. Esa ruta fue eliminada en nombre de la limpieza.
La corrección eventual fue poco glamorosa: mantener al menos dos kernels conocidos buenos, alertar sobre uso de /boot y añadir una comprobación pre-reinicio que verifique que initramfs se generó correctamente. La optimización no era perversa; era incompleta. La fiabilidad odia “todos los huevos en una cesta”, especialmente cuando la cesta es un kernel.
Micro-historia 3: La práctica aburrida pero correcta que salvó el día
Un equipo de servicios financieros tenía un clúster Proxmox que soportaba CI interno y algunos servicios sensibles a latencia. Su práctica de parcheo era aburrida: un nodo a la vez, evacuar VMs, actualizar, reiniciar, validar y continuar. También tenían una estricta costumbre: mantener iKVM accesible y probado, y snapshotear la configuración de arranque (lista de kernels, defaults de grub, /etc/network/interfaces) antes del mantenimiento.
Durante una actualización, un nodo reinició y apareció con la red mal configurada por un renombrado de interfaz. Corosync falló. El nodo “caía” desde la perspectiva del clúster. Pero el equipo ya había evacuado cargas. Así que no hubo impacto al cliente, solo orgullo herido de ingeniero.
Usaron el acceso por consola para comparar nombres de interfaces, arreglaron los puertos del bridge, reiniciaron corosync y se reincorporaron limpiamente. El postmortem fue casi aburrido: “nombre de interfaz cambiado; validamos antes/después; sin impacto en cargas.” Aburrido es el objetivo. El drama no es KPI.
Esa misma disciplina aburrida hizo que la reparación fuera segura: no importaciones forzadas, no reinicios aleatorios, no cambios apresurados de quorum. Solo pasos controlados y verificación en cada etapa. La respuesta a incidentes más impresionante es la que nadie fuera del equipo nota.
Preguntas frecuentes
1) ¿Debo revertir el kernel o reinstalar Proxmox?
Revertir el kernel primero. Reinstalar Proxmox es el último recurso y suele ser innecesario. Un kernel antiguo funcional junto con artefactos de arranque reparados resuelve una gran fracción de casos “falló tras la actualización”.
2) ¿Puedo eliminar de forma segura el paquete de kernel defectuoso?
Sí, pero solo después de confirmar arranque estable con otro kernel y tener suficiente espacio en /boot. Usa herramientas de paquetes, no borrados manuales en /boot. Mantén al menos un kernel de reserva instalado.
3) Mi nodo arranca, pero la UI de Proxmox es inaccesible. ¿Mis VM están muertas?
No necesariamente. Revisa systemctl status pveproxy y también verifica procesos de VM con qm list (si está disponible) o ps. La UI es un servicio; puede caerse mientras QEMU sigue ejecutándose.
4) El pool ZFS no se importa automáticamente tras reinicio. ¿Cuál es la causa más común?
Problemas de hostid/cachefile y cambios en nombres de dispositivos. Importa el pool explícitamente, configura el cachefile y asegúrate de que el hostid sea estable e intencional.
5) ¿Es seguro forzar la importación de un pool ZFS?
A veces. Pero también es una buena forma de convertir incertidumbre en consecuencias. Si hay posibilidad de que el pool esté importado en otro sitio o se movió entre hosts, importa en solo lectura primero y verifica.
6) ¿Cómo sé si /boot lleno causó mi fallo?
Revisa df -h /boot. Si supera ~90% y instalaste kernels recientemente, probablemente tienes initramfs incompletos o scripts postinst fallidos. Reconstruye initramfs después de liberar espacio.
7) ¿Cuál es el orden seguro para levantar servicios de clúster?
Primero la red (la interfaz a la que se liga corosync debe estar arriba), luego inicia corosync, después pve-cluster, confirma que /etc/pve esté montado y luego verifica servicios pve.
8) ¿Puedo ejecutar un nodo Proxmox “standalone” si el clúster está roto?
Temporalmente sí, parando servicios de clúster. Pero estás renunciando a la configuración y protecciones gestionadas por el clúster. Úsalo para recuperar datos o estabilizar el nodo y luego reincorpora correctamente.
9) ¿Por qué una actualización de kernel rompió la red?
Regresiones de controladores, interacciones con firmware o renombrado de interfaces. El kernel es el contrato con el hardware. Cuando ese contrato cambia, tu configuración de bridge/bond puede fallar de formas sorprendentes.
10) Si arreglo el arranque, ¿cómo evito que vuelva a pasar?
Aplica actualizaciones nodo por nodo, conserva kernels de reserva, monitoriza espacio en /boot, valida la generación de initramfs y prueba el acceso por consola antes de necesitarlo.
Conclusión: siguientes pasos que realmente debes hacer
Para recuperar un nodo Proxmox tras una mala actualización, prioriza la reversibilidad: arranca un kernel anterior, ancralo, reconstruye initramfs y solo después repara GRUB/EFI si es necesario. Valida la importación/activación del almacenamiento antes de tocar la membresía del clúster. Levanta la red antes de corosync. Y no “forces” nada hasta probar que estás operando sobre los discos correctos en el lugar correcto.
Siguientes pasos que se pagan por sí mismos:
- Mantén al menos dos kernels funcionales instalados y asegura espacio libre en /boot.
- Prueba acceso iKVM/IPMI trimestralmente, no durante una crisis.
- Documenta la propiedad del almacenamiento (qué pools viven dónde) y prefiere rutas de dispositivo by-id estables.
- Adopta un workflow de actualización de un nodo a la vez con evacuación de VMs y una lista de verificación de validación real.
Si haces esas cuatro cosas, el próximo evento “falló tras la actualización” será una reversión de 20 minutos, no un fin de semana largo con juramentos creativos cada vez más imaginativos.