Skip to content

docs(§2): document host/guest runtime drift in the KVM lab chapter - #28

Open
patterncatalyst wants to merge 1 commit into
mainfrom
docs/r27-ch02-runtime-drift
Open

patterncatalyst wants to merge 1 commit into
mainfrom
docs/r27-ch02-runtime-drift

Conversation

@patterncatalyst

Copy link
Copy Markdown
Owner

Closes the last open item from r26.

Why here

ch02 already named the assumption:

This works because host builds and the guest are both Fedora 44 (glibc parity); the in-VM toolchains are the fallback when that assumption breaks.

It named it and stopped — no account of how it breaks, how to recognise it, or how to fix it so the fix survives. r26 found out the hard way.

Two corrections

That sentence overstated its case twice:

  • it called the condition standing when it is only a starting condition — a snapshot freezes the guest while the workstation keeps updating;
  • it named glibc, but the drift that actually bit was libstdc++. glibc was identical at 2.43 on both sides throughout.

The new section

"When the guest falls behind the host", after Deploying host builds, plus a matching What you learned bullet.

It leads with what the failure looks like rather than what it is, because that's the part that costs time. Run through a demo's harness, the binary just never starts, and every assertion downstream blames the demo — a port that never opened, a Landlock line that never printed, an OOM that never happened. The loader message is the only place the truth appears, and only if you run the binary by hand.

Two things that generalise past this book:

  • The tell is which language fails. C++ failing where Go and Rust pass on the same guest in the same run is a runtime-parity signature, not a C++ bug — Go and Rust link statically.
  • Do not compare compiler versions. They agreed here and proved nothing: g++ said 16.1.1 and the guest's rpm -q libstdc++ said 16.1.1, while the host's libstdc++ had moved to 16.2.1 underneath both. Compare the symbol versions the loader actually resolves.

And it insists on the two halves people drop: fix every guest, not the one that failed (systems-peer had the identical drift and no symptom, because no C++ binary is deployed to it), and re-snapshot, or the next revert silently restores the break.

Evidence

The footer states the new section's evidence separately from the chapter's original provisioning run — the version table, the reproduced six-example asymmetry, the dnf fix, and the revert-then-rerun proof (8 passed, 0 failed, 0 skipped, including the two-guest 41-capstone-fleet).

Marked unverified in the same footer: the GLIBC_ form of the symbol check is stated by analogy, since the real failure was GLIBCXX_ only; and building with the in-VM toolchains is named as the standing fallback but is exercised by no example in the book.

validate.py OK.

Closes the last open item from r26. ch02 already named the assumption --
"host builds and the guest are both Fedora 44 (glibc parity)" -- but not
how it breaks, how to recognise it, or how to fix it durably. r26 found
out the hard way, so the chapter now says it.

Two corrections and one new section:

- the parity sentence overstated its case twice. It called the condition
  standing when it is only a STARTING condition, and it named glibc when
  the drift that actually bit was libstdc++ -- glibc was identical at 2.43
  on both sides throughout.
- new "When the guest falls behind the host" after Deploying host builds,
  and a matching "What you learned" bullet.

The section leads with what the failure LOOKS like rather than what it is,
because that is the part that costs time: run through a harness the binary
just never starts, and every assertion downstream blames the demo -- a
port that never opened, a Landlock line that never printed, an OOM that
never happened. The loader message is the only place the truth appears.

Two things I'd have wanted in advance and that generalise past this book:

- the tell is WHICH LANGUAGE fails. C++ failing where Go and Rust pass on
  the same guest in the same run is a runtime-parity signature, not a C++
  bug, because Go and Rust link statically.
- do NOT compare compiler versions. They agreed here and proved nothing:
  g++ said 16.1.1 and the guest's rpm said 16.1.1 while the host's
  libstdc++ had moved to 16.2.1 underneath both. Compare the symbol
  versions the loader actually resolves.

It also insists on the two halves people drop: fix EVERY guest, not the
one that failed (systems-peer had the identical drift and no symptom,
because no C++ binary is deployed to it), and RE-SNAPSHOT, or the next
revert silently restores the break.

Footer states the new section's evidence separately from the chapter's
original run, and marks two things unverified: the GLIBC_ form of the
check is stated by analogy (the real failure was GLIBCXX_ only), and
building with the in-VM toolchains is named as the fallback but is not
exercised by any example in the book.

validate.py OK.

This branch has not been deployed

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant