Third-party HBA module refuses to load after kernel update
A Debian 12 server provides iSCSI storage to 40 hosts. An administrator installed the vendor's out-of-tree storage HBA module mynic via DKMS, then applied a routine kernel update from 6.1.0-18-amd64 to 6.1.0-21-amd64. Secure Boot is enabled. The server boots, but the HBA is not detected and iSCSI sessions do not recover. modprobe mynic fails; dmesg reports 'module verification failed: signature and/or required key missing' and later 'Unknown symbol'. dkms status lists mynic/2.4.1 for 6.1.0-18 only. Booting the old kernel from the GRUB menu restores the HBA. The vendor supplies source code and a detached signature for its own kernel builds, but not for Debian's. The server is remote; console access requires a support ticket with a 30-minute delay. The team must restore storage and prevent recurrence at the next update.
1. Triage: confirm the failure mode and decide whether the problem is Secure Boot, DKMS, or a kernel API change. What evidence would distinguish them?
Read the worked answer
Collect uname -r, mokutil --sb-state, dkms status, modinfo mynic, modprobe -v mynic, dmesg | tail -50, and the DKMS make.log under /var/lib/dkms/mynic/2.4.1/build. The signature message proves Secure Boot rejected an unsigned module. Unknown symbol can appear after that because the module did not load, or because it was built against a different kernel API. Check modinfo -F vermagic mynic.ko and compare it with uname -r. DKMS status showing only 6.1.0-18 means the module was not rebuilt for 6.1.0-21. So there are two independent issues: missing DKMS build for the running kernel and missing signature. A successful build for the old kernel does not prove the new kernel is supported; the make.log will show API errors. Booting the old kernel isolates kernel version from hardware failure. If the HBA is absent in lspci, it is a module or kernel problem, not cabling.
2. Recommend a remediation path for tonight given the remote console delay. Compare booting the old kernel, disabling Secure Boot, and enrolling a MOK.
Read the worked answer
Tonight, use a one-time GRUB boot into 6.1.0-18 to restore storage, because the old kernel is known good and the remote console has a 30-minute delay. On Debian, set the next boot entry with grub-reboot, verify with grub-editenv list, then reboot. Do not disable Secure Boot as a production fix; that weakens the boot chain and may violate policy. Enrolling a MOK is the correct long-term route: build the module for 6.1.0-21 with dkms install -m mynic -v 2.4.1 -k 6.1.0-21-amd64, sign it with the MOK key, run mokutil --import, and complete enrollment at the console. Because console access is delayed, schedule a maintenance window rather than risking a boot that needs physical approval. A vendor-signed module for Debian's kernel is preferable if available. Keep 6.1.0-18 installed until the new kernel has been tested with the HBA and iSCSI sessions.
3. What persistent configuration prevents silent breakage at future kernel updates?
Read the worked answer
Make DKMS part of the kernel postinst path, verify dkms autoinstall runs for each new kernel, and add a pre-reboot check that modinfo -k <newver> mynic resolves and that the module signature is accepted. Do not rely on apt-mark hold as the only control; it delays security updates. Keep at least one previous kernel and a tested GRUB fallback. Monitor dkms status and the HBA's iSCSI sessions after every update. Stage kernel updates on a non-production host with Secure Boot enabled, because a build success without a signature still fails at boot. Document the MOK enrollment procedure and who can complete it. If the vendor cannot support new kernels promptly, move the HBA to a vendor-supported distribution or to hardware with in-tree drivers. Record the module version and kernel ABI in the change ticket so rollback is unambiguous.