Repository navigation
docs(§2): document host/guest runtime drift in the KVM lab chapter - #28
Open
patterncatalyst wants to merge 1 commit into
Open
patterncatalyst wants to merge 1 commit into
patterncatalyst wants to merge 1 commit into
Conversation
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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes the last open item from r26.
Why here
ch02 already named the assumption:
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:
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:
g++said 16.1.1 and the guest'srpm -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-peerhad 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
dnffix, and the revert-then-rerun proof (8 passed, 0 failed, 0 skipped, including the two-guest41-capstone-fleet).Marked unverified in the same footer: the
GLIBC_form of the symbol check is stated by analogy, since the real failure wasGLIBCXX_only; and building with the in-VM toolchains is named as the standing fallback but is exercised by no example in the book.validate.pyOK.