fix(installer): stamp the real module version into the packaged dkms.conf#15
Merged
Conversation
…conf
The in-tree dkms.conf ships PACKAGE_VERSION="unknown" and the installer's
fallbacks can't resolve it from a packaged app: generate-version.sh is
git-describe based (and lives at vds/generate-version.sh, outside the
bundled vds/module/, so it isn't even shipped), and OPENDS5_MODULE_VERSION
is only set when the installer is spawned by the companion. A direct
`sudo opends5-install` therefore fell through to the 0.0.0 last resort --
which is what is registered on real machines today.
Stamp the app version into the staged dkms.conf during afterPack so the
bundled copy is self-describing regardless of how the installer is invoked.
The in-tree file stays "unknown" so repo builds still resolve it via git.
Stamping the real version exposes a latent leak in the upgrade path:
plan_dkms only ran `dkms remove vds_hcd/${MODULE_VER}`, which was
idempotent while MODULE_VER was always 0.0.0, but would now strand the
previous registration on every version bump, leaving two DKMS entries
fighting over the same /extra/vds_hcd.ko. Enumerate and remove every
registered vds_hcd instead.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
LordVicky
force-pushed
the
fix/dkms-module-version
branch
from
July 12, 2026 05:39
ca7e4b4 to
659ec77
Compare
This was referenced Jul 12, 2026
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.
The bug
The vds module registers with DKMS as
vds_hcd/0.0.0on real installs. Confirmed on a live machine:Why
vds/module/dkms.confshipsPACKAGE_VERSION="unknown"by design, andresolve_module_source()resolves the real version through a fallback chain. Neither link can fire in a packaged app:OPENDS5_MODULE_VERSION— only set when the installer is spawned by the companion (install-system-cli.ts,setup-service.ts). A directsudo opends5-installdoesn't get it.generate-version.sh— isgit describe-based, so it printsunknownwithout a git repo. It also lives atvds/generate-version.sh, outside the bundledvds/module/, so it isn't shipped at all — the installer looks for it atresources/generate-version.sh, which doesn't exist.→ falls through to the
0.0.0last resort. It works in a repo checkout, which is why it went unnoticed.Fix
Stamp the app version into the staged
dkms.confduringafterPack, so the bundled copy is self-describing however the installer is invoked. The in-tree file stays"unknown"so repo builds still resolve via git.(The staging test fixture already wrote
PACKAGE_VERSION="1.6.3"into its simulated bundle — the stamping step was intended, just never implemented.)Second-order fix: upgrade-path leak
Stamping the real version exposes a latent bug.
plan_dkmsonly ran:dkms remove vds_hcd/${MODULE_VER}That was accidentally idempotent while
MODULE_VERwas always0.0.0. With a real version it stops matching the previous registration, so every version bump strands the old one — two DKMS entries fighting over the same/extra/vds_hcd.ko, which DKMS can error on. Now enumerates and removes every registeredvds_hcd.Simulated upgrade against a fake
dkmsreporting stale0.0.0+1.5.0:Verification
resources/vds-module/dkms.conf→PACKAGE_VERSION="1.6.3".vds/module/dkms.confunchanged ("unknown").dkms statusparsing tested against modern (vds_hcd/0.0.0,) and legacy (vds_hcd, 0.0.0,) output formats.test-plan.shcovers the enumeration.Note for existing installs
Machines already carrying
vds_hcd/0.0.0get it cleaned up automatically on the next install, since the removal now enumerates all versions.🤖 Generated with Claude Code