Proxmox no arranca tras una actualización del kernel: revertir vía GRUB correctamente

Guía rápida de diagnóstico

Cuando un nodo Proxmox no arranca tras una actualización del kernel, tu trabajo es obtener información rápido y evitar “arreglos” que destruyan evidencia (o rompan tu pool ZFS, o tu cargador de arranque, o tu estado de ánimo). Aquí tienes un orden de triage que funciona bajo presión.

Primero: identifica qué tipo de fallo tienes (segundos, no minutos)

• No aparece el menú GRUB / arranca directamente al firmware: probable problema con la entrada EFI/ESP, o cambio en el orden de arranque.
• GRUB aparece y hay selección de kernel: bien. Reviértelo al kernel anterior primero.
• El kernel carga y luego hace panic / se queda colgado: suele ser initramfs con módulos faltantes, incompatibilidad de controladores DKMS, o el almacenamiento raíz no encontrado.
• Arranca a un shell de emergencia: fallo al montar el sistema root, fallo al importar ZFS, o parámetros de kernel incorrectos.
• Pantalla negra tras GRUB: a menudo problemas de transferencia de la GPU/consola o del framebuffer; todavía puede estar arrancando—comprueba actividad de disco o responde a ping desde otra máquina.

Segundo: elige la vía de recuperación menos invasiva

1. Usa GRUB para arrancar un kernel anterior (rápido, reversible, mantiene tu instalación intacta).
2. Edita temporalmente desde GRUB para añadir un parámetro (por ejemplo debug o nomodeset) si es necesario.
3. Usa medios de rescate solo si GRUB no puede arrancar nada o falta la ESP.

Tercero: decide qué necesitas preservar

Antes de “limpiar kernels antiguos” o reinstalar cualquier cosa, decide qué importa:

• ¿Necesitas conservar el kernel roto para depuración posterior? Normalmente sí—al menos hasta que el nodo esté estable.
• ¿Tienes ZFS root? Entonces trata initramfs y el módulo ZFS como un sistema acoplado.
• ¿Ejecutas módulos DKMS del proveedor (controladoras HBA, NICs fuera del árbol)? Espera problemas de reconstrucción.

Regla operativa: tu primer objetivo al arrancar es consola estable + almacenamiento estable + red estable. La interfaz de Proxmox viene después.

Qué se rompió realmente cuando Proxmox no arranca

Una actualización del kernel no solo sustituye vmlinuz. Actualiza una familia de componentes estrechamente relacionados: imagen del kernel, initramfs, módulos bajo /lib/modules, controladores compilados por DKMS, entradas del bootloader y, a veces, microcódigo y bits EFI. Cualquiera de esos puede arruinarte la mañana.

Modos de fallo típicos tras una actualización del kernel

• El nuevo kernel arranca pero no encuentra el sistema root: controlador de almacenamiento faltante o módulo ZFS no presente en initramfs; root= incorrecto; generación de initramfs rota.
• Kernel panic durante el arranque temprano: a menudo incompatibilidad de módulos/ABI, initramfs corrupto o una compilación DKMS que falló silenciosamente.
• El menú GRUB existe pero solo muestra el kernel nuevo: kernels antiguos fueron eliminados, o /boot no se actualizó, o no se regeneró la configuración de GRUB.
• UEFI arranca al firmware / “No bootable device”: ESP no montada al actualizar, o entrada de arranque EFI perdida.
• Bucle de arranque: watchdog reinicia, panic seguido de reinicio automático, o systemd falla con kernel: panic y reinicio inmediato.
• El sistema arranca pero los servicios de Proxmox fallan: no es un fallo de arranque, pero sigue siendo inestabilidad posterior a la actualización (corosync, pveproxy, montajes de almacenamiento).

Aquí está la molesta verdad: la reversión con GRUB arregla síntomas, no causas. Pero te da un entorno limpio para reparar la causa sin operar en un shell initramfs.

Hechos interesantes y contexto histórico (porque ayuda a decidir)

1. GRUB 2 se convirtió en el predeterminado en Debian hace años en gran parte porque maneja escenarios de arranque complejos (LVM, RAID, múltiples kernels) mejor que el GRUB heredado.
2. Proxmox se basa en Debian, lo que significa que la mayoría de los “problemas de arranque de Proxmox” son problemas clásicos de kernel + initramfs + bootloader de Debian con una etiqueta PVE.
3. Initramfs no es teatro opcional: es un pequeño sistema de archivos cargado en RAM para montar el almacenamiento y el root. Si carece de los controladores correctos, el kernel no puede alcanzar tu root.
4. DKMS existe para reconstruir controladores entre kernels. Cuando falla, puedes obtener un kernel que arranca pero sin NIC, o peor, sin controlador de almacenamiento.
5. ZFS on Linux está fuera del árbol, lo que significa que es sensible a cambios de ABI del kernel. Un kernel nuevo más un módulo ZFS faltante equivale a “pool root no encontrado”.
6. UEFI hizo el arranque más flexible y más frágil: la ESP, las entradas NVRAM y múltiples implementaciones de proveedores añaden superficies de fallo.
7. Linux mantiene múltiples kernels instalados por diseño para que puedas revertir. La gente sabotea esa red de seguridad purgando agresivamente kernels “no usados”.
8. El empaquetado de kernel de Proxmox (pve-kernel) está ajustado para virtualización e incluye parches/características; mezclar kernels de repositorios aleatorios es pedir sorpresas.

Un consuelo seco: este fallo es lo bastante común como para que los pasos de recuperación sean, en su mayoría, aburridos. Y aburrido es bueno en producción.

Broma #1: Una actualización del kernel es como “solo un cambio rápido” en un firewall corporativo—nadie lo cree, pero todos fingen que sí.

Reversión vía GRUB (BIOS y UEFI) sin empeorar

Quieres el kernel antiguo porque probablemente coincide con el initramfs funcional y los módulos instalados. La reversión correcta es: seleccionar un kernel anterior, arrancar, confirmar estabilidad y luego hacerlo predeterminado temporalmente mientras arreglas el kernel roto.

Paso 1: llegar al menú GRUB de forma fiable

En muchos sistemas el menú GRUB está oculto salvo que algo vaya mal. Cuando ya hay un problema, a menudo aún tienes que ser rápido.

• BIOS: presiona y mantén Shift durante el arranque.
• UEFI: pulsa Esc (o a veces Shift) durante el arranque.
• IPMI/iKVM remoto: envía la tecla pronto; algunas consolas bufferizan mal.

Paso 2: elegir un kernel anterior de forma segura

En GRUB:

1. Selecciona Advanced options for Debian GNU/Linux (en Proxmox puede seguir poniendo Debian).
2. Selecciona la versión de kernel anterior (normalmente la que está debajo de la más nueva).
3. Prefiere la entrada normal, no “recovery mode”, a menos que la entrada normal falle.

¿Qué kernel debes escoger? En la práctica: el kernel más nuevo que funcionaba antes. Si actualizaste de 6.5 a 6.8 y 6.8 falla, elige 6.5. No retrocedas varios saltos mayores salvo que sea necesario; los kernels más antiguos pueden no coincidir con supuestos del espacio de usuario más recientes, y estás aquí para estabilizar, no para viajar en el tiempo.

Paso 3: cuando seleccionar kernel no es suficiente

Si la pantalla se pone negra o sospechas un problema de gráficos, prueba un parámetro temporal. En GRUB, resalta la entrada del kernel, pulsa e, encuentra la línea que empieza por linux, añade parámetros y arranca con Ctrl+x o F10.

Parámetros temporales útiles:

• nomodeset (problemas de transferencia del driver de vídeo; común en GPUs raras)
• systemd.unit=multi-user.target (saltarse targets gráficos; no suele ser relevante en servidores Proxmox, pero puede ayudar)
• debug o loglevel=7 (más verbosidad en logs del kernel)
• panic=30 (retrasar el reinicio por panic; te da tiempo para leer el error)

No “arregles” GRUB desde el editor de GRUB más allá de parámetros temporales. Si puedes arrancar un kernel antiguo, haz las reparaciones reales desde el sistema en ejecución.

Paso 4: hacer que el kernel antiguo sea el predeterminado (temporalmente)

Una vez que arranques con éxito, puedes fijar el kernel predeterminado configurando la entrada por defecto del menú GRUB. Esto evita reinicios accidentales al kernel roto mientras trabajas. Lo harás desde el SO, no desde menús del firmware.

Después de arrancar: confirmar, estabilizar y evitar una repetición

Arrancar no significa “resuelto”. Arrancar significa “podemos volver a respirar”. Ahora tienes que aprender por qué falló el kernel nuevo y decidir si lo reparas, lo retienes o lo eliminas.

Este es el modelo mental que te evita revolcarte sin rumbo:

• Si el kernel nuevo hace panic temprano: inspecciona el contenido de initramfs, módulos faltantes, disponibilidad de ZFS, problemas de microcódigo.
• Si arranca pero no tiene red: reconstrucción de módulos DKMS, paquetes de firmware, renombrado de interfaces o regresión del driver.
• Si arranca pero no puede importar ZFS: incompatibilidad de módulos ZFS, initramfs sin ZFS, o flags de características del pool.
• Si GRUB/UEFI es el problema: montaje de ESP, grub-install (BIOS) o recreación de entrada EFI (UEFI), y comprobaciones de coherencia.

Además: si esto ocurre en un entorno en clúster Proxmox, trata el nodo como “fuera de servicio” hasta que esté estable. Un nodo mediofuncional puede causar más daño que uno apagado, especialmente si empieza a provocar flapping en la membresía de corosync o en montajes de almacenamiento.

Broma #2: Nada une al equipo como todos mirando en silencio el arranque de un servidor—como si fuera una función en vivo.

Una cita para mantenerte honesto

“La esperanza no es una estrategia.” — General Gordon R. Sullivan

En términos de SRE: haz la reversión determinista, luego haz que el camino hacia adelante sea aburrido.

Particularidades de ZFS root y almacenamiento durante rollbacks de kernel

Si tu host Proxmox arranca desde ZFS, las actualizaciones del kernel pueden fallar de forma muy específica: el kernel arranca, initramfs se carga y luego no puede importar el rpool porque el módulo ZFS no está disponible (o no coincide con el kernel). Eso produce errores como “cannot import ‘rpool’: no such pool available” o “ZFS: module not found”, seguido de un shell de emergencia.

Por qué ZFS complica esto

• ZFS no está integrado en el árbol del kernel de Linux; es un módulo separado. Eso significa que debe compilarse para cada kernel.
• En ZFS root, el initramfs debe incluir los componentes ZFS para poder importar el pool temprano en el arranque.
• Los paquetes de Proxmox normalmente manejan esto, pero actualizaciones parciales, compilaciones DKMS rotas o una ESP no montada pueden crear escenarios de “kernel actualizado, initramfs no realmente actualizado”.

Enfoque seguro

Arranca con el último kernel conocido y bueno. Confirma que el pool se importa y los datasets se montan. Luego arregla el kernel roto reconstruyendo initramfs y asegurando que existan los módulos ZFS para él. Solo después permite que el sistema arranque con el kernel más nuevo otra vez.

Si tienes ZFS root y purgas kernels antiguos agresivamente, puedes quedarte atrapado: el único kernel que queda es el que necesita módulos ZFS que nunca se construyeron. Así es como conviertes un rollback de 10 minutos en una tarde de “arrancar desde ISO y chroot”.

Tareas prácticas (comandos, significados de salida, decisiones)

Abajo hay tareas reales que puedes ejecutar después de lograr arrancar (usualmente vía un kernel más antiguo). Cada una incluye: comando, qué significa la salida y la decisión que tomas.

Tarea 1: confirmar qué kernel estás ejecutando

cr0x@server:~$ uname -r
6.5.13-5-pve

Significado: Actualmente estás ejecutando 6.5.13-5-pve.

Decisión: Si este es el kernel conocido y bueno, mantenlo como referencia mientras reparas el nuevo. Si es el kernel nuevo, no retrocediste con éxito.

Tarea 2: listar kernels Proxmox instalados

cr0x@server:~$ dpkg -l 'pve-kernel-*' | awk '/^ii/ {print $2, $3}'
pve-kernel-6.5.13-5-pve 6.5.13-5
pve-kernel-6.8.12-3-pve 6.8.12-3

Significado: Ambos, el kernel antiguo y el nuevo, están instalados.

Decisión: Si solo está instalado el kernel roto, detente y considera instalar un paquete de kernel conocido y bueno antes de hacer cualquier otra cosa (posible vía chroot/rescate si no puedes arrancar).

Tarea 3: inspeccionar los últimos logs de arranque para saber por qué falló el kernel nuevo

cr0x@server:~$ journalctl -b -1 -p err --no-pager | tail -n 30
Dec 26 10:02:11 server kernel: zfs: module verification failed: signature and/or required key missing
Dec 26 10:02:11 server kernel: ZFS: Failed to load module
Dec 26 10:02:12 server systemd[1]: Failed to mount /.
Dec 26 10:02:12 server systemd[1]: Dependency failed for Initrd Root File System.

Significado: El arranque anterior (-1) tuvo fallo al cargar el módulo ZFS, así que el montaje del root falló.

Decisión: Esto apunta a Secure Boot/firma de módulos, fallo de compilación DKMS o initramfs sin ZFS. Investigarás esas causas específicas, no reinstalar GRUB al azar.

Tarea 4: comprobar si Secure Boot está en juego

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

Significado: Secure Boot de UEFI está habilitado.

Decisión: Si módulos fuera del árbol (ZFS, drivers del proveedor) no están firmados correctamente, pueden no cargarse. Debes inscribir claves/firmar módulos o deshabilitar Secure Boot (decisión de política). No “deshabilites” sin pensar si tu organización depende de ello.

Tarea 5: verificar que existan imágenes initramfs para cada kernel

cr0x@server:~$ ls -lh /boot | egrep 'vmlinuz|initrd.img' | tail -n 10
-rw-r--r-- 1 root root  78M Dec 25 21:14 initrd.img-6.5.13-5-pve
-rw-r--r-- 1 root root  82M Dec 25 21:16 initrd.img-6.8.12-3-pve
-rw-r--r-- 1 root root 8.6M Dec 25 21:14 vmlinuz-6.5.13-5-pve
-rw-r--r-- 1 root root 9.1M Dec 25 21:16 vmlinuz-6.8.12-3-pve

Significado: Ambos kernels tienen initramfs y vmlinuz presentes.

Decisión: La presencia no garantiza corrección, pero la ausencia es una señal clara: regenera initramfs y asegúrate de que /boot esté montado correctamente.

Tarea 6: confirmar que /boot y la partición del sistema EFI estén montadas (sistemas UEFI)

cr0x@server:~$ findmnt -no TARGET,SOURCE,FSTYPE /boot /boot/efi
/boot /dev/sda2 ext4
/boot/efi /dev/sda1 vfat

Significado: Ambos /boot y /boot/efi están montados.

Decisión: Si /boot/efi no está montado durante las actualizaciones de kernel, los binarios EFI de GRUB y las entradas NVRAM pueden desincronizarse. Arregla los montajes antes de volver a ejecutar update-grub o reinstalar piezas del bootloader.

Tarea 7: regenerar initramfs para el kernel roto

cr0x@server:~$ sudo update-initramfs -u -k 6.8.12-3-pve
update-initramfs: Generating /boot/initrd.img-6.8.12-3-pve
Running hook script 'zz-proxmox-boot'..

Significado: Initramfs regenerado para ese kernel exacto.

Decisión: Si falla con módulos faltantes o errores en hooks, detente y corrige esos errores antes de reiniciar. Una generación “exitosa” de initramfs es necesaria pero no suficiente; valida la presencia de módulos a continuación.

Tarea 8: comprobar disponibilidad del módulo ZFS para el kernel objetivo

cr0x@server:~$ ls /lib/modules/6.8.12-3-pve/updates/dkms/ 2>/dev/null | head
zfs.ko
zcommon.ko
znvpair.ko
zunicode.ko
zavl.ko

Significado: Existen módulos ZFS compilados por DKMS para el kernel nuevo.

Decisión: Si este directorio falta o está vacío, ZFS no se compiló para el kernel nuevo. Revisarás el estado de DKMS y los logs de compilación.

Tarea 9: inspeccionar el estado de DKMS y reconstruir si hace falta

cr0x@server:~$ dkms status
zfs/2.2.4, 6.5.13-5-pve, x86_64: installed
zfs/2.2.4, 6.8.12-3-pve, x86_64: built

Significado: Para el kernel nuevo, ZFS está solo “built” y no “installed” (o puede faltar por completo).

Decisión: Instálalo para ese kernel (o recompílalo). Un módulo “built” puede no haberse colocado en el árbol correcto.

cr0x@server:~$ sudo dkms install zfs/2.2.4 -k 6.8.12-3-pve
Installing to /lib/modules/6.8.12-3-pve/updates/dkms/
depmod...

Significado: DKMS instaló el módulo ZFS en el directorio de módulos del kernel nuevo y ejecutó depmod.

Decisión: Regenera initramfs otra vez para que contenga los bits necesarios.

Tarea 10: reconstruir entradas del menú GRUB

cr0x@server:~$ sudo update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.12-3-pve
Found initrd image: /boot/initrd.img-6.8.12-3-pve
Found linux image: /boot/vmlinuz-6.5.13-5-pve
Found initrd image: /boot/initrd.img-6.5.13-5-pve
done

Significado: La configuración de GRUB ahora contiene ambos kernels.

Decisión: Si no se encontró el kernel roto, o no lo tienes instalado, o /boot no estaba correcto. No reinicies hacia lo desconocido.

Tarea 11: establecer la entrada kernel predeterminada (pin temporal)

Primero, lista las entradas del menú con índices:

cr0x@server:~$ grep -n "menuentry '" /boot/grub/grub.cfg | head -n 8
105:menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-11111111-2222-3333-4444-555555555555' {
153:menuentry 'Advanced options for Debian GNU/Linux' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-advanced-11111111-2222-3333-4444-555555555555' {
161:menuentry 'Debian GNU/Linux, with Linux 6.8.12-3-pve' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-6.8.12-3-pve-advanced-11111111-2222-3333-4444-555555555555' {
199:menuentry 'Debian GNU/Linux, with Linux 6.5.13-5-pve' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-6.5.13-5-pve-advanced-11111111-2222-3333-4444-555555555555' {

Significado: Puedes referenciar una menuentry por título exacto o por ID de entrada guardada. Los títulos pueden cambiar; los IDs son más estables.

Decisión: Usa el mecanismo “saved” de GRUB para arranques predecibles y luego fija la entrada guardada al kernel conocido y bueno.

cr0x@server:~$ sudo sed -i 's/^GRUB_DEFAULT=.*/GRUB_DEFAULT=saved/' /etc/default/grub
cr0x@server:~$ sudo grub-set-default "Debian GNU/Linux, with Linux 6.5.13-5-pve"
cr0x@server:~$ sudo update-grub
Generating grub configuration file ...
done

Significado: GRUB arrancará por defecto con el kernel 6.5 hasta que lo cambies.

Decisión: Mantén el pin hasta que el kernel nuevo se verifique en una ventana de reinicio controlada.

Tarea 12: verificar servicios iniciados y salud del clúster (si aplica)

cr0x@server:~$ systemctl --failed --no-pager
UNIT                     LOAD   ACTIVE SUB    DESCRIPTION
0 loaded units listed.

Significado: No hay unidades systemd fallidas.

Decisión: Si ves unidades fallidas relacionadas con almacenamiento, red o servicios pve, arréglalas antes de reintroducir este nodo a cargas de producción.

cr0x@server:~$ pvecm status 2>/dev/null | egrep 'Quorate|Nodes|Name'
Name:             prod-cluster
Nodes:            3
Quorate:          Yes

Significado: El clúster es quórum y reconoce nodos.

Decisión: Si el nodo está aislado o provoca inestabilidad de membresía, mantenlo fuera e investiga red, configuración de corosync y sincronización de tiempo antes de continuar.

Tarea 13: confirmar salud del pool ZFS (ZFS root o pools de datos)

cr0x@server:~$ zpool status
  pool: rpool
 state: ONLINE
  scan: scrub repaired 0B in 00:09:12 with 0 errors on Sun Dec 22 02:10:12 2025
config:

        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sda3    ONLINE       0     0     0
            sdb3    ONLINE       0     0     0

errors: No known data errors

Significado: El almacenamiento está sano.

Decisión: Si los pools están degradados o no importados, no culpes la actualización del kernel automáticamente. Puede que hayas descubierto un problema real de disco/controladora que simplemente se manifestó durante el reinicio.

Tarea 14: comprobar entradas de arranque EFI si el firmware te lleva al setup

cr0x@server:~$ sudo efibootmgr -v | head -n 20
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0001,0002
Boot0001* UEFI: Built-in EFI Shell
Boot0002* UEFI PXE IPv4
Boot0003* debian	HD(1,GPT,aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee,0x800,0x32000)/File(\EFI\debian\grubx64.efi)

Significado: Hay una entrada EFI Debian/GRUB válida apuntando a \EFI\debian\grubx64.efi.

Decisión: Si falta la entrada Debian o apunta a un disco equivocado, la recrearás (con cuidado) después de confirmar el contenido de la ESP.

Tarea 15: validar el contenido de la ESP (UEFI)

cr0x@server:~$ sudo ls -R /boot/efi/EFI | head -n 40
/boot/efi/EFI:
BOOT
debian
proxmox

/boot/efi/EFI/debian:
grub.cfg
grubx64.efi
shimx64.efi

Significado: Existen archivos EFI. La presencia de shimx64.efi suele indicar soporte de Secure Boot.

Decisión: Si este directorio está vacío o falta, tu ESP no se montó durante las actualizaciones o fue sobrescrita. Necesitarás reinstalar los binarios EFI de GRUB y potencialmente recrear entradas NVRAM.

Tarea 16: comprobar espacio libre en /boot (silenciosamente mortal)

cr0x@server:~$ df -h /boot
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       512M  489M   23M  96% /boot

Significado: /boot está casi lleno.

Decisión: Un /boot lleno puede provocar escrituras parciales de initramfs o imágenes faltantes. Puede que necesites eliminar kernels antiguos—pero solo después de verificar que tienes al menos un kernel de reserva conocido e iniciable.

Tres microhistorias corporativas desde el terreno

1) El incidente causado por una suposición equivocada

El nodo era un hipervisor Proxmox perfectamente normal. ZFS root, un par de mirrors NVMe y un puñado pequeño de VMs críticas que la gente siempre insistía que eran “no críticas” hasta que estaban caídas. El equipo tenía la costumbre: aplicar actualizaciones a última hora de la tarde, reiniciar, irse a casa. Suele funcionar. “Suele” no es una estrategia.

En una ciclo de actualizaciones, el nodo no volvió. IPMI mostraba un kernel panic temprano en el arranque. Alguien asumió “GRUB debe estar corrupto” porque esa es la historia que todos recuerdan de 2012. Arrancaron con medios de rescate, reinstalaron GRUB y reiniciaron. Mismo panic. Luego reinstalaron GRUB otra vez, porque repetirse es una técnica de depuración reconocida en algunas industrias.

El problema real fue más simple: el initramfs del kernel nuevo no contenía el driver de la HBA que exponía el pool de arranque. El módulo existía en disco, pero nunca llegó al initramfs por un error en un hook durante la actualización—disparado por un /boot casi lleno. El kernel antiguo arrancó bien. El nuevo no encontró root. GRUB era inocente.

Una vez que revertieron vía GRUB al kernel anterior, la reparación llevó 15 minutos: liberar espacio en /boot, regenerar initramfs, validar la presencia de módulos y luego reiniciar en el kernel nuevo. La lección no fue “no actualizar”. La lección fue “no asumas que el fallo es el bootloader solo porque puedes ver el bootloader”.

2) La optimización que salió mal

En otro entorno había una cultura fuerte de “mantener las cosas limpias”. Ejecutaban un cron que purgaba kernels antiguos para mantener /boot ordenado y recuperar espacio. Alguien vio una vez una alerta sobre uso de /boot y decidió que la solución permanente era eliminar kernels “no usados”. Se ejecutó en todas partes. Era “estándar”. Nadie recordaba quién lo escribió.

Luego llegó una actualización de kernel que introdujo una regresión en el driver de la NIC primaria. El sistema arrancó, pero sin red. Eso habría sido molesto pero recuperable vía consola—salvo que el proceso de remote hands del DC requería acceso de red al plano de gestión para escalar. Su acceso fuera de banda existía, pero estaba atado a la misma red y pila de políticas. Diversión.

La reversión habría sido trivial si hubiera habido un kernel más antiguo para seleccionar en GRUB. No lo había. La “optimización” había reducido el margen de seguridad a cero. Tuvieron que arrancar desde medios de rescate, montar sistemas de archivos, instalar un kernel antiguo desde mirrors locales, reconstruir initramfs y luego reiniciar. Funcionó, pero consumió horas y atención de múltiples equipos, porque el procedimiento nunca se había practicado.

El postmortem no fue amable con el cron. Mantuvieron /boot bajo control después, pero con una regla: conservar al menos dos kernels conocidos y buenos instalados, siempre, y alertar sobre /boot lleno en lugar de purgar silenciosamente tu paracaídas.

3) La práctica aburrida pero correcta que salvó el día

Mismo tipo de fallo: tras una actualización del kernel, el host arrancó a un shell initramfs con “cannot mount root”. La diferencia fue la disciplina del equipo. No ejecutaron comandos al azar. Siguieron un pequeño runbook y trataron la consola como evidencia.

Primero, fotografiaron la pantalla y capturaron el error exacto. Luego reiniciaron y usaron GRUB para seleccionar el kernel anterior. Se arrancó con normalidad. Inmediatamente fijaron el kernel antiguo como predeterminado en GRUB para evitar reinicios accidentales al kernel roto, y pusieron el nodo en modo mantenimiento para que no aceptara cargas.

Luego hicieron la parte poco épica: comprobar si /boot y /boot/efi estaban montados, comprobar espacio libre, comprobar estado de DKMS, reconstruir initramfs para el kernel nuevo y confirmar que existían los módulos ZFS para ese kernel. Solo entonces probaron reiniciar en el kernel nuevo durante una ventana controlada.

No pasó nada heroico. Ningún truco ingenioso. Solo secuencia cuidadosa y sesgo por acciones reversibles. Así es como se ve la “ingeniería de fiabilidad” cuando funciona.

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

1) Síntoma: GRUB aparece, pero al arrancar el kernel nuevo cae a shell de emergencia

Causa raíz: initramfs sin controladores de almacenamiento o módulo ZFS; DKMS no instaló los módulos para el kernel nuevo; /boot lleno generó imágenes parciales.

Solución: arranca kernel antiguo; asegúrate de espacio en /boot; ejecuta dkms status; instala módulos faltantes para el kernel nuevo; regenera initramfs para ese kernel; ejecuta update-grub; prueba.

2) Síntoma: “ZFS: module not found” o el pool no se importa durante el arranque

Causa raíz: módulos ZFS no compilados/instalados para el kernel nuevo, o bloqueados por política de firma de Secure Boot.

Solución: arranca kernel antiguo; recompila/instala ZFS DKMS para el kernel objetivo; regenera initramfs; si Secure Boot está activado, asegúrate de firma/inscripción de claves o ajusta la política.

3) Síntoma: después de la actualización, el firmware dice “no bootable device”

Causa raíz: entrada NVRAM UEFI perdida; ESP corrupta; ESP no montada durante la actualización y archivos de arranque no están donde el firmware los espera.

Solución: confirma montaje de la ESP; inspecciona /boot/efi/EFI; recrea la entrada de arranque con efibootmgr si es necesario; reinstala binarios GRUB EFI desde el sistema en ejecución o chroot.

4) Síntoma: el sistema arranca pero no tiene red

Causa raíz: regresión del driver NIC; paquete de firmware faltante; driver DKMS falló; nombre de interfaz cambiado por orden PCI/firmware.

Solución: arranca kernel antiguo; compara salidas de ip link entre kernels; comprueba journalctl -k por errores de carga de drivers; reinstala paquetes de firmware; reconstruye DKMS; ajusta /etc/network/interfaces si cambiaron nombres de interfaz.

5) Síntoma: el menú GRUB solo tiene una entrada (el kernel roto)

Causa raíz: kernels antiguos purgados; no se ejecutó update-grub; /boot no montado; imágenes de kernel faltantes.

Solución: desde rescue o chroot, instala al menos un kernel conocido y bueno; asegúrate de que /boot esté montado; ejecuta update-grub. Deja de purgar kernels sin una política que preserve la reversión.

6) Síntoma: pantalla negra tras GRUB, pero ventiladores giran y discos parpadean

Causa raíz: transferencia del framebuffer/hand-off gráfico; consola serial mal configurada; el arranque continúa pero no puedes verlo.

Solución: prueba nomodeset; verifica configuraciones IPMI Serial-over-LAN; establece parámetros de consola del kernel de forma persistente si dependes de serial. Confirma mediante accesibilidad de red desde otro host.

Listas de verificación / plan paso a paso

Lista A: recuperar el nodo ahora mismo (riesgo mínimo)

1. Accede al sistema por consola/IPMI. No adivines remotamente.
2. Forzar menú GRUB (Shift para BIOS, Esc para UEFI).
3. Selecciona Advanced options, arranca el último kernel conocido y bueno.
4. Confirma la versión del kernel con uname -r.
5. Confirma salud del almacenamiento (ZFS: zpool status; no ZFS: comprueba montajes).
6. Confirma que la red está lo bastante arriba para acceso de gestión.
7. Fija el kernel conocido y bueno como predeterminado usando la entrada guardada de GRUB.

Lista B: reparar el kernel roto (para que puedas actualizar con seguridad)

1. Comprueba que /boot y /boot/efi están montados y tienen espacio.
2. Inspecciona los últimos logs de arranque fallido (journalctl -b -1 -p err).
3. Si ZFS/DKMS está implicado: revisa dkms status y los archivos de módulos bajo /lib/modules/<nuevo-kernel>.
4. Reconstruye/initramfs para el kernel objetivo: update-initramfs -u -k <version>.
5. Ejecuta update-grub y asegúrate de que encuentre kernel + initrd.
6. Si hay problemas UEFI: valida entradas EFI con efibootmgr -v y el contenido de la ESP.
7. Programa un reinicio controlado al kernel nuevo. Quédate en la consola. Captura la salida si falla.

Lista C: endurecer contra la próxima vez

1. Mantén al menos dos kernels arrancables instalados. Trátalo como política, no preferencia.
2. Monitorea uso de /boot y alerta antes de que llegue al 90%.
3. Para ZFS root: asegura que los módulos ZFS se compilen para nuevos kernels antes de reiniciar (comprobaciones DKMS en tu proceso de cambios).
4. Decide la política de Secure Boot: o soportas firma de módulos correctamente o lo deshabilitas intencionalmente. A medio camino viven las interrupciones.
5. Prueba actualizaciones de kernel en un nodo similar primero (el hardware importa para drivers).

Preguntas frecuentes

1) ¿Revertir vía GRUB es “la forma correcta” o solo un apaño?

Es la forma correcta. Usa el mecanismo diseñado para esto: múltiples kernels instalados con un menú del bootloader. El apaño es borrar todos los kernels antiguos.

2) ¿Por qué Proxmox dejó de arrancar si la misma actualización funcionó en otro nodo?

Diferencias de hardware. Diferentes HBAs, NICs, GPUs, versiones de firmware, estados de Secure Boot y diseños de ESP. Los kernels son educados hasta que se encuentran con tu dispositivo PCI específico.

3) ¿Debo eliminar el paquete del kernel roto?

No de inmediato. Primero estabiliza en el kernel antiguo, recopila logs y trata de reparar el kernel nuevo (initramfs + DKMS + ESP). Elimínalo solo si estás seguro de que es irrecuperable para tu hardware o necesitas espacio en /boot.

4) ¿Cuántos kernels debo mantener instalados?

Al menos dos kernels arrancables (estable actual y anterior). En hosts críticos, tres no es una locura—especialmente si tienes ventanas de cambio ajustadas.

5) Mi menú GRUB no aparece. ¿Cómo forzarlo permanentemente?

En un sistema en ejecución puedes ajustar la configuración de GRUB (por ejemplo, reducir timeout o mostrar el menú). Operativamente prefiero mantener el menú mayormente oculto y confiar en acceso por consola cuando sea necesario. Si necesitas verlo siempre para remote hands, configura un timeout mayor y evita el arranque “quiet” hasta estar estable.

6) Estoy en ZFS root. ¿Necesito pasos especiales?

Sí: verifica que los módulos ZFS existan para el kernel objetivo y que initramfs los incluya. Si ZFS no puede cargarse al arranque, tu pool root no se importará y acabarás en un shell initramfs.

7) ¿Puede Secure Boot bloquear ZFS u otros módulos tras una actualización del kernel?

Sí. Secure Boot puede impedir la carga de módulos de kernel no firmados. Si tus logs mencionan fallos de verificación de firma, trátalo como un desajuste de política, no como un fallo aleatorio de arranque.

8) El sistema arranca con el kernel antiguo, pero los servicios de Proxmox se ven raros. ¿Qué hago ahora?

Comprueba unidades fallidas y el estado del clúster. Un reinicio puede exponer problemas no relacionados: pools ZFS degradados, deriva de tiempo, flaps de red de corosync. Arregla la salud de la plataforma primero y luego vuelve a preocuparte por actualizar.

9) Si /boot está lleno, ¿puedo eliminar manualmente archivos initrd?

No. Elimina paquetes de kernel mediante el gestor de paquetes para que los hooks actualicen GRUB e initramfs correctamente. La eliminación manual crea menús de arranque apuntando a archivos ausentes—una manera emocionante de provocar una segunda interrupción.

10) ¿Cuándo debo usar medios de rescate?

Cuando GRUB no puede arrancar ningún kernel, cuando la ESP falta/corrupta o cuando purgaste todos los kernels funcionales. Los medios de rescate están bien; son solo más lentos y más fáciles de estropear si no los has practicado.

Conclusión: siguientes pasos que realmente reducen el riesgo

Si tu host Proxmox no arranca tras una actualización del kernel, el camino limpio es: usar GRUB para arrancar el kernel previo, fijarlo como predeterminado, luego reparar el kernel nuevo arreglando initramfs, los módulos DKMS (especialmente ZFS) y la coherencia EFI/ESP. Reinicia en el kernel nuevo solo cuando puedas ver la consola y hayas eliminado minas obvias como un /boot lleno.

Haz esto a continuación, en orden:

1. Mantén el kernel conocido y bueno como predeterminado hasta que la actualización esté probada.
2. Captura los errores del último arranque fallido (journalctl -b -1) y úsalos como hoja de ruta.
3. Haz que /boot sea aburrido: suficiente espacio, montajes correctos y una regla para conservar kernels de reversión.
4. Para ZFS root: verifica que los módulos ZFS estén instalados para cada kernel nuevo antes de reiniciar.
5. Escribe un pequeño runbook interno a partir de este incidente. La próxima vez debería llevar minutos, no horas.

Los sistemas de producción no exigen perfección. Exigen recuperación repetible. La reversión con GRUB es tu recuperación repetible—úsala con intención.