daedalus-v4l2-dkms: postinst — autoinstall for all installed kernels (#64) #65

Merged
marfrit merged 1 commits from claude-noether/marfrit-packages:fix/daedalus-dkms-multi-kernel-64 into main 2026-05-21 09:28:47 +00:00
Contributor

Fixes #64.

Symptom (recap)

On higgs (Pi CM5) the daedalus stack went dark after rebooting into a
newly installed kernel: /dev/daedalus-v4l2 absent, service skipped,
HW video decode silently falling back to software. Package looked fine
in dpkg -l.

Root cause

postinst runs dkms autoinstall "$NAME/$VERSION" (no -k), which
builds the module against $(uname -r) only. The verification block
then dkms status -k "$KERNELVER" also only inspects that one kernel.
A separately-installed kernel (e.g. 6.18.29 when the package was added
under 6.12.88) gets zero coverage and stays moduleless after switch.

Fix

postinst now enumerates every /lib/modules/<kver>/build that
resolves to a real directory (i.e. headers are actually installed
for that kernel) and runs dkms autoinstall -k <kver> for each.
Per-kernel verify; the warning block now aggregates per-kernel
failures with per-kernel finish-commands, instead of fingering only
the running kernel.

Dangling /build symlinks (kernels with no headers installed) are
filtered out by the [ -d "$d" ] test, so we don't spam warnings
about kernels we deliberately don't have headers for.

Note: not migrating to dh-dkms in this PR

The issue's "long-term" suggestion (move to dh-dkms for dpkg-trigger
based auto-rebuild on new-kernel install) is real and worth doing, but
that's a bigger restructure of the build — this hand-rolled dpkg-deb
recipe would have to become an actual debhelper-driven dpkg-source
tree. Tracking that separately.

Manual test

$ mkdir -p /tmp/t/lib/modules/{6.12.88+rpt-rpi-2712,6.18.29+rpt-rpi-2712}
$ ln -s /nonexistent/headers/6.12.88 /tmp/t/lib/modules/6.12.88+rpt-rpi-2712/build
$ ln -s /tmp/t/lib/modules/6.18.29+rpt-rpi-2712 /tmp/t/lib/modules/6.18.29+rpt-rpi-2712/build
$ mkdir /tmp/t/lib/modules/6.18.29+rpt-rpi-2712/build/dummy
$ ( cd /tmp/t && for d in lib/modules/*/build; do [ -d "$d" ] || continue; echo "$(basename "$(dirname "$d")")"; done )
6.18.29+rpt-rpi-2712

Only the kernel whose headers actually resolve is selected — the
dangling-symlink one is correctly skipped.

Smoke plan (post-merge)

  1. CI: arch-aarch64 / debian-aarch64 build (no behaviour change in
    build step, just postinst content; should green).
  2. higgs: apt install daedalus-v4l2-dkms while booted on 6.12.88 with
    6.18.29 headers also present → expect both /lib/modules/6.12.88... /updates/dkms/daedalus_v4l2.ko.xz and the same under 6.18.29.
  3. Reboot into 6.18.29 → /dev/daedalus-v4l2 appears,
    daedalus-v4l2.service not skipped.
Fixes #64. ## Symptom (recap) On higgs (Pi CM5) the daedalus stack went dark after rebooting into a newly installed kernel: `/dev/daedalus-v4l2` absent, service skipped, HW video decode silently falling back to software. Package looked fine in `dpkg -l`. ## Root cause `postinst` runs `dkms autoinstall "$NAME/$VERSION"` (no `-k`), which builds the module against `$(uname -r)` only. The verification block then `dkms status -k "$KERNELVER"` also only inspects that one kernel. A separately-installed kernel (e.g. 6.18.29 when the package was added under 6.12.88) gets zero coverage and stays moduleless after switch. ## Fix `postinst` now enumerates every `/lib/modules/<kver>/build` that resolves to a real directory (i.e. headers are actually installed for that kernel) and runs `dkms autoinstall -k <kver>` for each. Per-kernel verify; the warning block now aggregates per-kernel failures with per-kernel finish-commands, instead of fingering only the running kernel. Dangling `/build` symlinks (kernels with no headers installed) are filtered out by the `[ -d "$d" ]` test, so we don't spam warnings about kernels we deliberately don't have headers for. ## Note: not migrating to `dh-dkms` in this PR The issue's "long-term" suggestion (move to `dh-dkms` for dpkg-trigger based auto-rebuild on new-kernel install) is real and worth doing, but that's a bigger restructure of the build — this hand-rolled `dpkg-deb` recipe would have to become an actual debhelper-driven dpkg-source tree. Tracking that separately. ## Manual test ``` $ mkdir -p /tmp/t/lib/modules/{6.12.88+rpt-rpi-2712,6.18.29+rpt-rpi-2712} $ ln -s /nonexistent/headers/6.12.88 /tmp/t/lib/modules/6.12.88+rpt-rpi-2712/build $ ln -s /tmp/t/lib/modules/6.18.29+rpt-rpi-2712 /tmp/t/lib/modules/6.18.29+rpt-rpi-2712/build $ mkdir /tmp/t/lib/modules/6.18.29+rpt-rpi-2712/build/dummy $ ( cd /tmp/t && for d in lib/modules/*/build; do [ -d "$d" ] || continue; echo "$(basename "$(dirname "$d")")"; done ) 6.18.29+rpt-rpi-2712 ``` Only the kernel whose headers actually resolve is selected — the dangling-symlink one is correctly skipped. ## Smoke plan (post-merge) 1. CI: arch-aarch64 / debian-aarch64 build (no behaviour change in build step, just postinst content; should green). 2. higgs: `apt install daedalus-v4l2-dkms` while booted on 6.12.88 with 6.18.29 headers also present → expect both `/lib/modules/6.12.88... /updates/dkms/daedalus_v4l2.ko.xz` and the same under 6.18.29. 3. Reboot into 6.18.29 → `/dev/daedalus-v4l2` appears, `daedalus-v4l2.service` not skipped.
claude-noether added 1 commit 2026-05-21 09:09:39 +00:00
Previously dkms autoinstall ran only against $(uname -r), so installing
the package on kernel A and rebooting into separately-installed kernel B
left /lib/modules/B/updates/dkms/ empty.  /dev/daedalus-v4l2 absent,
daedalus daemon nothing to talk to, browser/VAAPI silently falling back
to software with no obvious diagnostic for the user.

Now we enumerate every /lib/modules/*/build that resolves to a real
directory (i.e. headers are actually installed for that kernel) and run
'dkms autoinstall -k <kver>' for each.  Per-kernel verify; aggregated
warning only for the kernels that didn't build.

Tested locally: enumeration filters dangling /build symlinks correctly
(2 kernels installed, 1 has headers → only that one is built against).

Bumps PKGREL 1 → 2.  Closes #64.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
marfrit merged commit adcc824bf7 into main 2026-05-21 09:28:47 +00:00
marfrit deleted branch fix/daedalus-dkms-multi-kernel-64 2026-05-21 09:28:48 +00:00
Sign in to join this conversation.
No Reviewers
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: marfrit/marfrit-packages#65