Release upgrade fails due to unsupported DKMS modules
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
ubuntu-release-upgrader (Ubuntu) |
Triaged
|
Medium
|
Unassigned | ||
Lunar |
Won't Fix
|
Medium
|
Unassigned |
Bug Description
The kernel team takes care that any DKMS package supported by the new release actually compiles and works with the new kernel. We also make sure that DKMS packages that are obsoleted in the new release are updated in the current release such that they are ignored on upgrade.
However users can have old and/or unsupported DKMS packages installed from different sources, not just the Ubuntu archive, which can be problematic. If kernel header packages are installed, the dkms post-install hook tries to compile all installed and enabled DKMS modules. On upgrade, header packages for the new kernel are installed and the dkms hook is invoked. If any of the installed and enabled DKMS modules fails to build for the new kernel, the header package installation fails and ultimately the whole release upgrade fails.
To get around this problem, we propose to disable all DKMS modules before attempting the upgrade and re-enable them one by one afterwards and notify the user if any of them failed to build. Care must be taken that when disabling the DKMS modules, the initrds are *not* rebuilt (otherwise the disabled DKMS modules might be removed from the initrds) so that the user can fall back to a previous kernel/initrd should the new kernel not work for them.
ATM, there are 46 bugs logged for the 'linux' package because of DKMS build failures on upgrade to Lunar: https:/
Related branches
- Nick Rosbrook: Disapprove
- Juerg Haefliger (community): Needs Information
- Brian Murray: Pending requested
-
Diff: 136 lines (+103/-0)2 files modifiedDistUpgrade/DistUpgradeQuirks.py (+97/-0)
debian/changelog (+6/-0)
Changed in ubuntu-release-upgrader (Ubuntu): | |
status: | Confirmed → Triaged |
assignee: | nobody → Nick Rosbrook (enr0n) |
importance: | Undecided → Medium |
Changed in ubuntu-release-upgrader (Ubuntu Lunar): | |
status: | New → Triaged |
importance: | Undecided → Medium |
assignee: | nobody → Nick Rosbrook (enr0n) |
tags: | removed: foundations-todo |
Changed in ubuntu-release-upgrader (Ubuntu): | |
assignee: | Nick Rosbrook (enr0n) → nobody |
Changed in ubuntu-release-upgrader (Ubuntu Lunar): | |
assignee: | Nick Rosbrook (enr0n) → nobody |
The proposal is similar to how we deal with PPAs on upgrades. At the upgrade start we disable PPAs, tell user we do this, and then do not re-enable them after the install is completed.
We should do the same with dkms: disable dkms autoinstall, and at the end of the upgrade re-enable autoinstall without attempting to configure/ build/enable any dkms packages.
In practical terms it means, at the start of the upgrade we should `touch /etc/dkms/ no-autoinstall` and at the end of the upgrade `rm -f /etc/dkms/ no-autoinstall` .