Captura de fallos con Kdump en Debian 13: configúralo y demuestra que funciona (caso #17)

Qué estás construyendo: kexec + un segundo kernel + una ruta de volcado

Kdump funciona manteniendo un “kernel de fallo” en reserva. Cuando el kernel en ejecución entra en pánico (o fuerzas un fallo para
pruebas), el sistema no realiza un reinicio frío. En su lugar, usa kexec para saltar directamente al
kernel de fallo, que ejecuta un pequeño espacio de usuario desde un initramfs y escribe la memoria en disco o en la red como un vmcore.

El requisito crítico: el kernel de fallo necesita RAM reservada que el kernel en crash nunca toque.
Por eso se establece crashkernel= en la línea de arranque. Si omites eso, tendrás un servicio kdump que
“arranca” y un fallo que no produce nada útil. Es como instalar rociadores sin presión de agua.

Dos aclaraciones rápidas que te ahorrarán horas:

• Kdump no arregla los fallos. Convierte un fallo en un artefacto con el que puedes razonar.
• Kdump solo es tan bueno como su ruta de volcado. Si tu destino de volcado depende de lo que está roto, aprenderás humildad.

Hechos y contexto que realmente importan

1. Kdump tiene años en Linux. El enfoque de volcado basado en kexec maduró a mediados de los 2000 y se convirtió en un estándar en distribuciones empresariales.
2. “Segundo kernel” es literal. Kdump no es una función de depuración dentro del mismo kernel; arranca un kernel separado en memoria reservada.
3. Los primeros kdump servían para triage de hardware. Ayudaban a los proveedores a distinguir RAM/PCIe defectuosos de bugs del kernel sin adivinar.
4. Los volcados de fallo impulsaron trabajo real en la fiabilidad del kernel. Cuando los equipos de operaciones podían entregar un vmcore a los desarrolladores, “no reproducible” perdió popularidad.
5. La compresión se volvió esencial conforme la RAM creció. Un volcado de 512 MB molestaba en 2006; un volcado de 512 GB arruina carreras.
6. NUMA y sistemas grandes cambiaron las reglas de dimensionamiento. Reservar 128 MB antes era suficiente; en hardware moderno el kernel de fallo puede necesitar más para cargar controladores y escribir volcados.
7. Secure Boot complica kexec en algunos entornos. Dependiendo de la política, kexec puede estar restringido; debes validar en el modelo de confianza de tu plataforma.
8. Initramfs es el verdadero campo de batalla. La mayoría de fallos de kdump no son “kdump”, son controladores de almacenamiento/red faltantes en el initramfs de fallo.
9. Systemd hizo visible el estado del servicio kdump. Ahora puedes ver rápidamente si el kernel de fallo está cargado, en lugar de confiar en folclore.

Decisiones de diseño: dónde volcar, cómo arrancar, qué reservar

Elige un destino de volcado que sobreviva a tus fallos probables

Normalmente tienes tres destinos sensatos para el volcado:

• Sistema de archivos local (rápido, simple): bueno si los discos siguen activos durante el fallo y el sistema de archivos montable en el kernel de fallo.
• Partición local dedicada o dispositivo raw (aburrido, robusto): menos dependencia de tu espacio de usuario normal; mejores probabilidades en pilas de almacenamiento complejas.
• Red (usualmente NFS) (mejor si “la pila de discos podría estar frita”): evita la complejidad de almacenamiento local, pero el kernel de fallo debe levantar la NIC y rutas.

Si ejecutas almacenamiento complejo—LUKS sobre LVM sobre MD RAID sobre multipath—tu ruta de volcado será lo que falle.
En ese caso, una pequeña partición dedicada sin cifrar, o un destino NFS, es la opción adulta.
Sí, eso significa que planificas tu propio colapso. Bienvenido a SRE.

Tamaño de crashkernel: prefiere “funciona” sobre “mínimo”

En sistemas Debian modernos, reservar muy poca memoria provoca fallos silenciosos y tontos: el kernel de fallo se carga,
pero luego no puede inicializar controladores ni asignar buffers para escribir el volcado. No seas ingenioso.

Una regla práctica aproximada que suele funcionar:

• VM pequeñas: 256M puede ser suficiente.
• Servidores generales con controladores comunes: 512M es una base segura.
• Máquinas grandes, muchos módulos de almacenamiento/red o NUMA intenso: 768M–1024M.

Si no puedes ceder 512M de RAM en 2025, tu problema real es el presupuesto, no kdump.

Una cita para colgar sobre el panel

La esperanza no es una estrategia. — máxima común de operaciones (idea parafraseada, atribuida a círculos de fiabilidad)

Instalar y habilitar kdump en Debian 13

El empaquetado de Debian puede cambiar entre versiones puntuales, pero el patrón operativo se mantiene:
instala las herramientas de kdump, reserva crashkernel, regenera la configuración de arranque/initramfs y asegura que el kernel de fallo esté cargado.

Tarea 1 — Confirma kernel, herramientas de initramfs y gestor de arranque

cr0x@server:~$ uname -a
Linux server 6.12.0-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.3-1 (2025-09-10) x86_64 GNU/Linux

Qué significa: Estás ejecutando un kernel Debian que soporta kexec/kdump. Si usas un kernel personalizado,
valida que esté compilado con soporte de volcado. Decisión: procede salvo que sepas que has eliminado las opciones kexec/crash.

cr0x@server:~$ ls -l /etc/kernel/cmdline /etc/default/grub 2>/dev/null || true
-rw-r--r-- 1 root root  112 Oct 12 10:03 /etc/default/grub

Qué significa: Este host probablemente usa la configuración de GRUB en /etc/default/grub. Algunos entornos Debian usan
/etc/kernel/cmdline con flujos de kernel-install. Decisión: usa el archivo que tu sistema realmente consume.

Tarea 2 — Instala los componentes de kdump

cr0x@server:~$ sudo apt-get update
Hit:1 http://deb.debian.org/debian trixie InRelease
Reading package lists... Done

cr0x@server:~$ sudo apt-get install -y kdump-tools kexec-tools linux-image-amd64 makedumpfile
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  kdump-tools kexec-tools makedumpfile
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Setting up kexec-tools (1:2.0.28-1) ...
Setting up kdump-tools (1:1.8.0-2) ...
Setting up makedumpfile (1:1.7.6-2) ...

Qué significa: Ahora tienes los wrappers de servicio y la herramienta de volcado. Decisión: el siguiente paso es la reserva de crashkernel;
sin ella, kdump solo fingirá.

Tarea 3 — Comprueba si el servicio kdump está habilitado y qué indica

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; preset: enabled)
     Active: active (exited) since Mon 2025-12-30 09:12:01 UTC; 3min ago
       Docs: man:kdump-config(8)

Qué significa: “active (exited)” es normal; el servicio carga el kernel de fallo y luego se aparta.
Decisión: no te felicites; aún necesitas confirmar que el kernel de fallo está realmente cargado.

Broma #1: Kdump es como las copias de seguridad: todos “lo tienen” hasta el día que lo necesitan y descubren que en realidad recopilaban sensaciones.

Reservar crashkernel memory (y demostrar que está reservada)

Tarea 4 — Inspecciona la línea de comando actual del kernel

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.12.0-1-amd64 root=UUID=0a1b2c3d-4e5f-6789-a012-3456789abcde ro quiet

Qué significa: No hay parámetro crashkernel=. Ahora mismo, kdump probablemente no puede reservar memoria.
Decisión: añade crashkernel=512M (o más si tienes controladores complejos).

Tarea 5 — Establece crashkernel en GRUB y regenera la configuración

cr0x@server:~$ sudo sed -i 's/^\(GRUB_CMDLINE_LINUX_DEFAULT=".*\)"/\1 crashkernel=512M"/' /etc/default/grub

cr0x@server:~$ grep -n '^GRUB_CMDLINE_LINUX_DEFAULT' /etc/default/grub
6:GRUB_CMDLINE_LINUX_DEFAULT="quiet crashkernel=512M"

Qué significa: Crashkernel ahora está configurado para futuros arranques. Decisión: actualiza GRUB y reinicia en un momento controlado.

cr0x@server:~$ sudo update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.12.0-1-amd64
Found initrd image: /boot/initrd.img-6.12.0-1-amd64
done

Tarea 6 — Reboot y verificar memoria reservada

cr0x@server:~$ sudo reboot
Connection to server closed by remote host.

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.12.0-1-amd64 root=UUID=0a1b2c3d-4e5f-6789-a012-3456789abcde ro quiet crashkernel=512M

cr0x@server:~$ dmesg | grep -i crashkernel | head -n 5
[    0.000000] Reserving 512MB of memory at 0x0000001f00000000 for crashkernel (System RAM: 32768MB)
[    0.000000] crashkernel reserved: 0x0000001f00000000 - 0x0000001f20000000 (512 MB)

Qué significa: La reserva es real. Si no ves líneas como estas, no tienes kdump—solo sensaciones.
Decisión: si la reserva falló, aumenta el tamaño o corrige parámetros del kernel en conflicto (común en VM pequeñas o mapas de firmware raros).

Tarea 7 — Confirma que el kernel de crash kexec está cargado

cr0x@server:~$ sudo kdump-config show
DUMP_MODE:                kdump
USE_KDUMP:                1
KDUMP_SYSCTL:             kernel.panic_on_oops=1
KDUMP_COREDIR:            /var/crash
KDUMP_KERNELVER:          6.12.0-1-amd64
KEXEC:                    /sbin/kexec
crashkernel addr:         0x0000001f00000000
crashkernel size:         0x20000000

Qué significa: Las herramientas ven la región reservada. Decisión: ahora valida la ruta de volcado y el contenido del initramfs de fallo.

cr0x@server:~$ sudo kexec -p -s || true
kexec: no crash kernel loaded

Qué significa: Esta comprobación en particular no dice que se haya cargado nada aún. Algunas configuraciones cargan al iniciar el servicio o tras la configuración.
Decisión: reinicia kdump-tools y vuelve a comprobar.

cr0x@server:~$ sudo systemctl restart kdump-tools

cr0x@server:~$ sudo kexec -p -s
kexec: crash kernel is loaded

Qué significa: Perfecto. Tu kernel de fallo está preparado. Decisión: pasa a la configuración y validación del destino de volcado.

Configurar destino de volcado: disco local vs NFS (y por qué importa)

Disco local a /var/crash: lo más simple cuando el almacenamiento es sano

Los valores por defecto de Debian suelen ser “volcar bajo /var/crash.” Eso está bien si:
tu sistema de archivos root es montable desde el initramfs de fallo y tu pila de almacenamiento es simple.
Para ext4 en una VM, suele ser perfecto.

Tarea 8 — Valida que tienes espacio para volcados y que el sistema de archivos lo acepta

cr0x@server:~$ df -h /var/crash
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        80G   22G   54G  29% /

Qué significa: Tienes espacio. Un volcado completo es aproximadamente del tamaño de la RAM; makedumpfile puede comprimir/filtrar.
Decisión: si el espacio libre es escaso, vuelca a un volumen dedicado o a NFS, y configura filtrado/compresión.

Tarea 9 — Revisa la configuración de kdump-tools (y establece compresión/filtrado)

cr0x@server:~$ sudo sed -n '1,200p' /etc/default/kdump-tools
# kdump-tools configuration
USE_KDUMP=1
KDUMP_COREDIR="/var/crash"
MAKEDUMPFILE_ARGS="-l --message-level 1 -d 31"
KDUMP_KERNELVER=""

Qué significa: MAKEDUMPFILE_ARGS controla cuánto recortas. -d 31 es una máscara común para “descartar muchas páginas”.
Decisión: mantiene el filtrado activado a menos que necesites volcados completos para depuración y puedas almacenarlos.

Destino NFS: menos controladores de almacenamiento, más trabajo de red

NFS es mi opción por defecto cuando la pila de almacenamiento local es compleja (LUKS-en-todo, controladores RAID exóticos, boot por iSCSI).
Cambia la dependencia de “podemos montar el FS root en un mundo roto” a “el kernel de fallo puede levantar la red”.
Eso suele ser más fácil de hacer determinista, especialmente en una VLAN fija.

Tarea 10 — Configurar un path NFS de volcado (ejemplo)

Este es un estilo de configuración de ejemplo. Las claves exactas pueden variar según la versión del empaquetado Debian, pero el requisito operativo es estable: el initramfs de fallo debe saber dónde escribir y cómo llegar.

cr0x@server:~$ sudo grep -R "KDUMP_" -n /etc/default/kdump-tools
2:USE_KDUMP=1
3:KDUMP_COREDIR="/var/crash"

Para NFS normalmente defines el directorio de volcado a una ruta exportada disponible en el entorno de fallo.
Un enfoque común es configurar scripts de kdump para montar NFS durante el crash. En Debian, ese comportamiento lo manejan los hooks del initramfs de kdump.
Debes probarlo.

Ejemplo: crea un punto de montaje y una entrada en fstab para visibilidad en el día a día, luego asegúrate de que el initramfs de fallo también incluya lo necesario.
(No asumas que el initramfs de fallo usa tus montajes normales. Es un mundo pequeño y separado.)

cr0x@server:~$ sudo mkdir -p /mnt/kdump-nfs

cr0x@server:~$ echo '10.10.20.50:/exports/kdump /mnt/kdump-nfs nfs4 _netdev,nofail,ro 0 0' | sudo tee -a /etc/fstab
10.10.20.50:/exports/kdump /mnt/kdump-nfs nfs4 _netdev,nofail,ro 0 0

cr0x@server:~$ sudo mount -a

cr0x@server:~$ mount | grep kdump-nfs
10.10.20.50:/exports/kdump on /mnt/kdump-nfs type nfs4 (ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.10.20.21,local_lock=none,addr=10.10.20.50)

Qué significa: El userspace normal puede alcanzar la exportación NFS. Decisión: ahora debes asegurarte de que el initramfs de fallo también pueda
hacerlo (controladores, configuración IP, ruta, piezas del cliente NFS).

cr0x@server:~$ sudo sed -i 's|^KDUMP_COREDIR=.*|KDUMP_COREDIR="/mnt/kdump-nfs"|g' /etc/default/kdump-tools

cr0x@server:~$ grep -n '^KDUMP_COREDIR' /etc/default/kdump-tools
3:KDUMP_COREDIR="/mnt/kdump-nfs"

Qué significa: Diriges los volcados al punto de montaje NFS. Decisión: reconstruye el initramfs de kdump y valida que el kernel de fallo aún se cargue.

Verificar el kernel de kdump e initramfs antes de provocar un fallo

La forma más rápida de parecer ridículo es “probar kdump” en horario laboral sin verificar que el entorno de fallo pueda escribir un volcado.
Trátalo como una migración: haz simulaciones, demuestra que las piezas existen y luego realiza la prueba disruptiva con un plan de reversión.

Tarea 11 — Reconstruir initramfs y reiniciar kdump-tools

cr0x@server:~$ sudo update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-6.12.0-1-amd64

cr0x@server:~$ sudo systemctl restart kdump-tools

cr0x@server:~$ sudo kexec -p -s
kexec: crash kernel is loaded

Qué significa: Tras cambios de configuración, el kernel de fallo sigue preparado. Decisión: valida qué contiene el initramfs,
especialmente los módulos de almacenamiento y NIC.

Tarea 12 — Inspecciona el initramfs de kdump en busca de módulos críticos (almacenamiento y red)

cr0x@server:~$ lsinitramfs /boot/initrd.img-6.12.0-1-amd64 | grep -E '(^lib/modules/.*/kernel/drivers/(net|block)|/sbin/makedumpfile|nfs|rpc)' | head -n 20
lib/modules/6.12.0-1-amd64/kernel/drivers/block/virtio_blk.ko
lib/modules/6.12.0-1-amd64/kernel/drivers/net/virtio_net.ko
sbin/makedumpfile
usr/sbin/ip
usr/sbin/ifconfig

Qué significa: Tu initramfs incluye al menos algunos componentes necesarios. Los controladores faltantes aquí son la razón nº1
por la que los volcados no aparecen. Decisión: si dependes de ixgbe, bnx2, megaraid_sas, nvme,
dm_crypt, etc., confirma que estén presentes.

Tarea 13 — Asegura que los sysctls están configurados para provocar un panic si algo falla

cr0x@server:~$ sysctl kernel.panic kernel.panic_on_oops
kernel.panic = 0
kernel.panic_on_oops = 1

Qué significa: El sistema hará panic en un oops (a menudo deseable para capturar volcados) pero no se reiniciará automáticamente tras el panic.
Decisión: en producción, establece kernel.panic=10 (o similar) para que el kernel de fallo tenga tiempo de volcar y luego reinicie.
Si lo dejas en 0 para siempre, podrías acabar con un host muerto que requiere intervención manual.

cr0x@server:~$ echo 'kernel.panic = 10' | sudo tee /etc/sysctl.d/99-kdump-panic.conf
kernel.panic = 10

cr0x@server:~$ sudo sysctl --system | tail -n 5
* Applying /etc/sysctl.d/99-kdump-panic.conf ...
kernel.panic = 10

Tarea 14 — Confirma que tu directorio de volcado es escribible y estable

cr0x@server:~$ sudo test -d /mnt/kdump-nfs && sudo test -w /mnt/kdump-nfs && echo "ok: writable" || echo "not writable"
not writable

Qué significa: En este ejemplo, el montaje NFS era de solo lectura (ro en fstab). Eso es auto-sabotaje.
Decisión: corrige las opciones de montaje; tu destino de volcado debe ser escribible, evidentemente.

cr0x@server:~$ sudo sed -i 's/_netdev,nofail,ro/_netdev,nofail,rw/' /etc/fstab

cr0x@server:~$ sudo mount -o remount,rw /mnt/kdump-nfs

cr0x@server:~$ sudo test -w /mnt/kdump-nfs && echo "ok: writable" || echo "not writable"
ok: writable

Qué significa: Tu destino es escribible en userspace normal. Decisión: aún no es suficiente—necesitas que el kernel de fallo también lo pueda,
pero esto elimina un modo de fallo fácil.

Tarea 15 — Simula permisos de escritura y comportamiento de nombres

cr0x@server:~$ sudo sh -c 'd=/mnt/kdump-nfs/TEST-$(hostname)-$(date +%s); mkdir "$d" && echo hello > "$d"/marker.txt && ls -l "$d"'
total 4
-rw-r--r-- 1 root root 6 Dec 30 09:24 marker.txt

Qué significa: La estructura de directorios funciona y el servidor acepta escrituras. Decisión: procede a la prueba controlada de fallo
solo cuando tengas acceso a consola (IPMI/iDRAC/consola virtual) y una ventana de mantenimiento.

Provocar un fallo de prueba controlado y confirmar la captura del vmcore

Una prueba de crash con kdump es disruptiva por definición. Hazlo como si lo sintieras:
ventana de mantenimiento, acceso a consola, ticket abierto, alguien observando el destino de volcado y un plan de reversión
(como mínimo: quitar crashkernel= si rompe el arranque, aunque eso es poco común).

Broma #2: Forzar un crash del kernel en producción es como probar la alarma de incendios prendiendo fuego en la cocina—efectivo, pero deberías tener un extintor.

Tarea 16 — Asegura que SysRq esté habilitado (requerido para un disparo relativamente seguro)

cr0x@server:~$ sysctl kernel.sysrq
kernel.sysrq = 176

Qué significa: SysRq está habilitado (176 permite un subconjunto que incluye el disparador de crash en muchos sistemas).
Decisión: si es 0, habilítalo temporalmente para la prueba y luego decide la política a largo plazo.

cr0x@server:~$ echo 'kernel.sysrq = 176' | sudo tee /etc/sysctl.d/99-sysrq.conf
kernel.sysrq = 176

cr0x@server:~$ sudo sysctl -p /etc/sysctl.d/99-sysrq.conf
kernel.sysrq = 176

Tarea 17 — Inicia una visualización en vivo del destino de volcado (en el servidor NFS o en el host)

cr0x@server:~$ sudo ls -lah /mnt/kdump-nfs | tail -n 5
drwxr-xr-x  3 root root 4.0K Dec 30 09:24 .
drwxr-xr-x  4 root root 4.0K Dec 30 09:21 ..
drwxr-xr-x  2 root root 4.0K Dec 30 09:24 TEST-server-1735550640

Qué significa: Puedes ver aparecer nuevos directorios. Decisión: mantén esta vista abierta durante la prueba; es tu verdad terreno.

Tarea 18 — Provoca el fallo vía SysRq

Esto hará que el kernel falle inmediatamente. No lo hagas desde una sesión SSH que no estés dispuesto a perder.
Usa acceso por consola si puedes.

cr0x@server:~$ echo c | sudo tee /proc/sysrq-trigger
c

Qué deberías ver a continuación: el host entra en pánico, luego kexec arranca el kernel de fallo, escribe un volcado y después reinicia.
El tiempo depende del tamaño de la RAM y de la velocidad del destino. Si reservaste 512M pero tienes 256G de RAM y sin filtrado, trae snacks.

Tarea 19 — Tras el reinicio, confirma que se escribió un volcado

cr0x@server:~$ sudo ls -lt /mnt/kdump-nfs | head
total 12
drwxr-xr-x 2 root root 4096 Dec 30 09:29 server-2025-12-30-09:29
drwxr-xr-x 2 root root 4096 Dec 30 09:24 TEST-server-1735550640

cr0x@server:~$ sudo ls -lah /mnt/kdump-nfs/server-2025-12-30-09:29
total 1.9G
-rw------- 1 root root 1.9G Dec 30 09:29 vmcore
-rw-r--r-- 1 root root 3.2K Dec 30 09:29 dmesg.txt
-rw-r--r-- 1 root root  178 Dec 30 09:29 kdump-info.txt

Qué significa: Esa es la condición de victoria: un vmcore más metadatos. Decisión: si falta vmcore,
ve directamente al guion de diagnóstico rápido y la tabla de errores comunes abajo.

Tarea 20 — Confirma que los logs muestran que kdump se ejecutó (journal del arranque posterior al crash)

cr0x@server:~$ sudo journalctl -b -1 -u kdump-tools --no-pager | tail -n 60
Dec 30 09:28:12 server systemd[1]: Starting kdump-tools.service - Kernel crash dump capture service...
Dec 30 09:28:12 server kdump-tools[642]: kdump-tools: Loading crash kernel: succeeded
Dec 30 09:28:12 server systemd[1]: Finished kdump-tools.service - Kernel crash dump capture service.

Qué significa: Los logs del arranque anterior muestran la carga del kernel de fallo. Esto no prueba que el volcado se escribió (tu listado de archivos lo hace),
pero prueba que la ruta de preparación funciona. Decisión: si esto muestra “failed to load crash kernel”, arregla eso antes de más pruebas.

Comprobar el volcado y hacer análisis básico

No necesitas ser ingeniero de kernel para validar que un vmcore es real y coherente internamente.
El objetivo es operativo: confirmar que capturaste memoria y que puedes extraer un backtrace cuando sea necesario.

Tarea 21 — Identifica el formato del volcado y confirma que no es basura vacía

cr0x@server:~$ sudo file /mnt/kdump-nfs/server-2025-12-30-09:29/vmcore
/mnt/kdump-nfs/server-2025-12-30-09:29/vmcore: ELF 64-bit LSB core file, x86-64, version 1 (SYSV)

Qué significa: Es un archivo core ELF, como se espera. Decisión: procede a las herramientas de análisis si necesitas depurar; si no, archívalo.

Tarea 22 — Confirma la versión del kernel para emparejar símbolos

cr0x@server:~$ sudo cat /mnt/kdump-nfs/server-2025-12-30-09:29/kdump-info.txt
Kdump: 1.8.0
Kernel: 6.12.0-1-amd64
Dump saved to: /mnt/kdump-nfs/server-2025-12-30-09:29

Qué significa: Necesitas símbolos coincidentes (paquetes debug) para análisis profundo. Decisión: en entornos serios, espeja paquetes debug
internamente para poder analizar semanas después, tras actualizaciones.

Tarea 23 — Prueba rápida con crash (opcional pero recomendable)

cr0x@server:~$ sudo apt-get install -y crash
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  crash
Setting up crash (8.0.5-1) ...

cr0x@server:~$ sudo crash /usr/lib/debug/boot/vmlinux-6.12.0-1-amd64 /mnt/kdump-nfs/server-2025-12-30-09:29/vmcore
crash 8.0.5
GNU gdb (Debian 14.2-1) 14.2
...
      KERNEL: /usr/lib/debug/boot/vmlinux-6.12.0-1-amd64
    DUMPFILE: /mnt/kdump-nfs/server-2025-12-30-09:29/vmcore
        CPUS: 8
        DATE: Mon Dec 30 09:29:01 2025
      UPTIME: 00:41:22
LOAD AVERAGE: 0.02, 0.05, 0.01
       TASKS: 312
    NODENAME: server
     RELEASE: 6.12.0-1-amd64
     VERSION: #1 SMP PREEMPT_DYNAMIC Debian 6.12.3-1 (2025-09-10)
     MACHINE: x86_64  (3191 Mhz)
crash>

Qué significa: Puedes abrir el volcado. Ese es el objetivo operativo. Decisión: si esto falla con “cannot find vmlinux”,
crea un proceso para conservar símbolos de depuración para los kernels desplegados (o al menos para los que te importan).

cr0x@server:~$ printf "bt\nsys\nquit\n" | sudo crash /usr/lib/debug/boot/vmlinux-6.12.0-1-amd64 /mnt/kdump-nfs/server-2025-12-30-09:29/vmcore | tail -n 20
PID: 0      TASK: ffffffff9a000000  CPU: 3   COMMAND: "swapper/3"
 #0 [ffffb0a5000f3d20] machine_kexec at ffffffff8a2a1a5a
 #1 [ffffb0a5000f3d80] __crash_kexec at ffffffff8a34b8e1
 #2 [ffffb0a5000f3e50] panic at ffffffff8a1a7d9f
 #3 [ffffb0a5000f3f20] sysrq_handle_crash at ffffffff8a8c2f10
 #4 [ffffb0a5000f3f60] __handle_sysrq at ffffffff8a8c2b3a
 #5 [ffffb0a5000f3fb0] write_sysrq_trigger at ffffffff8a8c42d0

Qué significa: El backtrace muestra claramente un crash provocado por SysRq, exactamente lo que hicimos. Esa es una prueba limpia.
Decisión: has verificado de extremo a extremo la captura con kdump y la viabilidad básica del post-mortem.

Guion de diagnóstico rápido

Cuando kdump “no funciona”, no entres en pánico. Diagnostica en el orden que reduce el espacio de búsqueda más rápido.
Esta es la secuencia que uso cuando me llaman por el pager.

1) ¿Reservó el kernel memoria crashkernel?

• Revisa /proc/cmdline en busca de crashkernel=.
• Revisa dmesg | grep -i crashkernel por líneas de reserva.

Si no hay reserva: no hay volcado. Arregla los parámetros del gestor de arranque y reinicia. Todo lo demás es distracción.

2) ¿Está realmente cargado un kernel de crash?

• Ejecuta sudo kexec -p -s para ver si hay un kernel de crash cargado.
• Revisa systemctl status kdump-tools y journalctl -u kdump-tools.

Si no está cargado: arregla la configuración de kdump-tools, la generación del initramfs o imágenes de kernel faltantes.

3) ¿Puede el entorno de crash acceder al destino de volcado?

• Disco local: asegúrate de que los controladores de bloque y sistemas de archivos necesarios estén en el initramfs; verifica que se monte.
• NFS: asegura que el controlador de NIC + configuración IP + ruta + bits del cliente NFS estén en el initramfs.

Si el destino es inalcanzable: ajusta hooks del initramfs, añade módulos, simplifica la ruta de volcado.
No “optimices” todavía. Haz que funcione primero.

4) ¿Es makedumpfile demasiado agresivo con el filtrado?

• Si obtienes un vmcore pequeño que no se puede abrir, inspecciona MAKEDUMPFILE_ARGS.
• Temporalmente reduce el filtrado para una prueba si es necesario.

5) Si todo parece bien pero los volcados aún desaparecen

• Considera: Secure Boot / lockdown que restringe kexec, rarezas de firmware, quirks de IOMMU o reinicios de almacenamiento.
• Prueba un destino más simple (partición ext4 dedicada sin cifrar) como experimento de control.

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

No hay vmcore después del crash, y nada obvio en logs

Síntomas: Fuerzas un crash; el host reinicia; el directorio de volcado queda vacío.

Causa raíz: No hay memoria crashkernel reservada, o la reserva falló.

Solución: Añade crashkernel=512M (o más), reinicia y confirma con dmesg | grep -i crashkernel.

El servicio kdump “activo”, pero kexec -p -s dice que no hay kernel de crash cargado

Síntomas: systemd muestra kdump-tools exitoso; kexec dice que no hay nada cargado.

Causa raíz: kdump-tools no cargó debido a falta de reserva crashkernel o initramfs mal generado.

Solución: Corrige crashkernel= primero, luego update-initramfs -u -k all, reinicia kdump-tools y vuelve a comprobar.

El directorio de volcado existe pero solo hay metadatos, no vmcore

Síntomas: Ves dmesg.txt o archivos de info, pero no vmcore.

Causa raíz: La escritura del volcado falló a mitad: sin espacio, fallo NFS, controlador faltante o el kernel de fallo se quedó sin memoria.

Solución: Comprueba espacio, estabilidad NFS, aumenta tamaño crashkernel, asegura que módulos NIC/almacenamiento estén en initramfs.

Volcado escrito localmente, pero el sistema de archivos queda corrupto después

Síntomas: vmcore aparece, pero el arranque siguiente activa fsck o errores.

Causa raíz: Volcar en el mismo sistema de archivos que ya estaba inestable, o el crash ocurrió durante la escritura y la recuperación del journal fue problemática.

Solución: Volcar a una partición dedicada o a NFS. Trata /var como no confiable durante desastres.

El volcado a NFS nunca aparece; los volcados locales funcionan

Síntomas: La captura en disco local funciona; el destino NFS queda vacío tras pruebas de crash.

Causa raíz: El kernel de fallo no puede levantar la red (falta el módulo NIC, no hay configuración IP, falta ruta, VLAN necesaria).

Solución: Asegura el controlador NIC en initramfs; configura IP estática para el kernel de fallo; evita dependencias en servicios complejos (DHCP, 802.1X).

El sistema se cuelga en el crash en lugar de reiniciar al kernel de fallo

Síntomas: Disparas el crash; el host se congela; no hay reinicio.

Causa raíz: Bloqueo hardware/firmware, problemas NMI, o la ruta de panic no puede ejecutar kexec; a veces watchdog no está configurado.

Solución: Habilita watchdog hardware si está disponible; prueba disparadores de crash alternativos; considera deshabilitar IOMMU problemático para la prueba; verifica acceso a consola.

vmcore existe pero la herramienta crash no puede leerlo

Síntomas: file muestra core file, pero crash da errores.

Causa raíz: Faltan símbolos vmlinux con debug para esa build exacta del kernel, o el volcado está truncado.

Solución: Conserva paquetes debug para kernels desplegados; verifica tamaño e integridad del volcado; re-prueba con filtrado menos agresivo de makedumpfile.

Tras habilitar crashkernel, el sistema no arranca o la memoria queda justa

Síntomas: OOMs tempranos, contenedores funcionan peor o el arranque falla en sistemas con poca RAM.

Causa raíz: Reservar demasiado en una VM limitada, o mapa de memoria en conflicto con el firmware.

Solución: Usa un valor menor (256M), o parámetros crashkernel basados en rango de memoria; confirma la reserva en dmesg.

Listas de verificación / plan paso a paso

Plan mínimo “solo necesito que funcione” (disco local)

1. Instala: kdump-tools, kexec-tools, makedumpfile.
2. Añade crashkernel=512M a GRUB, ejecuta update-grub, reinicia.
3. Verifica la reserva: dmesg | grep -i crashkernel.
4. Verifica kernel de crash cargado: kexec -p -s.
5. Asegura que /var/crash tenga espacio y sea escribible.
6. Prueba crash durante una ventana: echo c > /proc/sysrq-trigger.
7. Tras reiniciar, verifica que /var/crash contiene vmcore.

Plan creíble para producción (destino NFS)

1. Prepara una exportación NFS dedicada a volcados de crash (permisos, cuotas, retención).
2. Móntala en userspace normal para visibilidad, pero no asumas que el kernel de fallo usará ese montaje.
3. Configura KDUMP_COREDIR al path previsto y reconstruye initramfs.
4. Confirma que el initramfs contiene el controlador NIC y los bits del cliente NFS (inspecciona con lsinitramfs).
5. Establece kernel.panic=10 para que el sistema reinicie tras el volcado.
6. Realiza una prueba de crash controlada y observa el directorio NFS en vivo.
7. Abre el volcado con crash al menos una vez. Demuestra que es analizablе, no solo “un archivo existe”.

Notas de gestión de cambios (lo que pongo en el ticket)

• Riesgo: reservar crashkernel reduce RAM disponible; raros problemas de arranque en firmware inusual.
• Reversión: quitar crashkernel= de GRUB y reiniciar.
• Verificación: dmesg reserva, kernel de crash cargado, prueba de crash produce vmcore.
• Seguimiento operativo: política de retención, permisos y disponibilidad de símbolos para análisis.

Tres micro-historias corporativas (dolorosamente plausibles)

1) El incidente causado por una suposición equivocada

Un equipo desplegó kdump en una flota tras un panic que tumbó un nodo de base de datos y todos se encogieron de hombros en el postmortem.
Instalaron los paquetes, habilitaron el servicio y comprobaron que systemctl status estaba en verde.
Luego declararon la victoria. El ticket cerró con una captura de pantalla. Nadie probó un crash.

Meses después, un host de producción empezó a entrar en pánico bajo carga de red. Esta vez creían estar listos: “tenemos kdump ahora.”
Esperaron al reinicio, entraron y miraron en /var/crash. Vacío. Ni siquiera un archivo stub.
La cadena de escalada empezó con esa frase familiar: “Pero lo habilitamos.”

La causa raíz fue clara y embarazosa. Los parámetros del gestor de arranque nunca incluyeron crashkernel=.
El servicio “funcionaba” en el sentido de que se ejecutó y salió con éxito, pero no tenía nada que cargar.
La suposición fue creer que instalar kdump-tools implicaba que el sistema reservaría memoria automáticamente. No es así.

La solución fue sencilla y la lección no: cualquier característica de fiabilidad que no se verifica de extremo a extremo es teatro.
Añadieron crashkernel=512M, reiniciaron los hosts por lotes y ejecutaron un crash controlado por rack durante una ventana programada.
Tras eso, cuando reapareció el bug del controlador de red, tuvieron un vmcore y un backtrace real. La conversación con el proveedor cambió de tono al instante.

2) La optimización que salió mal

Otra organización tenía cajas de analítica con mucha memoria. Alguien decidió que los volcados eran demasiado grandes y “optimizó”
makedumpfile para eliminar más páginas y comprimir más. Los volcados se hicieron más pequeños. Todos aplaudieron.
También redujeron crashkernel de 1G a 256M porque “arranca bien y queremos RAM de vuelta.”

Entonces un panic ocurrió durante una tormenta de resets del controlador de almacenamiento. Kdump a veces escribía un vmcore minúsculo—unos megabytes—otras veces nada.
Cuando lo hacía, crash no podía extraer pilas útiles porque regiones clave de memoria fueron filtradas.
La configuración optimizada entregó un artefacto que contenía el equivalente operacional de lorem ipsum.

El análisis posterior encontró dos fallos que se sumaron. El crashkernel más pequeño dejó al entorno de fallo sin memoria
al cargar controladores de almacenamiento y al bufferizar escrituras. Encima, el filtrado agresivo eliminó estructuras del kernel
necesarias para la investigación (estado de la ruta I/O).

Revirtieron a una línea base conservadora: crashkernel en 768M y filtrado moderado.
Los volcados volvieron a ser más grandes. Pero pasaron a ser fiables y útiles. La verdadera optimización no fue la compresión; fue asegurarse
de que los volcados aterrizaran en un destino NFS para que extrañeza del disco local no importara. Afinar el rendimiento está bien, pero solo después de la corrección.

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

Un equipo de plataforma gestionaba una flota Debian mixta y tenía una política gris: cada actualización de kernel debía archivar símbolos de depuración coincidentes
(o al menos hacerlos recuperables) para las dos versiones previas. Sin excepciones. Los ingenieros se quejaban del almacenamiento extra,
pasos adicionales y burocracia.

Una noche, un host entró en pánico de modo que tumbó un servicio interno crítico. Kdump funcionó y escribió un vmcore a NFS.
El on-call trajo el volcado a la VM de análisis, ejecutó crash y obtuvo inmediatamente un backtrace limpio apuntando a un subsistema específico.
No fue la causa raíz completa, pero fue suficiente para reenviar el incidente al equipo correcto y aplicar una mitigación.

La clave fue que la disponibilidad de símbolos convirtió “tenemos un vmcore” en “tenemos una respuesta.” Sin símbolos, habrían tenido un blob.
Con símbolos, tuvieron nombres de funciones y una narrativa creíble de la falla. La práctica aburrida—mantener artefactos de depuración alineados con kernels desplegados—
marcó la diferencia entre un incidente de dos horas y una discusión de dos días.

Nadie escribió un correo de celebración sobre la política después. Así sabes que fue ingeniería real.

Preguntas frecuentes

1) ¿Realmente necesito reiniciar tras añadir crashkernel=?

Sí. La reserva de memoria ocurre en el arranque. Sin reinicio no hay memoria reservada, lo que significa que no hay volcado fiable.

2) ¿Cómo sé si kdump está realmente armado ahora?

Comprueba ambos: dmesg | grep -i crashkernel (reserva) y sudo kexec -p -s (kernel de crash cargado).
“Servicio habilitado” no es prueba.

3) ¿Cuál es la forma más segura de probar kdump?

Usa el disparador SysRq (echo c > /proc/sysrq-trigger) durante una ventana de mantenimiento con acceso a consola.
Verifica que el volcado aparezca y sea legible con crash.

4) ¿Qué tamaño debería poner en crashkernel en Debian 13?

Empieza con 512M para servidores típicos. Si tienes necesidades intensas de controladores de almacenamiento/red, sube a 768M–1024M.
En una VM pequeña, 256M puede ser tu límite—pruébalo.

5) ¿Puedo volcar a un sistema de archivos cifrado (LUKS)?

Puedes, pero es frágil: el initramfs de fallo debe desbloquear LUKS, lo que significa que necesitas claves disponibles sin interacción.
Para la mayoría, vuelca a una partición dedicada sin cifrar o a NFS en su lugar.

6) ¿Kdump funcionará si el fallo fue causado por el controlador de almacenamiento?

Tal vez sí, tal vez no. Si tu destino de volcado depende de la misma pila de controladores que acaba de fallar, estás jugando a la ruleta.
Por eso NFS o una partición local simple suelen ser el mejor diseño.

7) ¿Por qué obtengo un vmcore pero es demasiado grande?

Probablemente estás volcando la mayor parte de la RAM sin mucho filtrado/compresión. Ajusta MAKEDUMPFILE_ARGS para filtrar páginas,
y dimensiona el destino para el peor caso. También considera que “demasiado grande” suele ser un problema de retención, no de kdump.

8) ¿Por qué crash se queja de símbolos faltantes?

Necesitas el vmlinux con símbolos de depuración que coincidan exactamente con la release del kernel que produjo el volcado.
Crea un proceso para retener o recuperar esos artefactos tras actualizaciones.

9) ¿Debería poner kernel.panic_on_oops=1?

En muchos entornos de producción, sí: un oops a menudo significa estado del kernel corrupto, y continuar puede causar corrupción silenciosa de datos.
Si eliges panic-on-oops, pónlo junto con kdump y un kernel.panic razonable.

10) ¿Los contenedores o VMs cambian algo?

Los contenedores no controlan el kernel del host, así que kdump es una característica del host. En VMs, kdump suele funcionar bien—solo recuerda que el invitado necesita RAM crashkernel reservada, y el hipervisor puede influir en la velocidad de escritura hacia disco o red virtual.

Próximos pasos que deberías hacer

• Elige un destino de volcado según los modos de fallo, no la conveniencia. Si el almacenamiento es complejo, usa NFS o partición dedicada.
• Estandariza el dimensionamiento de crashkernel. Empieza con 512M; documenta cuándo usar más.
• Haz una prueba controlada por tipo de plataforma. Diferentes NICs/controladores RAID se comportan distinto en el kernel de fallo.
• Haz que la disponibilidad de símbolos sea una política. Si no puedes abrir un volcado dos semanas después, estás acumulando pisapapeles caros.
• Automatiza la verificación. Como mínimo, alerta si crashkernel no está reservado o el kernel de crash no está cargado.
• Escribe el runbook del operador. Quién extrae el vmcore, dónde se guarda, cómo funciona la retención y quién puede acceder.

Kdump es una característica de fiabilidad que solo justifica su valor cuando todo lo demás falla. Eso no es una razón para procrastinar.
Es la razón para hacerlo correctamente, probarlo y mantenerlo aburrido.