Pánico del kernel: cuando Linux dice “nope” en público

Qué es realmente un kernel panic (y qué no lo es)

Un pánico del kernel de Linux es el kernel admitiendo que no puede continuar de forma segura. No es “la aplicación se cerró”. No es “la máquina está lenta”. Es el núcleo del sistema operativo decidiendo que seguir podría corromper datos, perder la seguridad de la memoria o quedar bloqueado de forma permanente. Así que se detiene.

Los panics son deliberados. Normalmente son provocados por una ruta de código que llama a panic() (o por una excepción irrecuperable que lleva allí). El kernel imprime lo que sabe, con frecuencia incluyendo un backtrace, el estado de CPU y la razón (a veces útil, a veces insultante). A menudo verás uno de estos:

• “Kernel panic – not syncing: Attempted to kill init!” — PID 1 murió o quedó irrecuperable.
• “Kernel panic – not syncing: VFS: Unable to mount root fs” — el kernel no puede montar el sistema de archivos raíz.
• “Fatal exception in interrupt” — algo falló en un mal momento.
• “BUG: unable to handle kernel NULL pointer dereference” — bug del kernel o mal comportamiento de un driver, quizá corrupción de hardware.
• “soft lockup” / “hard lockup” — CPU atascada, el watchdog puede escalar a panic según la configuración.

Qué no es:

• OOM kill — que el kernel mate un proceso por presión de memoria es un comportamiento normal. Perdiste una carga de trabajo, no el kernel. Un panic causado por OOM es raro y normalmente viene por configuración.
• Caída de espacio de usuario — systemd, java, nginx, tu script “crítico” en Python… ninguno de esos es un kernel panic. Importantes, pero herramientas diferentes.
• Reinicio de hardware — un reinicio súbito sin registros puede ser por energía, watchdog del BMC o un triple fault. Trátalo diferente hasta que se demuestre lo contrario.

Y sí, los panics tienden a ocurrir en público—durante despliegues, ventanas de mantenimiento y demos ejecutivas. El kernel tiene un impecable sentido del timing cómico.

Una cita que vale la pena tener en el escritorio: “parafraseada” — John Allspaw: la confiabilidad viene de diseñar sistemas que asumen fallos, no de esperar que no ocurran.

Broma #1: Un kernel panic es la única vez que tu servidor es realmente honesto sobre sus sentimientos: “I can’t even.”

Datos interesantes y un poco de historia

El contexto importa porque mucho del comportamiento de los panics es equipaje histórico: valores por defecto antiguos, promesas de compatibilidad y décadas de “esto está bien” apiladas sobre “esto está en llamas”. Aquí hay hechos concretos que aparecen en investigaciones reales:

1. “Panic” es anterior a Linux. Los kernels UNIX usaban rutas de panic para detener el sistema ante riesgos de corrupción mucho antes de que existiera Linux.
2. Linux mantiene el mensaje directo a propósito. El kernel imprime directamente en consolas y líneas seriales porque esas suelen funcionar cuando nada más lo hace.
3. SysRq es una herramienta de supervivencia, no un juguete. Las teclas Magic SysRq existieron para recuperar el control durante bloqueos; sigue siendo una de las pocas herramientas de último recurso cuando el espacio de usuario está frito.
4. kdump no siempre fue algo mainstream. El volcado por crash maduró con los años; depurar Linux temprano a menudo significaba “reproducir bajo consola serial” y dolor.
5. “Oops” no es “panic”. Un oops es una excepción del kernel que puede permitir continuar; un panic es el kernel negándose a seguir. Los equipos tratan los oops repetidos como pre-panics.
6. Los watchdogs pueden forzar panics. Los watchdogs de soft/hard lockup existen porque los bloqueos silenciosos son peores que muertes ruidosas en producción.
7. initramfs hizo el arranque mejor y peor a la vez. Permite un arranque modular y userspace temprano, pero también añade una nueva zona de fallos: drivers faltantes, UUIDs equivocados, hooks rotos.
8. Módulos fuera del árbol son un multiplicador de riesgo conocido. Drivers propietarios y módulos que no siguen la API interna del kernel son fuentes frecuentes de “funciona hasta que deja de funcionar”.
9. El almacenamiento moderno es un campo minado adyacente al kernel. NVMe, multipath, iSCSI, RDMA y sistemas de archivos como ZFS aportan rendimiento y complejidad. A la complejidad le encanta provocar panics a las 3 a.m.

Cuaderno de juego para diagnóstico rápido

Esta es la secuencia “detener la hemorragia”. La haces de la misma forma cada vez, incluso cuando Slack está gritando. Especialmente cuando Slack está gritando.

Primero: determina si fue un panic, un reset o un evento de alimentación

• ¿Hubo un mensaje de panic en la consola/IPMI? Si sí, probablemente fue un panic real.
• ¿Tienes un vmcore? Si sí, fue una ruta de crash relativamente controlada (panic o kdump activado).
• ¿No hay registros en absoluto? Sospecha primero de energía, watchdog de firmware, reinicio del BMC o fallo hardware.

Segundo: clasifica el panic en una frase

Quieres una etiqueta rápida que guíe los siguientes pasos:

• Pánico de arranque: VFS no puede montar root, problemas con initramfs, cmdline del kernel equivocado.
• Pánico en tiempo de ejecución: bug de driver, bug de sistema de archivos, corrupción de memoria, watchdog de lockup.
• Pánico en la ruta de datos: timeouts de almacenamiento, resets NVMe, firmware HBA, tormentas de multipath, fallos de ZFS.
• Hardware de memoria/CPU: MCEs, errores EDAC, oops aleatorios en subsistemas no relacionados.

Tercero: elige la fuente de evidencia más rápida

• Mejor: vmcore + símbolos de depuración vmlinux coincidentes.
• Bueno: journal persistente + salida de consola de panic + dmesg del arranque anterior.
• Aceptable: SEL del BMC, registros de consola serial, netconsole.
• Malo: “se reinició, nadie vio nada.” (Eso lo arreglarás después.)

Cuarto: decide si mantener el nodo en línea

• Evento aislado y sin riesgo de corrupción: reanudar, capturar registros y planear análisis más profundo.
• Repetido o pánico en ruta de almacenamiento: aislar el nodo. Prioriza prevenir daño en el sistema de archivos y fallos en cascada.
• Posibles errores de memoria hardware: sacarlo del servicio. No ejecutes cargas críticas en una máquina que podría mentir sobre bits.

Capturar la evidencia: hacer los panics diagnósticables

Los panics rara vez son “uno y fuera”. El kernel hizo panic por una razón. Tu trabajo es asegurarte de que el siguiente deje un cuerpo.

Kdump: la diferencia entre adivinar y saber

kdump reserva memoria para un kernel de crash. Cuando el kernel principal entra en panic, arranca el kernel de crash y escribe un volcado vmcore. Ese volcado es grande, lento y merece la pena.

Modo de fallo común: “habilitaste kdump” pero nunca lo probaste, así que cuando ocurre el panic real no escribe nada. Eso no es un fallo de monitorización; es un fallo de liderazgo.

Registros persistentes: journal y consola

Haz que el sistema conserve registros entre reinicios. También captura la salida del kernel en algún lugar que sobreviva: registro de consola serial, captura SOL del BMC, netconsole o pstore.

Nota para ingenieros de almacenamiento: los panics pueden ser autoinfligidos

Si tu filesystem raíz vive sobre una pila de almacenamiento compleja (dm-crypt + LVM + mdraid + multipath + iSCSI + thin provisioning), tu ruta de arranque es una máquina de Rube Goldberg. Puede funcionar. También puede fallar de maneras emocionantes.

Broma #2: Arrancar desde almacenamiento en red es como confiar en un paracaídas empaquetado por un comité—posible, pero quieres una lista de verificación.

Tareas prácticas: comandos, salidas, decisiones (12+)

Estas son tareas reales de “haz esto ahora”. Cada una incluye qué estás mirando y qué decisión tomas a partir de eso.

Task 1: Confirmar que el arranque anterior falló y por qué (journal)

cr0x@server:~$ journalctl -b -1 -k -p err..alert --no-pager | tail -n 40
Jan 21 02:13:19 server kernel: BUG: unable to handle page fault for address: ffff8a0a00000000
Jan 21 02:13:19 server kernel: #PF: supervisor read access in kernel mode
Jan 21 02:13:19 server kernel: Kernel panic - not syncing: Fatal exception
Jan 21 02:13:19 server kernel: CPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.1.0-18-amd64 #1 Debian 6.1.76-1
Jan 21 02:13:19 server kernel: Call Trace:
Jan 21 02:13:19 server kernel:  ? nvme_complete_rq+0x2a/0xd0
Jan 21 02:13:19 server kernel:  ? blk_mq_end_request+0x2b/0x60

Qué significa: El arranque previo terminó con una excepción del kernel escalando a panic. El stack menciona la ruta de finalización NVMe.

Decisión: Trátalo como un panic en tiempo de ejecución probablemente en el driver/firmware de almacenamiento. Aísla el nodo si es parte de un clúster; no lo reinicies y lo olvides.

Task 2: Comprobar razón de reinicio e IDs de arranque (sanidad rápida)

cr0x@server:~$ last -x | head -n 8
reboot   system boot  6.1.0-18-amd64 Tue Jan 21 02:15   still running
crash    system crash 6.1.0-18-amd64 Tue Jan 21 02:13 - 02:15  (00:02)
reboot   system boot  6.1.0-18-amd64 Mon Jan 20 22:01 - 02:13  (04:12)

Qué significa: “crash” indica un apagado no limpio consistente con panic o reset.

Decisión: Si “crash” coincide con las líneas de panic del journal, procede con análisis del kernel. Si el journal está vacío, pivota a investigar reset de hardware/firmware.

Task 3: Ver si kdump produjo un vmcore

cr0x@server:~$ ls -lh /var/crash
total 2.3G
drwxr-xr-x 2 root root 4.0K Jan 21 02:15 127.0.1.1-2026-01-21-02:15:08

Qué significa: Existe un directorio de crash; probablemente contiene vmcore y metadatos.

Decisión: Presérvalo. Cópialo fuera del nodo antes de que los trabajos de “limpieza” se ejecuten o alguien reimagee el servidor.

Task 4: Validar el estado del servicio kdump (y si estaba armado)

cr0x@server:~$ systemctl status kdump-tools --no-pager
● kdump-tools.service - Kernel crash dump capture service
     Loaded: loaded (/lib/systemd/system/kdump-tools.service; enabled)
     Active: active (exited) since Tue 2026-01-21 02:16:01 UTC; 3min ago
       Docs: man:kdump-tools(8)
    Process: 612 ExecStart=/etc/init.d/kdump-tools start (code=exited, status=0/SUCCESS)

Qué significa: El servicio está habilitado y parece saludable ahora. Eso no prueba que funcionara en el momento del crash, pero es un comienzo.

Decisión: Si está deshabilitado o fallido, prioriza hacer los dumps confiables antes de perseguir la causa raíz. Sin dump, no hay certeza.

Task 5: Confirmar que la reserva crashkernel realmente existe

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.1.0-18-amd64 root=UUID=8b2c1d90-0a0f-4db3-bf90-4b3d6f1c2f3e ro quiet crashkernel=512M

Qué significa: Memoria reservada para crash kernel vía línea de comando del kernel.

Decisión: Si falta, añádela y reinicia en una ventana de mantenimiento. De lo contrario tu historia de “kdump habilitado” es ficción.

Task 6: Buscar Machine Check Exceptions (canarios hardware)

cr0x@server:~$ journalctl -k -b -1 | egrep -i "mce|machine check|hardware error|edac" | tail -n 20
Jan 21 02:12:57 server kernel: mce: [Hardware Error]: Machine check events logged
Jan 21 02:12:57 server kernel: EDAC MC0: 1 CE memory scrubbing error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#0

Qué significa: Ocurrieron errores ECC corregidos. Un error corregido no es una condena instantánea; los patrones sí lo son.

Decisión: Si ves errores corregidos repetidos o cualquier error no corregido, trátalo como fallo de hardware. Abre un ticket con el proveedor y saca el nodo de cargas críticas.

Task 7: Inspeccionar patrones de error PCIe/NVMe antes del panic

cr0x@server:~$ journalctl -k -b -1 | egrep -i "nvme|pcie|aer|reset|timeout" | tail -n 40
Jan 21 02:12:58 server kernel: nvme nvme0: I/O 487 QID 7 timeout, aborting
Jan 21 02:12:58 server kernel: nvme nvme0: Controller is down; will reset: CSTS=0x3
Jan 21 02:12:59 server kernel: pcieport 0000:00:1d.0: AER: Corrected error received: 0000:03:00.0
Jan 21 02:13:00 server kernel: nvme 0000:03:00.0: enabling device (0000 -> 0002)

Qué significa: Timeouts y resets de controlador suelen preceder panics si un driver entra en una ruta de fallo o el dispositivo se comporta mal.

Decisión: Revisa combinaciones firmware/driver NVMe; considera actualizar firmware, actualizar el kernel o cambiar el dispositivo. También revisa el slot/backplane PCIe.

Task 8: Verificar contenido de initramfs y filesystem raíz (panics de arranque)

cr0x@server:~$ lsinitramfs /boot/initrd.img-6.1.0-18-amd64 | egrep -i "nvme|ahci|virtio|dm-crypt|lvm" | head
usr/lib/modules/6.1.0-18-amd64/kernel/drivers/nvme/host/nvme.ko
usr/lib/modules/6.1.0-18-amd64/kernel/drivers/md/dm-crypt.ko
usr/lib/modules/6.1.0-18-amd64/kernel/drivers/md/dm-mod.ko
usr/lib/modules/6.1.0-18-amd64/kernel/drivers/md/raid1.ko
usr/lib/modules/6.1.0-18-amd64/kernel/drivers/scsi/sd_mod.ko

Qué significa: Los drivers de arranque temprano están presentes. Módulos de almacenamiento o de cifrado faltantes son un disparador clásico de “VFS: unable to mount root”.

Decisión: Si faltan módulos necesarios, reconstruye el initramfs y verifica los UUIDs en la cmdline del kernel. No sigas reiniciando esperando que cambie de opinión.

Task 9: Confirmar identidad de dispositivos de bloque y mapeo de UUID

cr0x@server:~$ blkid | head -n 6
/dev/nvme0n1p1: UUID="8b2c1d90-0a0f-4db3-bf90-4b3d6f1c2f3e" TYPE="ext4" PARTUUID="0f12c0d4-01"
/dev/nvme0n1p2: UUID="0d6d8a8c-0d90-4d8b-9d8b-7c8e6a6e2c1a" TYPE="swap" PARTUUID="0f12c0d4-02"

Qué significa: El UUID existe y coincide con la cmdline (compara con /proc/cmdline).

Decisión: Si hay desajuste, corrige la configuración del gestor de arranque. Si cambiaron los nombres de dispositivo (común con HBAs/multipath), deja de usar /dev/sdX en configuraciones de arranque.

Task 10: Inspeccionar estado de taint del kernel (¿hay un módulo de terceros involucrado?)

cr0x@server:~$ cat /proc/sys/kernel/tainted
0

Qué significa: 0 significa no tainted: sin flags conocidos como módulos propietarios o cargas forzadas.

Decisión: Si tainted es distinto de cero, descódralo y trata los módulos fuera del árbol como sospechosos. La capacidad de soporte cambia rápido cuando corres código no soportado.

Task 11: Identificar la compilación exacta del kernel y su procedencia

cr0x@server:~$ uname -a
Linux server 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2025-12-18) x86_64 GNU/Linux

Qué significa: Versión del kernel, empaquetado de la distro y fecha de compilación. Esta es tu línea base para regresiones conocidas.

Decisión: Si el panic empezó después de una actualización del kernel, considera revertir como contención mientras analizas, especialmente por regresiones en drivers.

Task 12: Comprobar señales de integridad de sistemas de archivos tras el reinicio (no adivines)

cr0x@server:~$ dmesg | egrep -i "EXT4-fs|XFS|BTRFS|ZFS|recovery|journal" | tail -n 30
[    2.911234] EXT4-fs (nvme0n1p1): recovery complete
[    2.911980] EXT4-fs (nvme0n1p1): mounted filesystem with ordered data mode. Quota mode: none.

Qué significa: El sistema de archivos remató su journal limpiamente. Es una buena señal; aún así verifica los datos de la aplicación según sea necesario.

Decisión: Si ves advertencias de corrupción, fuerza un plan offline de fsck/xfs_repair y mantiene el nodo fuera de servicio hasta verificarlo.

Task 13: Buscar lockups que podrían haber escalado

cr0x@server:~$ journalctl -k -b -1 | egrep -i "soft lockup|hard lockup|watchdog" | tail -n 30
Jan 21 02:12:50 server kernel: watchdog: BUG: soft lockup - CPU#7 stuck for 22s! [kworker/7:2:238]
Jan 21 02:13:12 server kernel: Kernel panic - not syncing: softlockup: hung tasks

Qué significa: El watchdog del kernel detectó una CPU atascada y provocó panic. A menudo por deadlocks en drivers, stalls de almacenamiento o tormentas de IRQ severas.

Decisión: Trátalo como un problema de kernel/driver o stall hardware. Revisa latencia de almacenamiento, distribución de IRQs y cambios recientes en drivers. No “arregles” deshabilitando el watchdog salvo que disfrutes los bloqueos silenciosos.

Task 14: Extraer registros del BMC/firmware cuando los panics sean sospechosamente silenciosos

cr0x@server:~$ ipmitool sel list | tail -n 8
  91 | 01/21/2026 | 02:13:18 | System Boot Initiated | Initiated by watchdog | Asserted
  92 | 01/21/2026 | 02:13:19 | Power Unit | Power off/down | Asserted
  93 | 01/21/2026 | 02:15:02 | Power Unit | Power cycle | Asserted

Qué significa: Un watchdog inició el reinicio/ciclo de energía. Eso podría ser un hang del kernel, política del BMC o fallo de plataforma.

Decisión: Si el BMC desencadenó resets, investiga la salud del hardware, la configuración del watchdog y si el SO estuvo lo bastante vivo como para registrar. Esto cambia toda la narrativa del incidente.

Task 15: Abrir el vmcore con crash (cuando tengas evidencia real)

cr0x@server:~$ crash /usr/lib/debug/boot/vmlinux-6.1.0-18-amd64 /var/crash/127.0.1.1-2026-01-21-02:15:08/vmcore
crash 8.0.2
VMLINUX: /usr/lib/debug/boot/vmlinux-6.1.0-18-amd64
DUMPFILE: /var/crash/127.0.1.1-2026-01-21-02:15:08/vmcore  [PARTIAL DUMP]
CPUS: 16
DATE: Tue Jan 21 02:13:19 2026
PANIC: "Kernel panic - not syncing: Fatal exception"
TASKS: 3247

Qué significa: Tienes un volcado usable y la cadena de panic. Ahora puedes inspeccionar stacks, tareas y estado del kernel.

Decisión: Si vmcore carga correctamente, deja de teorizar en el chat y empieza a extraer una hipótesis de causa raíz con evidencia.

Task 16: Obtener el backtrace e identificar el subsistema

cr0x@server:~$ crash -c "bt" /usr/lib/debug/boot/vmlinux-6.1.0-18-amd64 /var/crash/127.0.1.1-2026-01-21-02:15:08/vmcore
PID: 0      TASK: ffffffff81a13c80  CPU: 3   COMMAND: "swapper/3"
 #0 [ffffb3b740003d90] machine_kexec at ffffffff8105b2ad
 #1 [ffffb3b740003df0] __crash_kexec at ffffffff8112a7b2
 #2 [ffffb3b740003ec0] panic at ffffffff8122c1e5
 #3 [ffffb3b740003f40] oops_end at ffffffff810f3b9a
 #4 [ffffb3b740003f60] page_fault_oops at ffffffff8107d1d2
 #5 [ffffb3b740003fd0] exc_page_fault at ffffffff81c0167a
 #6 [ffffb3b7400040b0] asm_exc_page_fault at ffffffff81e00b2b
 #7 [ffffb3b740004140] nvme_complete_rq at ffffffff815a1e2a

Qué significa: El contexto del crash apunta al manejo de completions NVMe. Esto no prueba que NVMe sea “el culpable”, pero es tu mejor pista.

Decisión: Correlaciona con resets/timeouts NVMe, versión de firmware y issues conocidos del kernel. Considera actualizar firmware o kernel, o cambiar hardware para confirmar.

Modos de fallo que realmente causan panics

1) Tiempo de arranque: no puede montar el filesystem raíz

Los panics que mencionan VFS, root=, initramfs o “not syncing” durante el arranque son a menudo problemas de configuración o empaquetado. El kernel no puede continuar porque no encuentra o no puede montar /. Causas incluyen:

• root=UUID= incorrecto tras reemplazo o clonación de disco.
• Initramfs sin drivers de almacenamiento (común tras fallos en la instalación del kernel o imágenes personalizadas).
• Root encriptado/LVM donde los hooks no se generaron, o /etc/crypttab cambió sin regenerar initramfs.
• Cambios en nombres por multipath causando confusión del “dispositivo root”.

Qué hacer: Confirma cmdline, confirma UUIDs, inspecciona initramfs e inicia en un entorno de rescate si hace falta. Reconstruir initramfs suele ser la solución correcta. Reinstalar el SO suele ser una solución perezosa.

2) En tiempo de ejecución: rutas de drivers con bugs (red, GPU, almacenamiento, FS)

Los drivers corren en espacio kernel. Cuando fallan, fallan con privilegios. Los drivers de almacenamiento son especialmente picantes porque involucran IRQs, mapeo DMA, timeouts y reintentos bajo carga elevada.

Qué hacer: Correlaciona el backtrace del panic con los logs del kernel: resets, timeouts, mensajes AER, flaps de enlace. Si ves flags “tainted”, trata los módulos fuera del árbol como sospechosos principales.

3) Corrupción de memoria (hardware o software) que parece ser todo

Los panics más molestos son los que no se quedan en un solo subsistema. Hoy es ext4. Mañana es TCP. La semana que viene es el asignador de páginas. Ese patrón suele indicar corrupción de memoria—a veces bug del kernel, a menudo hardware (DIMM, CPU, placa madre) o ajustes inestables de overclock/undervolt en servidores “de rendimiento”.

Qué hacer: Busca señales MCE/EDAC, corre pruebas de memoria en mantenimiento y compara firmas de crash entre nodos. Si aparecen stacks no relacionados, deja de culpar genéricamente al “kernel” y empieza a tratar al host como sospechoso.

4) Panics inducidos por watchdogs por lockups

Soft lockups significan que el scheduler del kernel no avanza en una CPU. Hard lockups son peores. Los watchdogs existen porque los bloqueos silenciosos son veneno operativo: tu nodo sigue “up” pero no hace nada.

Qué hacer: No deshabilites watchdogs como primer movimiento. Investiga qué se estaba ejecutando, tormentas de IRQ, latencia de almacenamiento y deadlocks. Usa vmcore para encontrar tareas bloqueadas y locks cuando sea posible.

5) Casos límite del filesystem y la pila de almacenamiento

Los sistemas de archivos pueden provocar panic cuando se rompen invariantes internas (o cuando el kernel decide detenerse antes que arriesgar corrupción). Algunos están diseñados para “ir a panic” más fácilmente que otros. Las pilas de almacenamiento pueden provocar panics vía bugs, presión de memoria o problemas en la capa de bloques.

Qué hacer: Trata la ruta de almacenamiento como un sistema: firmware, cableado/backplane, errores PCIe, configuraciones multipath, timeouts, profundidades de cola y versión del kernel. Un panic en almacenamiento rara vez es “solo almacenamiento” o “solo kernel”. Es la interfaz entre ambos.

Tres mini-historias del mundo corporativo (anonimizadas)

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

Tenían una flota de nodos Linux que arrancaban desde NVMe local, con un pequeño RAID1 para el sistema root. Alguien reemplazó un disco fallado durante una ventana de mantenimiento rutinaria. Fue un buen día: sin alarmas, sin impacto al cliente, swap limpio.

Entonces ocurrió el siguiente reinicio. El nodo entró en panic: VFS: Unable to mount root fs on unknown-block. El on-call supuso que era “mala actualización del kernel” porque el reinicio coincidió con parches. Revirtieron el kernel. Mismo panic. Reinstalaron el gestor de arranque. Mismo panic. Empezaron a murmurar sobre kernels del proveedor y mala suerte.

El problema real fue más simple y más vergonzoso: la configuración del gestor de arranque referenciaba el dispositivo root por un UUID obsoleto copiado de una imagen vieja. El sistema había sobrevivido porque el disco antiguo aún existía y el orden de arranque era “afortunado”. El reemplazo cambió la enumeración lo suficiente para romper la suerte.

La solución fue usar identificadores estables consistentemente (UUID/PARTUUID en todas partes), reconstruir initramfs y validar que la ruta de arranque coincidiera con la realidad. El cambio duradero fue cultural: no más configuraciones de arranque de “va a estar bien”. El arranque es parte de producción.

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

Una iniciativa de rendimiento apuntó a la latencia de IO en un clúster analítico muy cargado. Alguien ajustó parámetros NVMe, cambió profundidades de cola y habilitó gestión agresiva de energía de la CPU para “reducir jitter”. Los benchmarks se veían bien. Todos celebraron los gráficos.

Una semana después, nodos empezaron a entrar en panic bajo carga pico. Los backtraces apuntaban a la ruta de completions de almacenamiento y ocasionalmente al scheduler. Era intermitente, imposible de reproducir en laboratorio y solo ocurría cuando el sistema estaba a la vez CPU-ocupado y IO-ocupado. Esa combinación es donde las optimizaciones “casi seguras” van a morir.

Tras un análisis doloroso de vmcore y mucha correlación, encontraron el patrón: una combinación firmware/driver no toleraba las nuevas transiciones de estado de energía a escala. La “optimización” aumentó la tasa de resets del controlador y compitió con una ruta de código raramente usada. El panic no fue solo por el ajuste de gestión de energía—fue la interacción.

La medida correcta fue aburrida: revertir el cambio de gestión de energía, actualizar firmware NVMe en un despliegue controlado y fijar una versión de kernel conocida por comportarse con ese hardware. La latencia empeoró un poco. La disponibilidad mejoró mucho. Sorprendentemente, al negocio le gustó más la disponibilidad.

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

Una plataforma adyacente a pagos corría una flota mixta con control de cambios estricto. Sus actualizaciones de kernel se hacían por etapas, su configuración de kdump se probaba trimestralmente y la salida de la consola serial se capturaba centralmente. A nadie le encantaba esto. Todos se beneficiaron.

Una noche, un subconjunto de nodos entró en panic tras un flap en la ruta de almacenamiento durante un mantenimiento del centro de datos. El panic fue rápido y los nodos se reiniciaron. El servicio se mantuvo porque el scheduler drenó automáticamente las cargas cuando fallaron los heartbeats.

A la mañana siguiente, en lugar de discusiones, tenían artefactos: vmcores, logs de consola y una línea temporal clara desde la persistencia del journal. Los dumps mostraron tareas bloqueadas en la capa de bloques tras timeouts repetidos y los logs de consola capturaron errores PCIe AER justo antes del panic.

La solución no fue un parche mágico del kernel. Fue reemplazar un backplane defectuoso y actualizar un lote de firmware que el proveedor llevaba recomendando en silencio. El postmortem fue calmado porque la evidencia fue completa. Las “prácticas aburridas” no evitaron la falla, pero previnieron el caos—y eso es la mayor parte de lo que hace ops.

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

1) Síntoma: “Kernel panic – not syncing: VFS: Unable to mount root fs” tras una actualización

Causa raíz: Initramfs sin un módulo de almacenamiento/cripto requerido, o desajuste de UUID del root tras cambios de imagen.

Solución: Arranca un kernel de rescate, verifica la intención de /proc/cmdline vs la realidad con blkid, reconstruye initramfs (dracut/update-initramfs) y reinstala el gestor de arranque si hace falta.

2) Síntoma: Panics aleatorios con backtraces no relacionados durante semanas

Causa raíz: Corrupción de memoria, a menudo hardware (DIMM) o inestabilidad de la plataforma.

Solución: Revisa logs MCE/EDAC, corre diagnósticos de memoria, intercambia DIMMs/hosts y no mantengas la máquina en producción “porque se reinició bien”.

3) Síntoma: Panic menciona “Attempted to kill init!”

Causa raíz: PID 1 se cayó (systemd o init) o fue matado por una falla catastrófica del espacio de usuario (root lleno, binarios corruptos, libc rota) o bug del kernel.

Solución: Examina el journal del arranque previo por fallos de espacio de usuario y errores de filesystem. Valida la salud del almacenamiento. Si PID 1 murió por SIGKILL debido a OOM, ataca la presión de memoria y las restricciones; si fue por corrupción de disco, repara y restaura.

4) Síntoma: Panic precedido por timeouts y resets NVMe

Causa raíz: Bug en firmware NVMe, integridad de señal PCIe, regresión del driver del kernel o interacción con gestión de energía.

Solución: Correlaciona resets con carga y versión de kernel; actualiza firmware; considera actualizar/revertir kernel; revisa logs AER; vuelve a asentar/reemplazar dispositivo o slot/backplane.

5) Síntoma: Mensajes “soft lockup” y luego panic

Causa raíz: CPU atascada por deadlock de driver, tormenta de interrupciones o sección no-preemptible larga bajo carga.

Solución: Usa vmcore para identificar hilos y locks atascados; revisa distribución de IRQs y errores de dispositivo; actualiza kernel si es una deadlock conocida; evita deshabilitar watchdog como “solución”.

6) Síntoma: Panics solo en una versión del kernel en la flota

Causa raíz: Regresión del kernel o cambios de defaults (IOMMU, scheduler, comportamiento del driver).

Solución: Fija una versión de kernel conocida como contención; prueba versiones candidatas en un anillo canario; recoge dumps para reportar un bug al upstream/proveedor con evidencia.

7) Síntoma: No hay logs de panic, solo reinicio súbito

Causa raíz: Pérdida de energía, reset del BMC watchdog, bug de firmware o crash del kernel demasiado temprano para registrar.

Solución: Extrae SEL del BMC, habilita consola serial/netconsole/pstore y verifica crashkernel + kdump. Trata “sin logs” como fallo de infraestructura, no como misterio tolerable.

8) Síntoma: Panic tras habilitar un módulo de kernel “inofensivo”

Causa raíz: Módulo fuera del árbol o mal probado; incompatibilidad ABI; kernel tainted causando inestabilidad.

Solución: Quita el módulo, vuelve a la pila soportada por el proveedor y reproduce en staging. Si debes usarlo, fija versiones de kernel y ten un plan de reversión practicado.

Listas de verificación / plan paso a paso

Checklist A: Cuando un nodo hace panic en producción (primeros 30 minutos)

1. Contener: quita el nodo del balanceador / scheduler; evita bucles de crash repetidos que destrozan discos.
2. Preservar evidencia: confirma /var/crash; copia el directorio de crash a almacenamiento seguro; snapshot de logs.
3. Recoger logs del kernel: journalctl -b -1 -k y dmesg del arranque actual.
4. Revisar señales hardware: logs MCE/EDAC, SEL del BMC, patrones de errores de almacenamiento.
5. Clasificar: arranque vs tiempo de ejecución vs ruta de almacenamiento vs aleatoriedad tipo hardware.
6. Elegir contención: revertir kernel/driver, cambiar hardware o mantener en cuarentena para análisis profundo.

Checklist B: Hacer futuros panics diagnósticables (una ventana de mantenimiento)

1. Habilita y prueba kdump con un crash controlado en un nodo no crítico.
2. Asegura que la memoria crashkernel esté reservada y sea suficiente para tu tamaño de RAM.
3. Habilita almacenamiento persistente para journald y verifica que los logs del arranque previo sobrevivan.
4. Configura registro de consola serial o captura SOL en tu entorno.
5. Decide dónde viven los vmcores y cómo se rotan (y quién puede borrarlos).
6. Establece canarios de actualización de kernel y procedimientos de reversión que no sean “rezar y reiniciar”.

Checklist C: Endurecimiento de la ruta de almacenamiento que reduce la probabilidad de panic

1. Mantén el firmware (NVMe/HBA/backplane) alineado con recomendaciones del proveedor.
2. Estandariza versiones de kernel por generación de hardware; evita “kernels copo de nieve”.
3. Monitorea y alerta sobre precursoras: timeouts NVMe, errores AER corregidos, resets de enlace.
4. Configura timeouts y políticas de reintento sensatas; ajustes demasiado agresivos pueden desencadenar casos límite.
5. Prueba rutas de failover (multipath, rebuild de RAID) bajo carga, no solo en diapositivas.

Preguntas frecuentes

1) ¿Cuál es la diferencia entre un oops del kernel y un panic del kernel?

Un oops es una excepción del kernel que puede permitir que el kernel siga funcionando (a veces con limitaciones). Un panic es el kernel deteniéndose (o reiniciando) porque no puede continuar de forma segura. Oops repetidos suelen ser preludio de un panic.

2) ¿Debo configurar el kernel para reiniciar automáticamente tras un panic?

En la mayoría de entornos de producción, sí: configura un retraso razonable con kernel.panic para que el nodo vuelva y tu scheduler pueda reponer capacidad. Pero hazlo junto con kdump y logs persistentes; reiniciar rápidamente sin evidencia es solo amnesia acelerada.

3) ¿Puede un disco lleno causar un panic del kernel?

No directamente en el caso común, pero puede provocar fallos en espacio de usuario que maten procesos críticos (incluido PID 1), lo que puede derivar en “Attempted to kill init.” Un disco lleno también puede agravar rutas de recuperación y corrupción. Trata el disco lleno como un bug serio de fiabilidad.

4) Si el stack menciona NVMe, ¿significa que el drive NVMe es definitivamente culpable?

No. Es una pista, no un veredicto. Los timeouts NVMe pueden venir de firmware, problemas en la ruta PCIe, gestión de energía, regresiones del kernel o del propio dispositivo. Correlaciona con resets/timeouts/logs AER y, idealmente, con análisis de vmcore.

5) ¿Por qué los panics ocurren más durante IO intensivo?

IO intensivo golpea concurrencia compleja: interrupciones, mapeo DMA, contención de locks y recuperación de errores. Bugs y hardware marginal suelen ocultarse hasta que esas rutas se estresan. La carga de producción es una mejor prueba que la mayoría de laboratorios.

6) ¿Es aceptable desactivar watchdogs para detener panics de “soft lockup”?

Como contención temporal en un escenario muy específico, tal vez. Como solución general, no. Estás intercambiando una falla ruidosa por un bloqueo silencioso, que es peor operativamente y más difícil de detectar. Arregla el stall subyacente.

7) ¿Cómo sé si mi kernel está “tainted” y por qué importa?

/proc/sys/kernel/tainted muestra un bitmask. Tainted suele indicar módulos propietarios, cargas forzadas de módulos u otras condiciones que dificultan el soporte upstream y pueden correlacionar con inestabilidad. Si está tainted, examina primero los módulos de terceros.

8) ¿Los contenedores o Kubernetes “causan” panics del kernel?

Los contenedores no obtienen privilegios especiales del kernel, pero aumentan la carga, el uso de features del kernel (cgroups, overlayfs, redes) y patrones de estrés. Kubernetes también genera churn rápido que puede exponer condiciones de carrera. El panic sigue siendo kernel/driver/hardware—pero la orquestación cambia el radio de afectación.

9) ¿Cuál es la mejor inversión para reducir el tiempo hasta la causa raíz?

Volcados confiables de crash (kdump) junto con un procedimiento probado para recuperarlos. Todo lo demás—argumentos, teorías, “lo vi una vez”—es más lento.

Conclusión: próximos pasos que puedes hacer esta semana

Si ejecutas Linux en producción, no eliminas los pánicos del kernel. Los haces raros, diagnósticables y no catastróficos.

• Elige un nodo y demuestra que kdump funciona de extremo a extremo: reserva, trigger, captura de vmcore y recuperación.
• Haz que los logs sobrevivan reinicios y captura la salida de consola en un lugar duradero.
• Define contención para clases de panic: panics de arranque, panics en ruta de almacenamiento, panics con sospecha de hardware.
• Deja de adivinar cuando tengas evidencia. Los vmcores convierten el drama en ingeniería.
• Audita tus “optimizaciones”—especialmente alrededor de la gestión de energía y la configuración de colas de almacenamiento—porque el kernel no tiene paciencia para la creatividad no probada bajo carga real.

Y cuando Linux dice “nope” en público, no es por mala educación. Se niega a corromper tus datos en silencio. Respeta la honestidad. Luego ve por el dump.