Tutoriales de VPS
Qué hacer ante un Kernel Panic en un VPS (2026): guía de diagnóstico con kdump, vmcore, journalctl y crash
El VPS se reinicia solo de repente, la consola muestra un Kernel panic, no puedes entrar por SSH o los registros contienen kernel oops/call trace. Las causas comunes incluyen anomalías en módulos/drivers del kernel, problemas de sistema de archivos o partición raíz, errores de hardware de memoria/CPU, fallos en cadena tras OOM y desajuste de initramfs tras una actualización del kernel. Este artículo diagnostica capa por capa usando los registros del arranque anterior, dmesg, kdump, vmcore, crash y las evidencias para el ticket del proveedor.
Cuando un VPS sufre un Kernel Panic, la primera reacción de muchas personas es: ¿se ha roto la máquina? ¿Se ha caído el proveedor?
En la consola puede quedar solo una pantalla en inglés:
Kernel panic - not syncing
Unable to mount root fs
Oops: 0000 [#1]
Call Trace:
RIP: 0010:...
O quizá no viste la pantalla de panic en absoluto, y solo notaste que el VPS se reinició solo de repente, el servicio se interrumpió y, tras reconectar por SSH, los registros estaban cortados. En este momento no mires solo los registros de la aplicación. Un Kernel Panic es un fallo a nivel del kernel, así que el foco del diagnóstico está en los registros del arranque anterior, el ring buffer del kernel, los volcados de fallo y las evidencias del host/disco en la nube/drivers.
Este artículo lo explica con claridad para el escenario de VPS: primero confirmar si realmente es un kernel panic, luego determinar si es el sistema de archivos, la memoria, los drivers, una actualización del kernel o un problema subyacente del proveedor, y por último explicar cuándo necesitas configurar kdump y cómo presentar las evidencias al proveedor.
Cuando un servicio se cae, el sistema sigue vivo; un Kernel Panic es cuando el propio kernel del sistema no aguanta.
Primero revisa los registros de reinicio:
last -x reboot shutdown | head -n 20
Luego revisa los registros de error del arranque anterior:
journalctl -b -1 -p err --no-pager
Si el sistema admite journal persistente, también puedes ver el registro completo del kernel del arranque anterior:
journalctl -k -b -1 --no-pager
Qué buscar en concreto:
journalctl -k -b -1 --no-pager | grep -Ei 'panic|oops|call trace|not syncing|segfault|mce|i/o error|ext4|xfs'
Si solo ves que un servicio failed, eso no es necesariamente un kernel panic. Puedes leer primero: Cómo leer los registros de un VPS (journalctl, systemctl, Nginx, registros de aplicación).
No necesitas leer los registros de Kernel Panic palabra por palabra; primero captura las palabras clave.
Este es un kernel panic explícito. Las causas comunes incluyen:
- Fallo al montar el sistema de archivos raíz
- Anomalías en módulos críticos del kernel
- El proceso init no puede arrancar
- El kernel encuentra un error irrecuperable
Esto suele estar relacionado con el disco de arranque, initramfs, fstab, una actualización del kernel o el sistema de archivos.
Escenarios comunes:
- initramfs no se generó bien tras actualizar el kernel
/booto la partición raíz presentan anomalías- Cambió el nombre del dispositivo del disco en la nube
- Corrupción del sistema de archivos
Si además ves sistema de archivos de solo lectura, fsck o emergency mode, puedes consultar: Qué hacer cuando un VPS se convierte en un sistema de archivos de solo lectura.
Oops no provoca necesariamente un panic inmediato, pero indica que el kernel encontró una anomalía grave. Call Trace es la pila de llamadas, que ayuda a localizar qué módulo o driver tiene problemas.
Por ejemplo:
Oops: 0000 [#1] SMP PTI
Call Trace:
? some_driver_function+0x...
RIP: 0010:...
Si en la pila aparece repetidamente el nombre de un módulo, un sistema de archivos, un driver de tarjeta de red o un módulo de kernel de terceros, ese es el foco del diagnóstico.
Si ves:
Machine Check Exception
Hardware Error
MCE
Este tipo de registro suele apuntar a un problema de hardware o a nivel del host. Los usuarios de VPS no pueden cambiar directamente la memoria o la CPU, pero pueden enviar los registros al proveedor para que revise el hardware del host, migre el nodo o reemplace la instancia.
Cuando el sistema actual sigue vivo, puedes ver:
dmesg -T | grep -Ei 'panic|oops|call trace|mce|hardware error|i/o error|ext4|xfs'
Pero si la máquina ya ha sufrido un panic y se ha reiniciado, dmesg normalmente solo contiene los registros del kernel desde este arranque. Para ver el arranque anterior, usa preferentemente:
journalctl -k -b -1
Esto requiere que el journal persistente esté habilitado. Si /var/log/journal no existe, muchos sistemas solo guardan los registros del arranque actual. Puedes habilitar la persistencia:
sudo mkdir -p /var/log/journal
sudo systemctl restart systemd-journald
Esto no te ayudará a recuperar un panic antiguo que ya se perdió, pero hará que el próximo fallo sea más fácil de rastrear.
Los Kernel Panics suelen ocurrir tras una actualización del kernel, especialmente cuando:
- El disco se llenó durante la actualización
/bootse quedó sin espacio- Falló la generación de initramfs
- Se usa un módulo de terceros incompatible
- La combinación de una imagen de VPS antigua y un kernel nuevo es inestable
Revisa los registros de instalación recientes:
grep -i 'install\|upgrade' /var/log/dpkg.log | tail -n 50
En Debian / Ubuntu también puedes ver el historial de apt:
grep -i kernel /var/log/apt/history.log
Ver el kernel actual:
uname -a
Listar los kernels instalados:
dpkg -l | grep 'linux-image'
Si puedes entrar en GRUB a través de la consola del proveedor, puedes intentar arrancar con un kernel antiguo. No borres los kernels antiguos de inmediato; conserva al menos una versión que hayas confirmado que arranca.
Un Kernel Panic no es necesariamente un bug del propio kernel. Los errores de la partición raíz, del disco en la nube o del sistema de archivos también pueden arrastrar al sistema a un panic.
Busca errores de E/S y del sistema de archivos en los registros del kernel:
journalctl -k -b -1 --no-pager | grep -Ei 'i/o error|buffer error|blk_update|ext4|xfs|remount|read-only'
Si ves muchos:
Buffer I/O error on dev vda
EXT4-fs error
XFS metadata I/O error
Debes sospechar primero del disco en la nube, del sistema de archivos o del almacenamiento del host. En este momento no te limites a reiniciar. Haz una copia de seguridad mientras los datos sean legibles y, si es necesario, entra en rescue mode para ejecutar fsck o migrar a un disco nuevo.
Los usuarios de VPS no pueden ver el hardware del host, pero los registros del kernel a veces revelan pistas.
Busca errores de hardware:
journalctl -k -b -1 --no-pager | grep -Ei 'mce|machine check|hardware error|edac|memory error'
Si aparecen MCE o errores de hardware, no se recomienda intentar arreglarlo por tu cuenta dentro del sistema. Deberías:
- Guardar los registros.
- Registrar la hora y la zona horaria en que ocurrió.
- Enviar un ticket al proveedor.
- Solicitar que revisen el hardware del host, migren el VPS o cambien el nodo.
Si además ves steal time alto, fluctuaciones del disco y varios usuarios del mismo nodo afectados, puedes combinarlo con: Cómo saber si un VPS está sobrevendido.
El comportamiento predeterminado tras un Kernel Panic depende de la configuración del sistema. Algunos sistemas se quedan en la pantalla de panic, otros se reinician automáticamente.
Ver la configuración:
sysctl kernel.panic
Si quieres que se reinicie automáticamente 10 segundos después de un panic:
sudo sysctl -w kernel.panic=10
Configuración permanente:
echo 'kernel.panic = 10' | sudo tee /etc/sysctl.d/99-kernel-panic.conf
sudo sysctl --system
Nota: el reinicio automático puede reducir el tiempo de inactividad, pero también puede ocultar la escena. En sistemas de producción se recomienda combinarlo con alertas de monitorización y kdump, no depender solo del reinicio automático.
Si los Kernel Panics se repiten pero no se ve la causa raíz en los registros, necesitas kdump.
La función de kdump es: cuando el sistema falla, conservar un archivo de volcado de memoria vmcore, y luego analizarlo con la herramienta crash.
Instalación en Debian / Ubuntu:
sudo apt install kdump-tools crash linux-crashdump -y
RHEL / Rocky / AlmaLinux:
sudo dnf install kexec-tools crash -y
Tras habilitarlo, confirma si existe el parámetro crashkernel:
cat /proc/cmdline | grep crashkernel
Si kdump funciona correctamente:
systemctl status kdump-tools
systemctl status kdump
El nombre del servicio varía según la distribución. Cuando la memoria del VPS es muy pequeña, reservar crashkernel ocupa parte de la memoria, así que hay que tener cuidado en máquinas pequeñas de menos de 1 GB.
Si se genera correctamente un vmcore, la ruta habitual puede ser:
/var/crash/
/var/lib/systemd/coredump/
/var/crash/127.0.0.1-YYYY-MM-DD-...
Para analizar con crash se necesita:
- El archivo vmcore
- El vmlinux / debug symbols del kernel correspondiente
El comando básico es similar a:
sudo crash /usr/lib/debug/boot/vmlinux-$(uname -r) /var/crash/vmcore
Tras entrar en crash, puedes usar:
bt
log
ps
kmem -i
sys
Para la mayoría de los usuarios de VPS, no es necesario entender completamente la salida de crash por su cuenta. Un enfoque más realista es: confirmar que el vmcore se ha generado y presentar la información clave junto con el ticket del proveedor. Para los equipos de negocio autogestionados, al menos se puede ver en bt y log si está relacionado con algún módulo, sistema de archivos, driver o error de memoria.
No escribas solo: "La máquina ha tenido un Kernel Panic, por favor, encárguense de ello".
Un contenido de ticket mejor:
故障时间：2026-05-25 10:18 Asia/Shanghai
现象：VPS 自动重启，业务中断约 2 分钟
实例 ID：xxx
系统：Ubuntu 24.04 / kernel xxx
已确认：
- last -x 显示异常 reboot
- journalctl -k -b -1 中出现 Kernel panic / Call Trace
- dmesg 中有/无 I/O error
- MCE/Hardware Error 有/无
附件：
- journalctl -k -b -1 输出
- last -x reboot shutdown 输出
- vmcore（如有）
Si en los registros hay I/O error, MCE o anomalías de recursos del host, solicita explícitamente al proveedor que revise el host, el disco en la nube y las posibilidades de migración.
Cuando te encuentres con un Kernel Panic o un reinicio anómalo de un VPS, revisa en este orden:
last -x reboot shutdownpara confirmar la hora del reinicio anómalo.journalctl -b -1 -p errpara ver los errores del arranque anterior.journalctl -k -b -1para buscarpanic/oops/call trace/mce/i/o error.- Comprobar si se actualizó recientemente el kernel, initramfs o módulos de terceros.
- Buscar errores del sistema de archivos y del disco en la nube:
ext4/xfs/i/o error/read-only. - Buscar errores de hardware:
mce/machine check/hardware error. - Si es necesario, configurar
kernel.panic=10para reducir el tiempo de inactividad. - Si se repite, configurar kdump y recopilar vmcore.
- Usar crash para obtener la información básica de
bt/log/sys. - Abrir un ticket con el proveedor con la línea de tiempo completa y los registros.
Un Kernel Panic no es una caída normal de una aplicación. Normalmente significa que ha ocurrido un problema irrecuperable a nivel del kernel, del sistema de archivos, del disco en la nube, del driver, del hardware o del host.
Primero usa journalctl -k -b -1 y last -x para reconstruir la línea de tiempo, y luego usa las palabras clave para distinguir entre sistema de archivos, actualización del kernel, errores de hardware MCE y anomalías de drivers. Un panic puntual se puede observar primero; si se repite, hay que configurar kdump para conservar el vmcore y presentar las evidencias al proveedor. No te limites a reiniciar para ocultar el problema, porque la próxima vez puede ocurrir en horas de máxima actividad.