fix(build): install Xorg into a staging root, not over the base rootfs - #678
Merged
Conversation
The build-time `apk add --root rootfs/x86_64 --initdb` clobbered the base system: --initdb starts from an empty database, so to satisfy xorg-server apk pulls the ENTIRE dependency closure (musl, libc, ld-musl, base libs) and writes it over Eclipse's hand-staged busybox/musl. The result booted to every VT shell SIGSEGV'ing identically (jump to a garbage PC 0x6100 through the broken loader), one of which tripped the new descriptive panic "Thread::lock_linux(): ... has no LinuxThread ext" during teardown. Fix: install into a throwaway staging root (ignored/xorg-stage), then copy ONLY the X-owned trees into the real rootfs — usr/bin, usr/lib, usr/libexec, usr/share, etc/fonts, etc/X11 — never bin/ lib/ sbin/ or base /etc. The base loader/libc/busybox are preserved; X is purely additive (musl lives in /lib, which is skipped, so usr/lib carries only the X + mesa libs). Also create the `libc.musl-x86_64.so.1 -> ld-musl-x86_64.so.1` alias the Alpine X binaries link against, additively, so they resolve libc against the base's own musl. xtask builds; fmt/clippy clean. NOTE for anyone with an already-broken rootfs from the previous build: clear it (`rm -rf rootfs/x86_64`) before rebuilding so the base is re-staged fresh — the incremental build path does not restore a clobbered /lib/ld-musl. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MHCn5RNRcwR5PY1sYBHY2S
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
2 participants
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.
The build-time
apk add --root rootfs/x86_64 --initdbclobbered the base system: --initdb starts from an empty database, so to satisfy xorg-server apk pulls the ENTIRE dependency closure (musl, libc, ld-musl, base libs) and writes it over Eclipse's hand-staged busybox/musl. The result booted to every VT shell SIGSEGV'ing identically (jump to a garbage PC 0x6100 through the broken loader), one of which tripped the new descriptive panic "Thread::lock_linux(): ... has no LinuxThread ext" during teardown.Fix: install into a throwaway staging root (ignored/xorg-stage), then copy ONLY the X-owned trees into the real rootfs — usr/bin, usr/lib, usr/libexec, usr/share, etc/fonts, etc/X11 — never bin/ lib/ sbin/ or base /etc. The base loader/libc/busybox are preserved; X is purely additive (musl lives in /lib, which is skipped, so usr/lib carries only the X + mesa libs). Also create the
libc.musl-x86_64.so.1 -> ld-musl-x86_64.so.1alias the Alpine X binaries link against, additively, so they resolve libc against the base's own musl.xtask builds; fmt/clippy clean.
NOTE for anyone with an already-broken rootfs from the previous build: clear it (
rm -rf rootfs/x86_64) before rebuilding so the base is re-staged fresh — the incremental build path does not restore a clobbered /lib/ld-musl.Claude-Session: https://claude.ai/code/session_01MHCn5RNRcwR5PY1sYBHY2S