Skip to content

fix(installer): stamp the real module version into the packaged dkms.conf#15

Merged
LordVicky merged 1 commit into
devfrom
fix/dkms-module-version
Jul 12, 2026
Merged

fix(installer): stamp the real module version into the packaged dkms.conf#15
LordVicky merged 1 commit into
devfrom
fix/dkms-module-version

Conversation

@LordVicky

Copy link
Copy Markdown
Owner

The bug

The vds module registers with DKMS as vds_hcd/0.0.0 on real installs. Confirmed on a live machine:

$ dkms status
vds_hcd/0.0.0, 7.1.2-cachyos1.fc44.x86_64, x86_64: installed
$ ls /usr/src/vds_hcd-*
/usr/src/vds_hcd-0.0.0

Why

vds/module/dkms.conf ships PACKAGE_VERSION="unknown" by design, and resolve_module_source() resolves the real version through a fallback chain. Neither link can fire in a packaged app:

  1. OPENDS5_MODULE_VERSION — only set when the installer is spawned by the companion (install-system-cli.ts, setup-service.ts). A direct sudo opends5-install doesn't get it.
  2. generate-version.sh — is git describe-based, so it prints unknown without a git repo. It also lives at vds/generate-version.sh, outside the bundled vds/module/, so it isn't shipped at all — the installer looks for it at resources/generate-version.sh, which doesn't exist.

→ falls through to the 0.0.0 last resort. It works in a repo checkout, which is why it went unnoticed.

Fix

Stamp the app version into the staged dkms.conf during afterPack, 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_dkms only ran:

dkms remove vds_hcd/${MODULE_VER}

That was accidentally idempotent while MODULE_VER was always 0.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 registered vds_hcd.

Simulated upgrade against a fake dkms reporting stale 0.0.0 + 1.5.0:

REMOVED vds_hcd/0.0.0
REMOVED vds_hcd/1.5.0
ADD vds_hcd/1.6.3
INSTALL vds_hcd/1.6.3

Verification

  • Rebuilt AppImage, mounted it: resources/vds-module/dkms.confPACKAGE_VERSION="1.6.3".
  • In-tree vds/module/dkms.conf unchanged ("unknown").
  • dkms status parsing tested against modern (vds_hcd/0.0.0,) and legacy (vds_hcd, 0.0.0,) output formats.
  • 12/12 installer tests pass, 411/411 companion tests pass. New assertion in test-plan.sh covers the enumeration.

Note for existing installs

Machines already carrying vds_hcd/0.0.0 get it cleaned up automatically on the next install, since the removal now enumerates all versions.

🤖 Generated with Claude Code

…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
LordVicky force-pushed the fix/dkms-module-version branch from ca7e4b4 to 659ec77 Compare July 12, 2026 05:39
@LordVicky
LordVicky merged commit 2a441b5 into dev Jul 12, 2026
1 check passed
@LordVicky
LordVicky deleted the fix/dkms-module-version branch July 12, 2026 05:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant