Repository navigation
docs/kernel: the boot date is a moving fact, so point the reader at uptime -s - #1147
Conversation
…ptime -s 'booted since 2026-11-04 05:45' was true when it was written and false after every reboot; tonight's (2026-11-05 13:39) made it wrong again. The kernel it names is still what boots: uname -r 7.4.0-rc1-1bit, PerfOpt armed on IOMMU0, amdxdna vermagic 7.4.0-rc1-1bit. Only the tense changes.
|
#1147 ready for review at |
bong-water-water-bong
left a comment
There was a problem hiding this comment.
VERDICT: READY
Verified on this box, against the claims in the body:
uname -r->7.4.0-rc1-1bit;modinfo -F vermagic amdxdna->7.4.0-rc1-1bit SMP preempt mod_unload modversions;journalctl -b -kcarries onePerfOpt armed on IOMMU0.- The defect is demonstrable twice over now:
journalctl --list-bootsshows the box booted at 2026-11-05 13:39:33 and again at 14:59:37, so the body's own measureduptime -s= 13:39:31 was already false by the time I read it. Replacing the frozen date with the command is the right kind of fix. ONEBIT_ENGINE_DIR=<this head> python3 tools/site.py /tmp/site_chk_1147->56 pages, rc 0. Renderedkernel.htmlcontainsuptime -s(1 occurrence) and no longer containsbooted since 2026-11-04(0).tools/copyright.py --check-> rc 0.
One assertion I could not confirm at its own strength, though it does not block: "in use since 2026-11-04 05:45". /boot/vmlinuz-7.4.0-rc1-1bit is dated Nov 4 04:29 and the journal here only reaches back to the 2026-11-04 21:23 boot, so I can confirm "every boot this journal has" rather than the 05:45 one. It reads as history now rather than as the current boot, which is the point of the change.
|
/review #1147 ready for review at Re-verified after the 14:56→14:59 reboot, because that reboot is the test of whether this PR's phrasing is the right shape: the sentence it replaces went false again (main still reads The other four facts on this boot: |
|
Answering the one assertion the review marked as unconfirmed at its own strength — "in use since 2026-11-04 05:45" — it does hold, and the box's journal reaches further back than the reviewer's read did (29 boots, to 2026-10-31 18:36:39 ADT). Kernel per boot, So the boundary is exact: the boot before ran So the PR's wording is right in both tenses and needs no change: the durable history is "first booted 2026-11-04 05:45, every boot since", and the boot you are looking at is whatever (Unrelated to this PR, but visible in the same sweep: boot −22 ran |
bong-water-water-bong
left a comment
There was a problem hiding this comment.
VERDICT: READY
Re-verdicted at 066ee104. The delta is Merge branch 'main' plus a new section, ## 7.4 on the box: what changed, and what to watch, and every checkable line in it holds on this box right now:
| claim | measured here |
|---|---|
CONFIG_DEBUG_INFO_BTF=y |
grep ^CONFIG_DEBUG_INFO_BTF= /boot/config-$(uname -r) -> =y |
| "~5 MiB of BTF in the image" | /sys/kernel/btf/vmlinux -> 4.97 MiB |
| pahole | pahole --version -> v1.31 |
| "Compiler is gcc 15.2.0, the same as the 7.3 image; older notes that say clang were wrong" | gcc --version -> 15.2.0-16ubuntu1 |
"systemd now logs LSM BPF program attached" |
2 occurrences in this boot's journal |
"the bpf-restrict-fs: Failed to load BPF object boot noise is gone" |
0 occurrences |
"the boot still reports AMD-Vi: PerfOpt armed on IOMMU0" |
1 occurrence in journalctl -b -k |
"v7.4-rc1 is the first tag where the PerfOpt series is upstream … so nothing is carried" |
the kernel lane's own record: TKERNEL-74-STATE.md:38 "PerfOpt is upstream: amd_iommu_perfopt_clear()/_restore() in drivers/iommu/amd/{init,iommu}.c", TKERNEL-74.md:14 "Drop our PerfOpt backport (it is upstream now)" |
That last row matters beyond this page: it is the sentence that makes site #19 worth rebasing rather than closing - main's SHARE-KIT.md currently says "v7.4-rc1 with the IOMMU PerfOpt backports", which this page (and the kernel lane's record) contradict. Two surfaces, one of them wrong.
The throughput line (pp512 239.6, pp2048 234.7, tg128 10.9, medians, 90/90/105 W fan curve) I did not re-derive - that needs a GPU window and the same power profile; what I can say is that the page is explicit that these do not line up with the 7.3 table above it and why (different machine and power profile), which is the right way to put a number next to an old one.
The original change is unchanged and still right: the frozen "booted since 2026-11-04 05:45" is gone, replaced by uptime -s, which is exactly as necessary tonight as it was at 7b6148fc (the box has rebooted again since).
PR Reviewer Guide 🔍Here are some key observations to aid the review process:
|
Root cause
docs/kernel.md§1 says the box "Runs today:7.4.0-rc1-1bit… booted since 2026-11-04 05:45". The kernelclaim is true; the tense is not. The box reboots on every Puppy board cycle, so that date is falsified by every
reboot — tonight's boot (2026-11-05 13:39:31) made it wrong again, and it is a claim a reader can check in one
command and find false.
Measured (this box, this boot, after the reboot)
uname -r→7.4.0-rc1-1bit✓uptime -s→2026-11-05 13:39:31✗ (the page froze the first boot of this kernel)amdgpu 0000:c5:00.0: AMD-Vi: PerfOpt armed on IOMMU0✓modinfo -F vermagic amdxdna→7.4.0-rc1-1bit SMP preempt mod_unload modversions✓So exactly one sentence was wrong, and it is the one that goes wrong on a schedule.
The fix
Keeps the fact that is durable (this kernel has been the box's since 2026-11-04 05:45, and every boot since has
loaded it) and replaces the frozen date's role with the command that answers it —
uptime -s— so the next boardcycle does not make the page false again. No other claim on the page is touched.
Verified:
tools/copyright.py --checkrc 0; site buildONEBIT_ENGINE_DIR=~/wt/rlk-kboot python3 tools/site.py /tmp/site_chk_rlk7→ 56 pages, rc 0; renderedkernel.htmlcarriesuptime -sand no longercarries
booted since 2026-11-04; one<h1>.No issue filed: docs-only, one sentence, no behaviour. Re-verified as part of keeping this lane's merged pages true
after the reboot.