fix(qemu): heal libaio.so.1t64 soname on Arch/Fedora + skip sudo /etc/hosts spam (#40)#41
Merged
Merged
Conversation
…s spam (#40) The bundled vee-qemu build is compiled on a Debian-family host, so on Linux its DT_NEEDED records the Debian 64-bit-time_t soname `libaio.so.1t64`. Distros that ship only the upstream `libaio.so.1` (Arch, Fedora, …) can't satisfy it, so `vee start` failed with: error while loading shared libraries: libaio.so.1t64: cannot open shared object file: No such file or directory The ABI is identical on 64-bit architectures — only the filename differs. Fix (issue #40 suggested option 3): on Linux, qemubin now reads the QEMU binary's DT_NEEDED entries and, for any `*t64` soname the host cannot resolve but whose un-suffixed variant exists, creates an ABI-compatible compat symlink in `~/.vee/bin/` (e.g. `libaio.so.1t64 -> /usr/lib/libaio.so.1`). This runs on both fresh install and the already-installed fast path, so existing installs self-heal on the next `vee start`. Because the managed binary has no rpath, the QEMU launcher now also prepends the binary's directory to `LD_LIBRARY_PATH` on Linux so the loader finds the compat symlink; darwin/windows keep inheriting the parent env. The whole shim is Debian-transition-generic, not hardcoded to libaio. Also fixes the secondary complaint: post-boot hostname registration now probes for passwordless sudo (or a writable /etc/hosts) via `CanWriteHosts()` and skips registration with a single info-level log instead of failing and warning on every boot when sudo would prompt. `removeHostsEntry` short-circuits when the entry is already absent so unregister on such hosts is a clean no-op. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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.
Fixes #40.
Problem 1 — bundled QEMU fails to start on Arch/Fedora
After the v0.3.2 auto-update pulled a new bundled QEMU,
vee startfails on Arch Linux:The vee-qemu bundle is built on a Debian-family host, so on Linux the binary's
DT_NEEDEDrecords the Debian 64-bit-time_tsonamelibaio.so.1t64. Distros that ship only the upstreamlibaio.so.1(Arch, Fedora, …) can't satisfy it. On 64-bit architectures the ABI is identical — only the filename differs.Fix (issue's suggested option 3, generalized)
internal/qemubin/libcompat_linux.goreads the QEMU binary'sDT_NEEDEDentries viadebug/elf. For any*t64soname the host cannot resolve but whose un-suffixed variant exists, it creates an ABI-compatible compat symlink in~/.vee/bin/(e.g.libaio.so.1t64 -> /usr/lib/libaio.so.1). Generic to the whole Debian time_t transition, not hardcoded to libaio. No-op stub off Linux.Ensure()on both the fresh-install path and the already-installed fast path, so existing broken installs self-heal on the nextvee start.qemuEnv()now prepends the binary's directory toLD_LIBRARY_PATHon Linux at launch. darwin/windows inherit the parent env unchanged.Problem 2 —
/etc/hostsregistration logs a sudo failure every bootv0.3.2's post-boot hostname registration needs root and warned on every start when passwordless sudo wasn't available (non-fatal, VM still booted).
CanWriteHosts()probes for a writable/etc/hostsor passwordless sudo (sudo -n -v). The manager now skips registration with a single info-level log instead of attempting it and warning every boot.removeHostsEntryshort-circuits when the entry is already absent, so unregister on such hosts is a clean no-op.Verification
End-to-end on an Arch host:
qemu-system-x86_64 --versionfails with the exact issue error.~/.vee/bin/libaio.so.1t64 -> /usr/lib/libaio.so.1recreated.LD_LIBRARY_PATH=$HOME/.vee/bin qemu-system-x86_64 --version→QEMU emulator version 10.0.2, exit 0.All three platforms cross-build (
linux/darwin/windows), full test suite passes,golangci-lintclean, new unit tests added. Docs updated indocs/prerequisites.md(managed-QEMU compat note + hostname/sudo behavior).🤖 Generated with Claude Code