# 工单：kais-engine 2026-10-11 黑屏 + 主板 Q-Code B0 挂起 8h22m —— 根因深查（只读审计）

## 0. 角色与总任务

机器 kais-engine（ASUS ROG CROSSHAIR VIII HERO, X570, BIOS 5302 2025-10-03, 4×32GB DDR4, RTX 3060 Ti 显示卡 + 2×RTX 3090 渲染卡, Ubuntu 24.04 HWE 内核）。2026-10-11 01:16 机器走完有序关机黑屏，随后主板 Q-Code 显示 **B0 并保持约 8 小时 22 分**，09:38 人工按电源才启动成功。操作员（Kai）要求深挖这次黑屏+B0 的根本原因。

你是架构老司机，任务性质 = **只读审计 + Web 调研 + 修复方案设计**。
**唯一允许写入**：报告 `/tmp/glm-c8h-blackout-rca.md` + 修复脚本提案 `/tmp/gpu_driver_reboot_sentinel.fixed.sh`。
**红线**：禁 reboot/poweroff/halt、禁改任何系统配置/BIOS/文件、禁重启服务、禁 GPU 任务、禁 push。所有系统取证命令只读（journalctl/auth.log/dmidecode/efibootmgr/apt 日志均可；sudo -n 可用）。

## 1. Hermes 预钉事实（实测锚点，直接采用勿重新推导；复测有出入以你的为准并注明）

### 1.1 时间线（journal/wtmp/sentinel.log 实测）
| 时刻 | 事件 | 证据 |
|---|---|---|
| 10-10 06:50:58–06:53:29 | unattended-upgrades 把 **nvidia 全家 580.173.02→580.178.04**（含 nvidia-dkms）+ bluez 等 | /var/log/apt/history.log |
| 10-09 06:41 | unattended-upgrades 装了新内核 linux-image-7.0.0-38（机器继续跑在 -34 上） | /var/log/apt/history.log |
| 10-10 17:15:27 | 哨兵日志「DIRECT-REBOOT ordered by Kai (跳过空闲等待)」——Kai 授权重启，但 **reboot 从未到达 systemd**（会话执行器硬线闸拦截，见 1.3 哨兵脚本注释自述） | ~/.hermes/state/gpu-reboot-sentinel/sentinel.log |
| 10-11 01:00:25 | 哨兵 ARMED（KAP 租约空+ComfyUI 三实例队列空+宿主无杂散 GPU 进程） | 同上 |
| 10-11 01:15:26 | 哨兵 FIRING → `sudo -n systemctl reboot` | 同上 |
| 10-11 01:15:26–28 | journal 大量 NVRM API mismatch（用户态 580.178.04 vs 已加载内核模块 580.173.02）——每次 nvidia-smi 探测刷屏 | journalctl -b -1 |
| 10-11 01:15:28–01:16:04 | systemd 有序停机全序列：stop jobs → 卸载 /data /mnt/* → swap off → umount.target → reboot.target → journald 收 SIGTERM | journalctl -b -1 --since "01:15" |
| 10-11 01:16:04 | journal 停写（关机完成点）。wtmp: `shutdown ... Oct 11 01:16 - 09:38 (08:22)` | last -x |
| 10-11 01:16 → 09:38 | **journal/auth 完全空白 8h22m = 机器没有任何 OS 活动**；Kai 观察到主板 Q-Code 停在 B0 | journalctl --since 01:16:10 --until 09:38 空 |
| 10-11 09:38:15 | 人工开机成功，进内核 7.0.0-38，NVRM 580.178.04 三卡正常（驱动错配解除） | journalctl -b 0; nvidia-smi |
| 10-11 09:45:06 | 哨兵对账**没有执行**，反而重新 ARMED（bug，见 1.3） | sentinel.log |
| 10-11 10:00:06 | 哨兵因 GPU busy DISARMED——侥幸没把机器再重启一次 | sentinel.log |

### 1.2 关机性质判定（Hermes 初判，待你复核）
- boot -1 最后日志是完整 systemd 停机序列走到 `reached final.target / systemd-reboot.service finished / Shutting down`，journald 正常收 SIGTERM——**有序 reboot，非 panic/断电/内核挂死**。/var/crash 空，pstore 空，无 oops/Xid/MCE。
- NVRM mismatch 是关机前的持续噪声（监控在反复跑 nvidia-smi），不是关机诱因——关机是哨兵主动发起的。
- **疑点核心**：既然是 reboot，01:16 后机器本应重新 POST 启动；实际却卡在 B0 直到 09:38 人工干预。→ 黑屏本身不是故障，「reboot 后 POST 挂在 B0 八个多小时」才是要解的根因。

### 1.3 重启哨兵脚本两处硬伤（Hermes 已复核的代码级事实，你要验证并出修复）
- 脚本：`/home/kai/.hermes/scripts/gpu_driver_reboot_sentinel.sh`（cron job c16b1dce9ff7，*/15，no_agent）。**Hermes 已于今早 10:0x remove 该 cron 并 rm MARKER/ARMED + touch ABORT 拆除再重启地雷**——你只读分析，勿再动。
- **Bug A（对账永不执行）**：`PRE_UP=$(awk '{print int($1)}' "$STATE_DIR/pre-reboot-uptime.txt")`——该文件存的是 `uptime` 命令输出（首字段=时刻 "01:00:25"），`int($1)`=1，不是秒数；而 UP 取自 /proc/uptime 是真秒。于是重启后每次 tick 都命中 `UP > PRE_UP-60` 的「同 boot」分支，模式 B 对账永不运行 → MARKER 永不清 → 走到模式 A 空闲就重新 ARM/FIRE（09:45 ARMED、10:00 因 busy 侥幸 DISARMED）。
- **Bug B（无幂等触发源校验）**：MARKER 一旦存在且 24h 内，模式 A 空闲双 tick 即发 reboot，没有「本次 reboot 是否已成功发生」的判定（正是 Bug A 使对账失效导致的次生）。
- 附带发现：`netfilter-persistent.service` 本次 boot failed（25-ip6tables exit 4 NOPERMISSION）——顺带定性（可能是 iptables/nft 后端切换问题），P2。

### 1.4 环境真值
- 当前：`uname -r`=7.0.0-38-generic；dkms nvidia/580.178.04 对 -34 和 -38 都已装；三卡 nvidia-smi 正常。
- 上一 boot 用内核 7.0.0-34；加载的模块 580.173.02（错配根因=10-10 06:53 用户态升级不重启）。
- BIOS 5302（2025-10-03）；主板 2026-09-01 前后新换（历史见 skill: infrastructure/system-health-audit references/audit-2026-09-01-motherboard-swap.md，可读）。9-05 晚曾 5 连快速重启（21:06–21:18，每个 boot 都以 journald 正常收尾=人工调试行为，非挂死）。
- 哨兵脚本注释自述：10-10 17:15 的 DIRECT-REBOOT 被「会话执行器硬线闸」拦截（Hermes 工具对含 reboot 词的命令硬线封锁），reboot 从未到达 systemd，悬空至 01:00 空闲窗补发。

## 2. 任务

### C1 时间线终版重建
用 journalctl -b -1、/var/log/auth.log（01:00–01:16 段，找 cron/sudo/session 证据链）、wtmp/btmp、sentinel.log、apt/dpkg 日志，产出逐秒级关机触发链：谁（哪个 PID/命令行）→ 经什么授权路径（sudoers 匹配）→ systemd 停机序列关键节点。要求每条结论挂 证据文件:时间戳。特别核实：01:15:26 `sudo -n systemctl reboot` 的 auth.log 对应行。

### C2 B0 POST 挂起 8h22m 根因（本工单核心）
1. **本机取证**：`systemd-analyze`（本次固件阶段耗时）、`efibootmgr` 全量（BootOrder/BootNext/Timeout）、`sudo efivar -l | grep -i` 关键变量、dmesg -b 0 早期 ACPI/DMI 行、`sudo dmidecode` 完整（注意 RAM 训练相关字段）、检查 /sys/fs/pstore、`journalctl -b 0` 里 firmware→loader→kernel 的交接时间（判断本次是冷启动还是正常重启路径）。
2. **Web 调研**（重点）：CROSSHAIR VIII HERO / X570 AGESA（5302, ComboAM4v2 1.2.0.x 时代）**warm restart 后 POST 卡 B0** 的已知问题：搜 ASUS 官方论坛/Reddit/ Levels1techs 等关键词组合（"Crosshair VIII Hero" B0 q-code hang / "X570 restart stuck q-code" / "AGESA 5302" / "memory context restore restart hang"）。B0 在 AMI Q-code 里属 DXE 早期（Runtime Set Virtual Address MAP 一带），已知诱因族：Fast Boot、Memory Context Restore/Power Down Enable 与 EXPO 组合、Resizable BAR/Above 4G + 多 GPU、USB 控制器/设备枚举挂起、Warm-reboot 供电保持下的 RAM 重训失败。逐条给「社区证据 → 与本机配置的相关性 → 置信度」。
3. **判别设计**：给出下一轮可执行的判别探针序（如：故意 `systemctl reboot` 一次观察是否复现卡 B0 vs `poweroff` 冷开不复现；BIOS 里 MCR/Fast Boot 状态核对清单；若复现时的最小化差异法）。注意：探针只写方案，**不执行**（红线禁重启）。

### C3 触发链治理定性
这次事件的完整因果链 = ①unattended-upgrades 升级 nvidia 用户态/dkms 不重启 → ②NVML mismatch 破坏 GPU 监控 → ③Kai 授权重启被工具硬线闸拦 → ④哨兵 8h 后空闲补发 → ⑤reboot 后 POST 卡 B0 8h22m（C2 根因）→ ⑥对账 bug 使哨兵变再重启地雷。逐环给「机制解释 + 已有证据 + 防再发措施」，其中①的防再发 = unattended-upgrades 黑名单方案（给 50unattended-upgrades 的精确配置行：Unattended-Upgrade::Package-Blacklist 加 nvidia- / linux-image- / linux-headers- 等通配），并核对当前 /etc/apt/apt.conf.d/ 现状。

### C4 哨兵脚本修复提案
产出 `/tmp/gpu_driver_reboot_sentinel.fixed.sh`：修 Bug A（PRE_UP 用 /proc/uptime 秒数或改存 `awk '{print $1}' /proc/uptime`）、修 Bug B（对账成功/失败都必须收敛 MARKER 生命周期，加「reboot 已发生」单调判定；对账部分失败时只报不重启）、保留原有对账清单与消息格式。附 diff 说明。**禁直接覆盖生产脚本**——只写 .fixed.sh 提案。

### C5 与 Hermes 初判交叉验证
Hermes 初判三条：ⅰ「关机是有序 reboot 非 crash」ⅱ「B0 挂起 = POST 阶段问题，非 OS 层」ⅲ「哨兵 Bug A 的 awk 解析错误是对账失效根因」。逐条 ✅/❌ + 你的证据；另列你发现的 Hermes 遗漏点。

## 3. 输出契约

报告写 `/tmp/glm-c8h-blackout-rca.md`：C1–C5 各节 + 修复优先级矩阵（🔴立即/🟡短期/🟢规划 × 成本 S/M/L）+ operator 割接清单（BIOS 核对项/unattended 黑名单/哨兵修复部署步骤）。结尾 ≤300 字中文摘要（含根因一句话定谳 + P0 清单）。所有结论必须带证据（文件:行/时间戳/URL）；不确定标「待验证」；禁止无证据推断。