Nuevo arranque de pmx50 a las 15:11 del 20 de octubre de 2026¶
Es un evento distinto del arranque de las 13:35. Root lo confirmó a las 15:12:55,632896 CEST: /proc/stat registra btime=1792501910, 15:11:50 CEST / 13:11:50 UTC, boot ID <REDACTED_UUID>, uptime 65,6 segundos. La lectura independiente de las 15:14:18 confirma ese boot y uptime 148,72 segundos.
Secuencia nativa y del receptor¶
journalctl --list-boots conserva directamente el boot cff5c198… desde las 13:35:20 hasta las 15:11:00 y el actual desde las 15:11:52. No aparece un arranque intermedio. El primero y el último journal son límites de registros retenidos; no son un detector del instante exacto de bloqueo.
| Evidencia | CEST | UTC | Alcance |
|---|---|---|---|
Último journal retenido PRE, boot cff5c198… |
15:11:00,696788 | 13:11:00,696788 | No equivale a último keepalive |
| Último pulso PRE recibido por pmx51 | 15:11:24 | 13:11:24 | Uptime emisor 5765,99 s |
| Primeros mensajes de pérdida de enlace del peer | 15:11:28,478–480 | 13:11:28,478–480 | Observación de corosync, no causa raíz |
| Cambios de membresía del peer | 15:11:46–48 | 13:11:46–48 | No prueban por sí solos fencing |
| Btime actual | 15:11:50 | 13:11:50 | Lectura nativa de /proc/stat |
| Primer journal POST | 15:11:52,339419 | 13:11:52,339419 | Boot decded74… |
| Firma literal de expiración hardware watchdog | 15:11:52,379881 | 13:11:52,379881 | Kernel del nuevo boot, estado 0x02000800 |
| Primer pulso POST recibido | 15:12:01 | 13:12:01 | Uptime 11,78 s; separado de PRE |
| Enlace y membresía observados de nuevo | 15:12:07–10 | 13:12:07–10 | Sin equivalencia con recuperación completa |
La ventana nativa 15:09–15:13 contiene 2371 filas / 1.126.648 bytes: 175 PRE y 2196 POST. El kernel del arranque nuevo registra la firma literal hardware watchdog timer expired; sysfs watchdog0/bootstatus devuelve 32. No se abrió /dev/watchdog. Es evidencia del mecanismo de reset reportado; no identifica la causa de perder los keepalives ni el cliente, proceso o CPU implicado. Véanse los límites del driver y de la captura.
No se encontraron firmas acotadas de apagado ordenado, OOM o panic/lockup en la ventana. El último kernel retenido del boot PRE corresponde a las 13:37:40,899636, muy anterior al corte; su ausencia cerca del incidente no descarta un fallo no registrado.
pmx51 mantiene el boot <REDACTED_UUID>. Su journal de corosync/HA/watchdog-mux contiene 24 filas en la ventana; el clasificador detecta enlace y membresía, sin firmas de expiración de cliente, fencing o pérdida de quorum. No se convierte esta ausencia en una exclusión global de esos mecanismos.
Pulso PRE separado de POST¶
Se verificaron metadatos de los dos archivos existentes del receptor y se leyeron sólo sus colas de 8 MiB, con descriptor sin seguir symlinks, límite de tiempo y tamaño inicial fijado. Se toleró append sin cambio de identidad y sin truncado. Sus prefijos temporales abarcan la ventana; no se exploraron rotaciones ni se persistieron mensajes completos.
- PRE: 144 muestras, 15:09:00–15:11:24. CPU 47,1–51,0 °C, última 47,4 °C; MemAvailable 13647–13885 MiB, última 13880 MiB; SwapFree 6244 MiB; lag 0,01 s.
- POST: 59 muestras, 15:12:01–15:13:00. Uptime 11,78–70,26 s; no se mezclan sus valores con los del PRE.
El emisor de pulso avanza unos 23,30 s después del último journal local. Esto acredita progreso de ese proceso, no de watchdog-mux o HA, ni ausencia de bloqueo parcial. No identifica el último ping del watchdog. No se resta uptime de una recepción UDP para reemplazar el btime nativo. La temperatura/memoria muestreadas no descartan un cambio posterior ni explican causalmente el reset.
Ansible y evidencia anterior: límites¶
La consulta de ansible-pull.service en el boot PRE, restringida a 15:09:00–15:11:50, devuelve cero filas. Por tanto no hay en esa ventana una TASK ni una ejecución de rol acreditadas. El preflight comunicado por root a las 15:10:38 había contado cero procesos Git y Ansible y mantenía la referencia del fallo Git de las 14:45; era una muestra anterior al nuevo boot, no vigilancia continua. No se atribuye este evento a Ansible, a las lecturas ni a la avería de objetos del checkout.
En el boot POST la unidad aparece inactive/dead, Result=success y ExecMainStatus=0, con timestamps de ejecución vacíos: no acredita un pull completado después del reboot. El timer sigue active/waiting; sus metadatos de disparo o persistencia tampoco son prueba de una ejecución de roles previa. No se ha forzado start, pull, fetch, reparación de Git ni reintento.
Las proyecciones de propietarios/invitados de las 15:06 y de caché/procesos de las 15:10 son anteriores a este boot. No se presentan como inventario actual ni como prueba de que todos los invitados, montajes, jobs o aplicaciones hayan quedado recuperados. Esta investigación no realizó una consulta nueva del mapa de invitados ni de productos. El impacto posterior queda pendiente de una lectura de propietario/estado autorizada por separado.
Evidencia y alcance¶
Directorio privado 0700 ~/.local/state/pmx50-1511-forensics-20261020-jiwrmzlc/; proyecciones 0600:
| Archivo | SHA256 |
|---|---|
| native-forensics.json | <REDACTED> |
| peer-window.json | <REDACTED> |
La confirmación inicial de root está en ~/.local/state/pmx50-newest-boot-20261020-nstl129o/host.json, SHA256 <REDACTED>.
Una conexión de lectura por nodo en esta investigación. Cada consulta de journal quedó limitada a 2 MiB y 10 s; el conjunto devolvió menos del máximo de filas pedido. Sólo se retuvieron timestamps, clases, contadores y metadatos. Sin escrituras remotas, reinicios, estrés, sondas, sensores adicionales, cambios de HA/watchdog, colectores, jobs ni tareas de Vera. El instalador del publicador continúa pausado y sin ejecutar. No hay causa raíz ni estabilidad posterior certificadas.
Parámetros seleccionados del boot actual: 15:18:29 CEST¶
Una lectura adicional autorizada, sin comandos de sondeo, confirma el mismo boot decded74… y btime 15:11:50. Los campos seleccionados concuerdan con las mitigaciones históricas citadas; esto acredita configuración actual, no eficacia ni causa del reset.
| Campo seleccionado | Valor observado |
|---|---|
| Kernel release | 7.0.14-19-pve |
Cmdline nvme_core.default_ps_max_latency_us |
0 |
Sysfs nvme_core/parameters/default_ps_max_latency_us |
0 |
Cmdline crash_kexec_post_notifiers |
Presente |
Sysfs cpufreq/boost |
0 |
Sysctl nmi_watchdog / hardlockup_panic / softlockup_panic |
1 / 1 / 1 |
Sysctl watchdog_thresh |
5 |
Módulos cargados mt7921e / btusb / cfg80211 |
No / no / no |
| DMI board vendor / board name | Shenzhen Meigao Electronic Equipment Co.,Ltd / F7BFD |
| BIOS version / date | 1.15 / 11/30/2023 |
Los cuatro parámetros de watchdog/panic no aparecen como tokens en cmdline, pero sus valores actuales sí se leyeron en /proc/sys/kernel; ausencia en cmdline no significa desactivación. La presencia de crash_kexec_post_notifiers no demuestra que un crash haya alcanzado kdump. No se consultaron el resto de cmdline, listas completas de módulos, seriales ni UUID de hardware. El board vendor es un campo diferente del sys_vendor histórico; estos datos no bastan para seleccionar un firmware por modelo.
Proyección privada mitigations.json, SHA256 <REDACTED>, en el mismo directorio de evidencia 0700, archivo 0600. No se abrió /dev/watchdog, ni se ejecutaron modprobe, SMART, sensores, ajustes o herramientas de invitados. La investigación de la ventana anterior usó una lectura por nodo; esta comprobación añadió sólo una lectura seleccionada de pmx.