felhom.eu/REPORT.md

REPORT — read-back of the first real kernel night (2026-10-07 → 08)

Check	Result
demo-felhom — step ran	PASS. Whole-guest backup 04:35; guest/host/Proxmox steps 04:37–04:38; kernel staged 04:39:04 as exactly the told 7.0.14-20 (the sources offered 7.0.14-22 — R-898's fix held); restart 04:39:08; boot on 7.0.14-20; judged healthy 04:40:38 (38 s after the agent started); 7.0.14-20 is the default, flag empty, step good.
demo-felhom — apps	Away about 1.5 min (restart 04:39:08 → every container healthy at the 04:40:38 verdict).
demo-felhom — alarms	None: no host_stale, no backup failure mail (demo-felhom has no drive apps, so R-897's fix was not exercised there). Crash guard armed, 0 unclean boots. Hub logged staged → judging → applied.
demo-hp — step ran	NO. No whole-guest backup that night: the last one was yesterday's morning press at 08:49:53; with the 24 h cadence it came due at 08:49 today, after the window closed (08:30). No backup → no night leg → no kernel step. Nothing changed: running and default 7.0.14-20. Filed R-899.
Reply-To	Proven by you: your reply to the test mail (2026-10-07 20:29) went to admin@felhom.eu.
Your inbox overnight	Only Tester 2's expected missed-backup mails (the laptop is off).

Rows: 126 before → 127 after. Opened 1 (R-899). Closed 0.

What happens next, by itself:

• demo-hp is still due 7.0.14-22. A new household mail is allowed after 14:38 today (20 h after the last); its whole-guest backup is due inside tonight's window → the step should run on the night 8→9.
• demo-felhom now sees 7.0.14-22 pending → due; its household gets a mail after 09:00; it should step to 22 tonight too.
• After that both run 7.0.14-22, and "Approve kernel set" can appear. Read back the morning of 2026-10-09.

Seen, not fixed: the after-boot "judging" report carries ring 1 (the agent reads its ring from the hub's block, which it has not fetched yet in the first second after a boot). Cosmetic: the hub's approval reads its own ring list, not this field. Not fixed today because it needs an agent release and delivery for a label.

Evidence: documentation/audits/kernel-night-2026-10-07/readback/.

Decisions for you

1. R-899 — a daytime "back up now" press skips the next night's backup (and its updates). My pick: count nights, not 24 hours (the backup is due when the last one is older than ~20 h at the window's start). If you do nothing: each daytime press costs one night, and the kernel step waits one more day.