Skip to content

docs/kernel: the boot date is a moving fact, so point the reader at uptime -s - #1147

Merged
bong-water-water-bong merged 2 commits into
mainfrom
docs/kernel-boot-date-durable
Nov 5, 2026
Merged

bong-water-water-bong merged 2 commits into
mainfrom
docs/kernel-boot-date-durable

Conversation

@bong-water-water-bong

Copy link
Copy Markdown
Collaborator

Root cause

docs/kernel.md §1 says the box "Runs today: 7.4.0-rc1-1bit … booted since 2026-11-04 05:45". The kernel
claim 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)

claim in the page measured now
the kernel that runs uname -r → 7.4.0-rc1-1bit ✓
"booted since 2026-11-04 05:45" uptime -s → 2026-11-05 13:39:31 ✗ (the page froze the first boot of this kernel)
PerfOpt is present in it boot prints amdgpu 0000:c5:00.0: AMD-Vi: PerfOpt armed on IOMMU0 ✓
the out-of-tree modules load 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 board
cycle does not make the page false again. No other claim on the page is touched.

Verified: tools/copyright.py --check rc 0; site build ONEBIT_ENGINE_DIR=~/wt/rlk-kboot python3 tools/site.py /tmp/site_chk_rlk7 → 56 pages, rc 0; rendered kernel.html carries uptime -s and no longer
carries 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.

…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.
@bong-water-water-bong

Copy link
Copy Markdown
Collaborator Author

#1147 ready for review at 7b6148f — one sentence in docs/kernel.md: the frozen boot date (2026-11-04 05:45) is falsified by every board-cycle reboot (tonight's boot is 2026-11-05 13:39), so the page now states the durable fact and points at uptime -s. Copyright rc 0, site build 56 pages rc 0, rendered kernel.html verified.

@bong-water-water-bong bong-water-water-bong left a comment

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 -k carries one PerfOpt armed on IOMMU0.
  • The defect is demonstrable twice over now: journalctl --list-boots shows the box booted at 2026-11-05 13:39:33 and again at 14:59:37, so the body's own measured uptime -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. Rendered kernel.html contains uptime -s (1 occurrence) and no longer contains booted 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.

@bong-water-water-bong

Copy link
Copy Markdown
Collaborator Author

/review

#1147 ready for review at 7b6148f — docs only, 1 file, +4/−2.

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 booted since 2026-11-04 05:45; this boot started 14:59:35 on 2026-11-05), and the replacement stayed true — uptime -s is the answer for the boot in front of you.

The other four facts on this boot: uname -r = 7.4.0-rc1-1bit; uptime -s = 2026-11-05 14:59:35; boot prints amdgpu 0000:c5:00.0: AMD-Vi: PerfOpt armed on IOMMU0; /proc/config.gz → CONFIG_CC_IS_GCC=y, CONFIG_GCC_VERSION=150200 (so the compiler correction below it still holds). The PR's "in use since 2026-11-04 05:45, every boot since has loaded it" is now checked boot by boot, not asserted: journal boots −7..0 (2026-11-04 05:45:40 → now) all report Linux version 7.4.0-rc1-1bit, and /boot carries no kernel image newer than that one (built 2026-11-04 04:29).

@bong-water-water-bong

Copy link
Copy Markdown
Collaborator Author

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, journalctl -b <idx> -k → first Linux version line:

boot  -8  2026-11-04 01:55:25   7.3.0-rc4-1bit-perfopt+
boot  -7  2026-11-04 05:45:40   7.4.0-rc1-1bit      <- first boot on it
boot  -6 .. 0  (11-04 08:36:57 … 2026-11-05 14:59:37)   7.4.0-rc1-1bit

So the boundary is exact: the boot before ran 7.3.0-rc4-1bit-perfopt+, and every one of the eight boots since (journal indexes −7…0) ran 7.4.0-rc1-1bit — the 05:45:40 boot included, which is the one the sentence names. /boot/vmlinuz-7.4.0-rc1-1bit is dated 2026-11-04 04:29 (built 16 minutes before that first boot) and there is no newer kernel image in /boot (the other images are 7.3.0-rc4-1bit-perfopt+, its unsigned twin, and 7.0.0-42-generic).

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 uptime -s says — which is the whole point, since this session's own 14:59:37 boot falsified the old sentence a second time.

(Unrelated to this PR, but visible in the same sweep: boot −22 ran 7.0.0-42-generic between two 7.3 boots, so the box has had the distro kernel in the middle of its history. The page's claim is about the kernel it runs today, so it is unaffected — mentioning it because a reader could otherwise be surprised by that line in journalctl --list-boots.)

@bong-water-water-bong bong-water-water-bong left a comment

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

@bong-water-water-bong
bong-water-water-bong merged commit a2ce293 into main Nov 5, 2026
9 checks passed
@bong-water-water-bong
bong-water-water-bong deleted the docs/kernel-boot-date-durable branch November 5, 2026 21:34
@github-actions

github-actions Bot commented Nov 5, 2026

Copy link
Copy Markdown

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 1 🔵⚪⚪⚪⚪
🧪 No relevant tests
🔒 No security concerns identified
⚡ Recommended focus areas for review

Outdated Information

The previous wording stated that the kernel was booted since a fixed date (2026-11-04 05:45), which becomes incorrect after each reboot. The updated documentation correctly addresses this by directing readers to use uptime -s to get the actual boot time, ensuring the information remains accurate across reboots.

- **Runs today:** `7.4.0-rc1-1bit` — Linux `v7.4-rc1`, in use since 2026-11-04 05:45
  (`/boot/vmlinuz-7.4.0-rc1-1bit`); every boot since has loaded it, and the box reboots on each Puppy
  board cycle, so read `uptime -s` for the boot you are looking at. PerfOpt is present in it,
  measured: this box's boot prints
  `amdgpu 0000:c5:00.0: AMD-Vi: PerfOpt armed on IOMMU0`. The 7.3 A/B below stays as the measurement

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant