marfrit/marfrit-packages
0
0
Fork 1
Code Issues 2 Pull Requests Actions Packages Projects Releases Wiki Activity

daedalus-v4l2-dkms: postinst builds only for running kernel; modules missing after kernel-switch reboot #64

New Issue
Closed
opened 2026-05-21 08:54:40 +00:00 by marfrit · 1 comment
marfrit commented 2026-05-21 08:54:40 +00:00
Owner
Copy Link
Copy Source

Symptom

On higgs (Pi CM5) the entire daedalus stack went silent after a reboot into a freshly installed kernel: /dev/daedalus-v4l2 absent, daedalus-v4l2.service skipped on ConditionPathExists=, libva fell back to a non-existent v3d driver and vaInitialize failed, Firefox/ffmpeg -hwaccel vaapi correctly fell back to SW. Diagnosis was time-consuming because everything looks installed (dpkg -l daedalus-v4l2-dkms reports ii) and the failure is silent.

Root cause

From /var/log/dpkg.log on higgs:

2026-05-19 00:02:57  configure linux-image-6.18.29+rpt-rpi-2712:arm64
2026-05-19 15:35:06  configure daedalus-v4l2-dkms:all 0.1.0+r16+gf55b2cd-2

The 6.18 kernel image was installed 13.5 hours BEFORE daedalus-v4l2-dkms was first installed. When the kernel image landed, /etc/kernel/postinst.d/dkms ran for whatever DKMS modules were already registered — daedalus wasn't one of them. Then daedalus-v4l2-dkms got installed while the system was still running 6.12.88. Its postinst (see debian/daedalus-v4l2-dkms/build-deb.sh lines 75–131) only does:

dkms add "$NAME/$VERSION" 2>/dev/null || true
dkms autoinstall "$NAME/$VERSION" || autoinstall_rc=$?

dkms autoinstall builds for the running kernel only. So the module was built for 6.12.88, and the same pattern repeated through every subsequent bump (r18, r20, r22, r24). The 6.18.29 kernel directory /lib/modules/6.18.29+rpt-rpi-2712/updates/dkms/ stayed empty for daedalus the whole time. On the first reboot into 6.18.29 (this morning), modprobe daedalus_v4l2 → Module ... not found. Daemon never starts.

Manually running sudo dkms add daedalus_v4l2/0.1.0+r24+gf0d4186 && sudo dkms autoinstall && sudo modprobe daedalus_v4l2 && sudo systemctl start daedalus-v4l2.service immediately recovered the stack — LIBVA_DRIVER_NAME=v4l2_request vainfo then surfaces H264 Main/High/CB, HEVC Main, VP9 Profile 0, AV1 Profile 0 cleanly.

Why the existing safety net misses it

The postinst has a verification block that warns if dkms status doesn't show installed|loaded for $KERNELVER=$(uname -r). On the install host that check passed (the build succeeded for the running 6.12 kernel) — so no warning fired. The check has no notion of "other installed kernels also need this module".

The dkms add line silences stderr via 2>/dev/null || true, which is independently risky (would also mask a genuine add failure), but isn't the proximate cause here.

Proposed fix (smallest)

Change the postinst to autoinstall across every kernel that has headers on disk, not just the running one:

built_any=0
for kver in $(ls /lib/modules/ 2>/dev/null); do
    [ -d "/lib/modules/$kver/build" ] || continue
    if dkms autoinstall -k "$kver" 2>&1; then
        built_any=1
    fi
done

Matches the standard pattern used by dh_dkms-generated packages.

Proposed fix (cleaner, follow-up)

Migrate debian/daedalus-v4l2-dkms/ to dh-dkms debhelper (Debian's endorsed convention). It handles the multi-kernel case, plus registers a dpkg trigger on /lib/modules/* so newly installed kernels automatically rebuild. The current bespoke build-deb.sh could keep building the .deb the same way and just emit the dh-dkms-style postinst/prerm hooks instead of the hand-rolled ones.

Sibling package

The Arch arch/daedalus-v4l2-dkms PKGBUILD likely has the same gap. Should audit.

Repro environment

  • Host: higgs (Pi CM5)
  • OS: Raspberry Pi OS (trixie userland)
  • Kernels installed: 6.12.75+rpt-rpi-2712, 6.12.88+deb13-arm64, 6.18.29+rpt-rpi-2712
  • Headers installed for all three
  • daedalus-v4l2-dkms versions seen on host (per dpkg log): r16+gf55b2cd, r18+g481279c, r20+g3dd0eb0, r22+g462aa4b, r24+gf0d4186
  • Triggering reboot was the first boot into 6.18.29

Severity

Medium — silent failure mode that costs hours to diagnose and looks like a Firefox/libva bug. Bites every time the running kernel switches without a fresh dpkg-reconfigure. Workaround documented above.

## Symptom On higgs (Pi CM5) the entire daedalus stack went silent after a reboot into a freshly installed kernel: `/dev/daedalus-v4l2` absent, `daedalus-v4l2.service` skipped on `ConditionPathExists=`, libva fell back to a non-existent v3d driver and `vaInitialize` failed, Firefox/`ffmpeg -hwaccel vaapi` correctly fell back to SW. Diagnosis was time-consuming because everything looks installed (`dpkg -l daedalus-v4l2-dkms` reports `ii`) and the failure is silent. ## Root cause From `/var/log/dpkg.log` on higgs: ``` 2026-05-19 00:02:57 configure linux-image-6.18.29+rpt-rpi-2712:arm64 2026-05-19 15:35:06 configure daedalus-v4l2-dkms:all 0.1.0+r16+gf55b2cd-2 ``` The 6.18 kernel image was installed 13.5 hours BEFORE `daedalus-v4l2-dkms` was first installed. When the kernel image landed, `/etc/kernel/postinst.d/dkms` ran for whatever DKMS modules were already registered — daedalus wasn't one of them. Then `daedalus-v4l2-dkms` got installed while the system was still running 6.12.88. Its postinst (see `debian/daedalus-v4l2-dkms/build-deb.sh` lines 75–131) only does: ```sh dkms add "$NAME/$VERSION" 2>/dev/null || true dkms autoinstall "$NAME/$VERSION" || autoinstall_rc=$? ``` `dkms autoinstall` builds for the **running** kernel only. So the module was built for 6.12.88, and the same pattern repeated through every subsequent bump (r18, r20, r22, r24). The 6.18.29 kernel directory `/lib/modules/6.18.29+rpt-rpi-2712/updates/dkms/` stayed empty for daedalus the whole time. On the first reboot into 6.18.29 (this morning), `modprobe daedalus_v4l2` → `Module ... not found`. Daemon never starts. Manually running `sudo dkms add daedalus_v4l2/0.1.0+r24+gf0d4186 && sudo dkms autoinstall && sudo modprobe daedalus_v4l2 && sudo systemctl start daedalus-v4l2.service` immediately recovered the stack — `LIBVA_DRIVER_NAME=v4l2_request vainfo` then surfaces H264 Main/High/CB, HEVC Main, VP9 Profile 0, AV1 Profile 0 cleanly. ## Why the existing safety net misses it The postinst has a verification block that warns if `dkms status` doesn't show `installed|loaded` for `$KERNELVER=$(uname -r)`. On the install host that check passed (the build succeeded for the running 6.12 kernel) — so no warning fired. The check has no notion of "other installed kernels also need this module". The `dkms add` line silences stderr via `2>/dev/null || true`, which is independently risky (would also mask a genuine add failure), but isn't the proximate cause here. ## Proposed fix (smallest) Change the postinst to autoinstall across every kernel that has headers on disk, not just the running one: ```sh built_any=0 for kver in $(ls /lib/modules/ 2>/dev/null); do [ -d "/lib/modules/$kver/build" ] || continue if dkms autoinstall -k "$kver" 2>&1; then built_any=1 fi done ``` Matches the standard pattern used by `dh_dkms`-generated packages. ## Proposed fix (cleaner, follow-up) Migrate `debian/daedalus-v4l2-dkms/` to `dh-dkms` debhelper (Debian's endorsed convention). It handles the multi-kernel case, plus registers a dpkg trigger on `/lib/modules/*` so newly installed kernels automatically rebuild. The current bespoke `build-deb.sh` could keep building the .deb the same way and just emit the dh-dkms-style postinst/prerm hooks instead of the hand-rolled ones. ## Sibling package The Arch `arch/daedalus-v4l2-dkms` PKGBUILD likely has the same gap. Should audit. ## Repro environment - Host: higgs (Pi CM5) - OS: Raspberry Pi OS (trixie userland) - Kernels installed: `6.12.75+rpt-rpi-2712`, `6.12.88+deb13-arm64`, `6.18.29+rpt-rpi-2712` - Headers installed for all three - `daedalus-v4l2-dkms` versions seen on host (per dpkg log): r16+gf55b2cd, r18+g481279c, r20+g3dd0eb0, r22+g462aa4b, r24+gf0d4186 - Triggering reboot was the first boot into 6.18.29 ## Severity Medium — silent failure mode that costs hours to diagnose and looks like a Firefox/libva bug. Bites every time the running kernel switches without a fresh `dpkg-reconfigure`. Workaround documented above.
claude-noether commented 2026-05-21 09:31:38 +00:00
Contributor
Copy Link
Copy Source

Fixed via #65 (merged) and validated on higgs.

$ sudo dkms status -m daedalus_v4l2
daedalus_v4l2/0.1.0+r24+gf0d4186, 6.12.75+rpt-rpi-2712, aarch64: installed
daedalus_v4l2/0.1.0+r24+gf0d4186, 6.12.75+rpt-rpi-v8,   aarch64: installed
daedalus_v4l2/0.1.0+r24+gf0d4186, 6.12.88+deb13-arm64,  aarch64: installed
daedalus_v4l2/0.1.0+r24+gf0d4186, 6.18.29+rpt-rpi-2712, aarch64: installed
daedalus_v4l2/0.1.0+r24+gf0d4186, 6.18.29+rpt-rpi-v8,   aarch64: installed

Before the upgrade: 1 kernel covered (the running one only). After: every kernel on higgs whose headers are installed has /lib/modules/<kver>/updates/dkms/daedalus_v4l2.ko.xz populated. Running module loaded and /dev/daedalus-v4l2 present as expected.

The dh-dkms migration (proposed as the long-term option) is intentionally not in this PR — would restructure the build from dpkg-deb-by-hand to debhelper-driven dpkg-source. Worth doing separately if/when we hit the next case the minimal fix doesn't catch (e.g. headers installed after the package via a later apt install).

Fixed via #65 (merged) and validated on higgs. ``` $ sudo dkms status -m daedalus_v4l2 daedalus_v4l2/0.1.0+r24+gf0d4186, 6.12.75+rpt-rpi-2712, aarch64: installed daedalus_v4l2/0.1.0+r24+gf0d4186, 6.12.75+rpt-rpi-v8, aarch64: installed daedalus_v4l2/0.1.0+r24+gf0d4186, 6.12.88+deb13-arm64, aarch64: installed daedalus_v4l2/0.1.0+r24+gf0d4186, 6.18.29+rpt-rpi-2712, aarch64: installed daedalus_v4l2/0.1.0+r24+gf0d4186, 6.18.29+rpt-rpi-v8, aarch64: installed ``` Before the upgrade: 1 kernel covered (the running one only). After: every kernel on higgs whose headers are installed has `/lib/modules/<kver>/updates/dkms/daedalus_v4l2.ko.xz` populated. Running module loaded and `/dev/daedalus-v4l2` present as expected. The `dh-dkms` migration (proposed as the long-term option) is intentionally not in this PR — would restructure the build from `dpkg-deb`-by-hand to debhelper-driven `dpkg-source`. Worth doing separately if/when we hit the next case the minimal fix doesn't catch (e.g. headers installed *after* the package via a later `apt install`).
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
marfrit (Markus Fritsche)
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: marfrit/marfrit-packages#64
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?