Repository navigation
glibc-bedrock-2.42: seal only the sysroot subtree, not a whole second glibc - #940
bryan-minimal wants to merge 1 commit into
Conversation
… glibc The sealed (hex0 switch off) arm pinned d0850b65, the artifact the production glibc's replace_on_cycle slot anchors on. Besides the versioned sysroot under usr/lib/glibc-bedrock-2.42/, it carries a full top-level glibc 2.42 (usr/lib/libc.so.6, ld-linux-x86-64.so.2, crt*.o, gconv, usr/include, usr/bin). A prebuilt lands as its whole tarball (minimal skips outputs globs for it), so every bare import put that 2.42 libc in the sandbox's merged /usr/lib next to production glibc 2.44, and the lower spec hash won. That is the pkgs#895 classpath-0.93 FTBFS (`sort: GLIBC_2.43 not found`). Pin 62d398ef instead: d0850b65 with every tar entry outside usr/lib/glibc-bedrock-2.42 dropped. The kept tar records are byte-identical to the original (order, headers, mtimes; uncompressed sha256 96759457...), recompressed with zstd -5 --no-check. The sealed arm's outputs narrow to sysroot_lib + sysroot_include so they say what the tarball holds. Nothing used the dropped tree: the sysroot is a superset of its headers and libraries, every consumer reaches glibc through SR=/usr/lib/glibc-bedrock-2.42, and the only top-level reference (jikes-1.22 build.sh) is a `|| true` diagnostic. Production glibc keeps d0850b65, which its cycle root needs whole. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to
|
| Check name | Status | Explanation |
|---|---|---|
| Description Check |  |
Check skipped - CodeRabbit’s high-level summary is enabled. |
| Title check | |
The title clearly and concisely describes the main change: the sealed configuration now exports only the glibc sysroot subtree instead of a full second glibc tree. |
| Docstring Coverage | |
No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0… |
| Linked Issues check | |
Check skipped because no linked issues were found for this pull request. |
| Out of Scope Changes check | |
Check skipped because no linked issues were found for this pull request. |
Full details: Docstring Coverage
-
Explanation
No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0 files. (1 skipped: 1 unsupported.)
✨ Finishing Touches
-
🧪 Generate unit tests (beta)
-
- Commit to this branch
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Comment @coderabbitai help to get the list of available commands.
|
Verified against the failing case. On the lab (amd64, mip), I built
Without the fix, the same tree with the original bedrock tarball reproduces the prod failure: 🤖 Generated with Claude Code |
There was a problem hiding this comment.
This looks like the right root-cause fix. I re-derived the artifact:
- The tarball's sha256 is
62d398ef…, and uncompressed it is96759457…, matching the PR. - All 2,628 sysroot members are identical to d0850b65's (type, mode, mtime, link target and content sha), and nothing else remains outside
usr/lib/glibc-bedrock-2.42. - crt files,
libc_nonshared.a, the loader,libm*/libmvec*,gconv/and the headers are all present, andlibc.soalready points inside the sysroot. - CI is green, and the 52-minute build looks like a real JVM-ladder rebuild.
Holding approval on one decision: the new artifact is hand-repacked and uploaded to staging, with no seal or in-toto envelope, replacing the minimermetic-attested d0850b65. It can be re-derived (as above), but I want to confirm we're OK with an unattested bedrock before approving. The alternative is #941, which keeps the attested artifact and filters it.
Other points:
- Two linker scripts in the sysroot point outside it.
…/lib/libm.soreadsGROUP(/usr/lib/libm.so.6 AS_NEEDED(/usr/lib/libmvec.so.1))and…/lib/libm.areadsGROUP(/usr/lib/libm-2.42.a /usr/lib/libmvec.a). After this PR,/usr/lib/libm.so.6is always production 2.44, and/usr/lib/libm-2.42.ano longer exists anywhere.- The JVM rungs only rewrite
libc.so(e.g.openjdk-17/build.sh:57-59), so-lmlinks against 2.44 but loads 2.42 at runtime through the$SR/librpath. - That's already true on main, so it isn't a regression. Still, the body's "nothing used the dropped tree" should mention it, and the JVM rungs need a follow-up libm fixlib rewrite, as the GHC ladder does (
ghc-7.6.3/build.sh:84-85).
- The JVM rungs only rewrite
- The body cites #937 as the companion change, but #937 was closed unmerged. Please reference #941, or say no companion is needed.
- FYI: the current recipe (
build.sh:155-167) rewrites every sysroot linker script, but the sealed artifact still has the/usr/lib/libm…paths, so the sealed tarball predates today's recipe. - The
minimal buildbox in the test plan can be ticked.
Generated by Claude Code
|
@norrietaylor thanks for re-deriving it. Point by point:
The attestation question you're holding on is Bryan's call. I've laid out the options for him: take #941 now (attested, JVM-only), take this as-is (unattested but re-derivable, as you showed), or re-seal the sysroot-only artifact through minimermetic before merging. Either #940 or #941 unblocks #950 and #895, since the classpath-0.93 failure is what kills those runs. 🤖 Generated with Claude Code |
|
Closing in favour of #941. Both fix the same failure (the glibc-bedrock-2.42 libc collision that breaks classpath-0.93 whenever python rehashes glibc: #895, #950), and landing both would cost two ~50-minute amd64 JVM-ladder rebuilds for no extra coverage today. Why #941 over this one:
If we want the broader fix later: re-seal the sysroot-only artifact through minimermetic, then revive this change against the attested tarball. The repacked object stays at Thanks @norrietaylor and Mike for the reviews. The libm linker-script caveat noted here applies to #941 as well and is documented there. 🤖 Generated with Claude Code |
Summary
The sealed (hex0 switch off) arm of
glibc-bedrock-2.42now pins a sysroot-only artifact instead of the whole d0850b65 bedrock glibc.The problem. d0850b65 is also the production
glibc'sreplace_on_cycleroot, so besides the versioned sysroot underusr/lib/glibc-bedrock-2.42/it ships a full top-level glibc 2.42:usr/lib/libc.so.6,ld-linux-x86-64.so.2,crt*.o,gconv/,usr/include/**,usr/bin/*andusr/share/{i18n,locale}. minimal materializes aprebuilt = truepackage as its whole tarball and skips theoutputsglobs (only a consumer'ssubsetOffilters). So every bareimportof glibc-bedrock-2.42 (the 28 JVM rungs, plus theirruntime_deps) put a 2.42 libc in the merged/usr/libnext to production glibc 2.44. When two deps ship the same path, the one with the lower spec hash wins and the collision only produces a warning. That is the pkgs#895 classpath-0.93 FTBFS (sort: GLIBC_2.43 not found), and any rehash upstream could cause it again.The fix. This PR fixes the artifact itself, so no bare import (now or later 8000 ) can bring the collision back.
pkgs#937(closed:subsetOfinbuild_depspanics minimal's executor). The JVM-only alternative is pkgs#941, which keeps the attested artifact and takes the sysroot slice through a collection. The two are compatible; either alone fixes #895. No companion change is required.gs://minimal-staging-archives/prebuilts/bedrock/sha256/62d398ef1e1b689664b982f43d0cfb3570ee2133c6be3ded434c4bb9d1c747bc/glibc-bedrock-2.42-sysroot-2.42.tar.zst(7.2 MB, down from 19.6 MB).usr/lib/glibc-bedrock-2.42(plus theusrandusr/libdir entries) unchanged. The order, headers,HeaderMode::Deterministicmtimes and GNU format all match the original, and the stream ends with tar-rs's two zero blocks. Recompressed withzstd -5 --no-check, which matches the level and no-checksum setting of minimal'scompress_dir; the compressed bytes can't match tar-rs's encoder exactly. Uncompressed tar sha256:96759457b66774c09ac50923235a5873469d2daa18c09626cbc4fc43efc2565b.etcandusr) reproduces the original tar byte-for-byte;diff -r --no-dereferenceof the extracted sysroot, original against repack, shows no differences (2630 entries kept, 1457 dropped); and a re-download from GCS matches the sha above.outputsare nowsealed_outputs = { sysroot_lib, sysroot_include }, so they say what the tarball holds. The from-source arm (switch on) keepsall_outputsunchanged.Nothing used the dropped tree.
…/include, and every top-levelusr/liblibrary and crt is also under…/lib, exceptaudit/andlocale/, which no consumer references.SR=/usr/lib/glibc-bedrock-2.42, with includes-isystem $SR/includefirst,-B$SR/lib -L$SR/liband the loader at$SR/lib. This covers the 28 JVM rungs, jikes, go-1.4/1.17/1.20/1.22/1.24, mrustc and mrustc-rustc, rustc-1.91.1, binutils-2.46-glibc and gcc-15.2.0-glibc./usr/lib/libc.so.6is a|| truediagnostic in jikes-1.22's failure path.subsetOf … ["sysroot_lib"].Not changed. Production
glibc'sreplace_on_cyclekeeps d0850b65. It needs the top-level layout, and minimermetic'supdate-bedrock-roots.pymanages that row (glibc Amd64). The minimermetic seals and in-toto envelopes cover d0850b65. This artifact is a deterministic subset of it that anyone can re-derive with the steps above; it is not separately attested.Test plan
MINIMAL_SCIENCE_MODE=1 mip dump --packagesevaluates on amd64 and arm64.minimal buildon this PR (the JVM ladder rungs rehash): green, a real 52-minute JVM-ladder rebuild.🤖 Generated with Claude Code
Summary by CodeRabbit
Known limitation (pre-existing, not a regression; thanks @norrietaylor): two linker scripts inside the sysroot still point outside it.
usr/lib/glibc-bedrock-2.42/lib/libm.soisGROUP(/usr/lib/libm.so.6 AS_NEEDED(/usr/lib/libmvec.so.1))andlib/libm.aisGROUP(/usr/lib/libm-2.42.a /usr/lib/libmvec.a). The JVM rungs only rewritelibc.so(e.g.openjdk-17/build.sh:57-59), so-lmlinks against production libm (2.44) while the$SR/librpath loads 2.42 at runtime. That was already true on main. The follow-up is a libm fixlib rewrite in the JVM rungs, as the GHC ladder does (ghc-7.6.3/build.sh:84-85). The sealed tarball also predates today's recipe, which rewrites every sysroot linker script (build.sh:155-167).