Kernel header installation fails for incompatible DKMS modules
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
dkms (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Jammy |
Confirmed
|
Undecided
|
Unassigned | ||
Lunar |
Fix Released
|
Undecided
|
Unassigned | ||
Mantic |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[ Impact ]
If a new kernel is installed, all installed DKMS modules are built for that new kernel. There might be incompatible modules that won't compile for the new kernel which results in a kernel header package installation failure. That's bad and not really correct, the incompatible DKMS module is the problem and not the new kernel.
In this case, DKMS module build failures should be ignored so that the kernel installation completes.
This is especially acute during release-upgrades, as dkms modules are upgraded out of order, and major kernel version are upgraded out of order. Majority of the time there is a new dkms available, which should attempt build & load.
However, many modules are often remain broken, no longer needed, or need user to fetch updated versions themselves.
[ Test Plan ]
* Install jammy
* Add module that support v5.15 kernel, but fails to compile with any newer kernels (one can find examples of such dkms modules in the archive, or out of the archive)
* Perform release upgrade with patched dkms pre-installed
* Release upgrade should succeed, despite unable to compile all dkms modules
[ Where problems could occur ]
* This is an improvement to the current situation of aborting release upgrade half way through. It doesn't quite resolve the UX to notify the user which dkms modules did not manage to compile, or to ask user to uninstall or to update them. Further UX / hooks might be needed in the release upgrade to complete the story of asking the user what they want to do with regressed dkms modules.
[ Other Info ]
* See lots and lots of upgrade bugs, failing on dkms module installation
summary: |
- kernel header installation fails for incompatible DKMS modules + Kernel header installation fails for incompatible DKMS modules |
tags: | added: patch |
Changed in dkms (Ubuntu): | |
status: | New → Triaged |
Changed in dkms (Ubuntu Lunar): | |
status: | New → In Progress |
Changed in dkms (Ubuntu Mantic): | |
status: | Triaged → Fix Committed |
description: | updated |
Changed in dkms (Ubuntu Jammy): | |
status: | New → Confirmed |
With the above patch, a dist upgrade with a problematic DKMS module and /etc/dkms/ no-autoinstall- errors present looks like:
Setting up linux-headers- 6.2.0-25- generic (6.2.0-25.25) ... header_ postinst. d/dkms: shim-signed/ mok/MOK. priv shim-signed/ mok/MOK. der
/etc/kernel/
* dkms: running auto installation service for kernel 6.2.0-25-generic
Sign command: /usr/bin/kmodsign
Signing key: /var/lib/
Public certificate (MOK): /var/lib/
Building module: 6.2.0-25- generic -C /lib/modules/ 6.2.0-25- generic/ build M=/var/ lib/dkms/ evdi/1. 12.0+dfsg/ build DKMS_BUILD=1...(bad exit status: 2) dkms/evdi/ 1.12.0+ dfsg/build/ make.log for more information. generic/ x86_64 failed for evdi(10)
Cleaning build area...
make -j1 KERNELRELEASE=
ERROR (dkms apport): binary package for evdi: 1.12.0+dfsg not found
Error! Bad return status for module build on kernel: 6.2.0-25-generic (x86_64)
Consult /var/lib/
dkms autoinstall on 6.2.0-25-
Error! One or more modules failed to install during autoinstall.
Refer to previous errors for more information.
* dkms: ignore autoinstall errors for dkms modules
* dkms: autoinstall for kernel 6.2.0-25-generic
...done.