Kernel header installation fails for incompatible DKMS modules

[Juerg Haefliger]

[ 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

[Juerg Haefliger (juergh)]

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) ...
/etc/kernel/header_postinst.d/dkms:
 * dkms: running auto installation service for kernel 6.2.0-25-generic
Sign command: /usr/bin/kmodsign
Signing key: /var/lib/shim-signed/mok/MOK.priv
Public certificate (MOK): /var/lib/shim-signed/mok/MOK.der

Building module:
Cleaning build area...
make -j1 KERNELRELEASE=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)
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/evdi/1.12.0+dfsg/build/make.log for more information.
dkms autoinstall on 6.2.0-25-generic/x86_64 failed for evdi(10)
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.

[Juerg Haefliger (juergh)]

Note the following line in the above log:

  * dkms: ignore autoinstall errors for dkms modules

[Dimitri John Ledkov (xnox)]

I like this stamp file, but I'm not too sure who will create it and remove it and when.

Note that separately, ubuntu-release-upgrader https://git.launchpad.net/ubuntu-release-upgrader/tree/DistUpgrade/README#n13 will set environment variables:

The following environment variable will be *set* by the upgrader:
RELEASE_UPGRADE_IN_PROGRESS:
- set to "1" if a release-upgrade is running (and not a normal
  package/security upgrade)

Can we also please add code to use the "no-autoinstall-errors" mode, whenever RELEASE_UPGRADE_IN_PROGRESS = 1 ?

[Juerg Haefliger (juergh)]

Updated debdiff that also honors RELEASE_UPGRADE_IN_PROGRESS. Tested an upgrade from K to L with this package installed and a rogue DKMS that won't compile for 6.2. Errors are ignored and the upgraded completes.

[Dimitri John Ledkov (xnox)]

This looks good, trying to see how i can make current ubuntu8 dkms migrate, before uploading this one.

[Juerg Haefliger (juergh)]

Should we put this into lunar as well? I'm still seeing occasional bug reports because of this issue.

[Juerg Haefliger (juergh)]

debdiff for Lunar

[Dimitri John Ledkov (xnox)]

Uploaded to mantic and lunar, fixed lunar version number to be ubuntu2.1 (sru style version)

[Launchpad Janitor (janitor)]

This bug was fixed in the package dkms - 3.0.11-1ubuntu9

---------------
dkms (3.0.11-1ubuntu9) mantic; urgency=medium

  * Unsupported DKMS modules break kernel header installation if compilation
    fails. Handle this by ignoring autoinstall errors if a release upgrade is
    in progress or if the file /etc/dkms/no-autoinstall-errors exists
    (LP: #2028366).

 -- Juerg Haefliger <email address hidden> Tue, 25 Jul 2023 16:29:26 +0200

[Timo Aaltonen (tjaalton)]

Hello Juerg, or anyone else affected,

Accepted dkms into lunar-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/dkms/3.0.10-7ubuntu2.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-lunar to verification-done-lunar. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-lunar. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted dkms (3.0.10-7ubuntu2.1) for lunar have finished running.
The following regressions have been reported in tests triggered by the package:

dahdi-linux/1:2.11.1.0.20170917~dfsg-8.4ubuntu1 (amd64)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/lunar/update_excuses.html#dkms

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Juerg Haefliger (juergh)]

Tested DKMS from proposed

Testbed preparation:

1) Install Lunar

2) Install a good and a bad DKMS (one that builds correctly and one that doesn't):
   2.1) Install evdi-dkms (good DKMS)
   2.2) Install rtl8821ce-dkms 5.5.2.1-0ubuntu10 from Jammy (bad DKMS)

3) Verify DKMS build status:
   $ dkms status
   evdi/1.12.0+dfsg, 6.2.0-27-generic, x86_64: installed
   rtl8821ce/5.5.2.1: added

During the above, the build of rtl8821ce failed.

Verify current brokenness:

1) Unbuild evdi dkms:
   $ sudo dkms unbuild evdi/1.12.0+dfsg --all
   $ dmks status
   evdi/1.12.0+dfsg: added
   rtl8821ce/5.5.2.1: added

2) Reinstall the kernel headers, this triggers a build of all DKMS modules. One of the modules fails to build and the kernel header installation fails as a result of that.
  $ sudo apt install --reinstall linux-headers-6.2.0-27-generic
...
Setting up linux-headers-6.2.0-27-generic (6.2.0-27.28) ...
/etc/kernel/header_postinst.d/dkms:
 * dkms: running auto installation service for kernel 6.2.0-27-generic
...
Error! Bad return status for module build on kernel: 6.2.0-27-generic (x86_64)
Consult /var/lib/dkms/rtl8821ce/5.5.2.1/build/make.log for more information.
...
Errors were encountered while processing:
 linux-headers-6.2.0-27-generic
 rtl8821ce-dkms
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)

OK, confirmed that header installation with a broken DKMS is place fails.

Clean up the testbed and install dkms from proposed:

1) Remove rtl8821ce-dkms
2) Reinstall kernel headers
3) Install dkms 3.0.10-7ubuntu2.1 from proposed
4) Reinstall rtl8821ce-dkms 5.5.2.1-0ubuntu10 from Jammy. Build still fails.
5) Unbuild evdi dkms:
   $ sudo dkms unbuild evdi/1.12.0+dfsg --all
   $ dmks status
   evdi/1.12.0+dfsg: added
   rtl8821ce/5.5.2.1: added

Verify correct behavior of dkms from proposed:

1) Reinstall kernel headers (mimick do-release-upgrade):
   $ RELEASE_UPGRADE_IN_PROGRESS=1 apt install --reinstall linux-headers-6.2.0-27-generic
...
etting up linux-headers-6.2.0-27-generic (6.2.0-27.28) ...
/etc/kernel/header_postinst.d/dkms:
 * dkms: running auto installation service for kernel 6.2.0-27-generic
...
Error! Bad return status for module build on kernel: 6.2.0-27-generic (x86_64)
Consult /var/lib/dkms/rtl8821ce/5.5.2.1/build/make.log for more information.
dkms autoinstall on 6.2.0-27-generic/x86_64 succeeded for evdi
dkms autoinstall on 6.2.0-27-generic/x86_64 failed for rtl8821ce(10)
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-27-generic
   ...done.
...
   $ echo $?
   0

See above output. Build of rtl8821ce/5.5.2.1 failed but error is ignored and kernel headers are installed successfully.

[Afred Factice (afredfactice)]

Hi

with the kernel 6.2.0-27 i have a kernel panic when i start the
computer, because there upgrade doesn't work.

I could start the same computer with 6.2.0-26 in grub.

Yesterday ubuntu asked to upgraded to 6.2.0-31. I replied yes. It's work.

( uname -a :

Linux jeanpaul-Precision-WorkStation-T5500 6.2.0-31-generic #31-Ubuntu
SMP PREEMPT_DYNAMIC Mon Aug 14 13:42:26 UTC 2023 x86_64 x86_64 x86_64
GNU/Linux
)

Now i can start the computer without a kernel pannic with the computer
start.

I tryed before the update yesterday the following command. It did not work.

Sincerly yours

Le 28/08/2023 à 11:33, Juerg Haefliger a écrit :
> Tested DKMS from proposed
>
> Testbed preparation:
>
> 1) Install Lunar
>
> 2) Install a good and a bad DKMS (one that builds correctly and one that doesn't):
> 2.1) Install evdi-dkms (good DKMS)
> 2.2) Install rtl8821ce-dkms 5.5.2.1-0ubuntu10 from Jammy (bad DKMS)
>
> 3) Verify DKMS build status:
> $ dkms status
> evdi/1.12.0+dfsg, 6.2.0-27-generic, x86_64: installed
> rtl8821ce/5.5.2.1: added
>
> During the above, the build of rtl8821ce failed.
>
> Verify current brokenness:
>
> 1) Unbuild evdi dkms:
> $ sudo dkms unbuild evdi/1.12.0+dfsg --all
> $ dmks status
> evdi/1.12.0+dfsg: added
> rtl8821ce/5.5.2.1: added
>
> 2) Reinstall the kernel headers, this triggers a build of all DKMS modules. One of the modules fails to build and the kernel header installation fails as a result of that.
> $ sudo apt install --reinstall linux-headers-6.2.0-27-generic
> ...
> Setting up linux-headers-6.2.0-27-generic (6.2.0-27.28) ...
> /etc/kernel/header_postinst.d/dkms:
> * dkms: running auto installation service for kernel 6.2.0-27-generic
> ...
> Error! Bad return status for module build on kernel: 6.2.0-27-generic (x86_64)
> Consult /var/lib/dkms/rtl8821ce/5.5.2.1/build/make.log for more information.
> ...
> Errors were encountered while processing:
> linux-headers-6.2.0-27-generic
> rtl8821ce-dkms
> needrestart is being skipped since dpkg has failed
> E: Sub-process /usr/bin/dpkg returned an error code (1)
>
> OK, confirmed that header installation with a broken DKMS is place
> fails.
>
> Clean up the testbed and install dkms from proposed:
>
> 1) Remove rtl8821ce-dkms
> 2) Reinstall kernel headers
> 3) Install dkms 3.0.10-7ubuntu2.1 from proposed
> 4) Reinstall rtl8821ce-dkms 5.5.2.1-0ubuntu10 from Jammy. Build still fails.
> 5) Unbuild evdi dkms:
> $ sudo dkms unbuild evdi/1.12.0+dfsg --all
> $ dmks status
> evdi/1.12.0+dfsg: added
> rtl8821ce/5.5.2.1: added
>
>
> Verify correct behavior of dkms from proposed:
>
> 1) Reinstall kernel headers (mimick do-release-upgrade):
> $ RELEASE_UPGRADE_IN_PROGRESS=1 apt install --reinstall linux-headers-6.2.0-27-generic
> ...
> etting up linux-headers-6.2.0-27-generic (6.2.0-27.28) ...
> /etc/kernel/header_postinst.d/dkms:
> * dkms: running auto installation service for kernel 6.2.0-27-generic
> ...
> Error! Bad return status for module build on kernel: 6.2.0-27-generic (x86_64)
> Consult /var/lib/dkms/rtl8821ce/5.5.2.1/build/make.log for more information.
> dkms autoinstall on 6.2.0-27-generic/x86_64 succeeded for evdi
>...

[Robie Basak (racb)]

@afredfactice it sounds like your issue is not related to this bug. If you think it is related, please could you explain why? Otherwise, please see https://ubuntu.com/community/support for community support options.

[Robie Basak (racb)]

> This is an improvement to the current situation of aborting release upgrade half way through.

Is it? If the user ends up with a broken DKMS package on release upgrade, then at least they'll know about it. But if we silently ignore the failure, the release upgrade will finish pretending that it was successful when it was not, and then what if they find the system broken later?

> 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.

I agree that this is appropriate to fix in SRUs, but can we fix the entire story rather than iterating in the stable release?

I prefer not to move the goalposts but I think the above is a big enough concern to be worth considering first.

[Dimitri John Ledkov (xnox)]

On Wed, 30 Aug 2023, 13:57 Robie Basak, <email address hidden> wrote:

> > This is an improvement to the current situation of aborting release
> upgrade half way through.
>
> Is it? If the user ends up with a broken DKMS package on release
> upgrade, then at least they'll know about it. But if we silently ignore
> the failure, the release upgrade will finish pretending that it was
> successful when it was not, and then what if they find the system broken
> later?
>

This matches the behaviour we do with all the packages installed from
3rd-party PPAs. I.e. disable the PPAs, and remove packages installed from
there if they are no longer installable.

This implementation for dkms is equivalent to the above.

Note that the current failure mode is - aborted dist-upgrade half way
through the dist-install. No rollback is performed, and it is extremely
difficult to recover from requiring multiple by hand calls to "apt install
--fix-broken" and manual resolutions.

On contrast, resolving missing dkms is trivial, as dkms status will show
that they are only available for the old kernel, and user then can go and
update git pull of local got repos, or 3rd party ppa's, to get the updated
modules if they exist.

> > 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.
>
> I agree that this is appropriate to fix in SRUs, but can we fix the
> entire story rather than iterating in the stable release?
>

No, not yet as it will require a lot of UX development.

Not leaving people half way through the upgrade with unconfigured, unpacked
and partially configured packages is at upmost priority. As that is a
catastrophic state to leave users at.

Also note that future UX will be done outside of the dkms package. As it
would be for e.g. ubuntu-release-uograder to capture dkms status before and
after release upgrade to figure out how to aks user to fix modules, if
there is any discrepancy between old and new state.

> I prefer not to move the goalposts but I think the above is a big enough
> concern to be worth considering first.
>

Priority of this upload is to prevent users being left in a catastrophic
state that is not recoverable. Whilst attempting to still compile dkms
modules on best effort basis - just like what we do with packages installed
from 3rd party PPAs. This is the goal post.

> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/2028366
>
> Title:
> Kernel header installation fails for incompatible DKMS modules
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/dkms/+bug/2028366/+subscriptions
>
> Launchpad-Notification-Type: bug
> Launchpad-Bug: distribution=ubuntu; sourcepackage=dkms; component=main;
> status=Fix Released; importance=Undecided; assignee=None;
> Launchpad-Bug: distribution=ubuntu; distroseries=jammy;
> sourcepackage=dkms; component=main; status=Confirmed; importance=Undecided;
> assignee=None;
> Launchpad-Bug: distribution=ubuntu; distroseries=lunar;
> sourcepackage=dkms; component=main; status=Fix Committed;
...

[Juerg Haefliger (juergh)]

In the current situation, the user is not left with a broken DKMS package but a broken system because the kernel upgrade failed. This is really really bad. Not only is the kernel wrongly blamed when in fact it's a dkms issue but the system is in an utterly bad state and requires serious apt foo to recover. How can this be better than a fully upgraded system with a DKMS package that is not built for the current kernel?

We had ~50 reports (all dups of this bug) when people upgraded to Lunar. Most of the problematic DKMS are evdi, parallels-tools and realtek ethernet. Nothing boot essential.

[Andreas Hasenack (ahasenack)]

I suppose it's possible that the particular dkms module that failed to build is essential for booting the system, so the new approach that hides this build failure could render the system unbootable without the user realizing it. A bit less catastrophic, but still very serious, would be for the machine to lose network access (wifi driver), which could pose a chicken an egg problem (need network to fix the problem).

So what we have here is a balance between a system with an interrupted release-upgrade, requiring a lot of apt-foo to fix, or a system where dkms rebuilds might have failed, but otherwise upgraded successfully. Both cases could result in an unbootable system, but I tend to agree that the first one (interrupted release-upgrade) is more likely to be much harder to recover (been there).

I would like some sort of commitment on the follow-up work for the release upgrader to check the status of dkms builds after the upgrade. Can we get an LP bug for it please?

[Launchpad Janitor (janitor)]

This bug was fixed in the package dkms - 3.0.10-7ubuntu2.1

---------------
dkms (3.0.10-7ubuntu2.1) lunar; urgency=medium

  * Unsupported DKMS modules break kernel header installation if compilation
    fails. Handle this by ignoring autoinstall errors if a release upgrade is
    in progress or if the file /etc/dkms/no-autoinstall-errors exists
    (LP: #2028366).

 -- Juerg Haefliger <email address hidden> Tue, 25 Jul 2023 16:29:26 +0200

[Andreas Hasenack (ahasenack)]

The verification of the Stable Release Update for dkms has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Nicolas L'huillier (nicolaslh31)]

Hi Andreas,

Anbox dkms module is incomptible with kernel 6.2.0-27-generic.

Solution applied:

1- Anbox removed

2- Command applied:
$ dkms remove anbox-ashmem/1 --all
$ dkms remove anbox-binder/1 --all

System is now ok.

apt update : ok without error

apt upgrade : ok without error

Restart ok with the last kernel (6.2.0-31-generic) installed by the last update.

Thanks a lot for your help.

[https://d36urhup7zbd7q.cloudfront.net/a/5bfbaff9-9d34-4d3d-832c-070e4a3ea4f8.png#logo]
Nicolas L'huillier
Brasserie La Cavalière Occitane

0608889301 <tel:[phone]> | <http://www.brasserielacavalièreoccitane.fr> www.brasserielacavaliereoccitane.fr<http://www.brasserielacavaliereoccitane.fr>

<mailto:contact@brasserielacavalièreoccitane.fr><email address hidden><mailto:<email address hidden>><mailto:contact@brasserielacavalièreoccitane.fr>

311 route de devant la Save 31230 Anan<https://www.google.fr/maps/place/Brasserie+La+Cavali%C3%A8re+Occitane/@43.3542943,0.821968,17z/data=!3m1!4b1!4m6!3m5!1s0x12a91168d8f11c93:0x341191ec8c4e5c2f!8m2!3d43.3542904!4d0.8245429!16s%2Fg%2F11rsg5ys2b> <https://maps.google.com/?q=311%20route%20de%20devant%20la%20Save%2031230%20Anan>

Ouverture brasserie : sur rendez-vous

________________________________
De : <email address hidden> <email address hidden> de la part de Andreas Hasenack <email address hidden>
Envoyé : jeudi 31 août 2023 15:11:12
À : Brasserie La Cavalière Occitane
Objet : [Bug 2028366] Re: Kernel header installation fails for incompatible DKMS modules

I suppose it's possible that the particular dkms module that failed to
build is essential for booting the system, so the new approach that
hides this build failure could render the system unbootable without the
user realizing it. A bit less catastrophic, but still very serious,
would be for the machine to lose network access (wifi driver), which
could pose a chicken an egg problem (need network to fix the problem).

So what we have here is a balance between a system with an interrupted
release-upgrade, requiring a lot of apt-foo to fix, or a system where
dkms rebuilds might have failed, but otherwise upgraded successfully.
Both cases could result in an unbootable system, but I tend to agree
that the first one (interrupted release-upgrade) is more likely to be
much harder to recover (been there).

I would like some sort of commitment on the follow-up work for the
release upgrader to check the status of dkms builds after the upgrade.
Can we get an LP bug for it please?

--
You received this bug notification because you are subscribed to a
duplicate bug report (2033408).
https://bugs.launchpad.net/bugs/2028366

Title:
  Kernel header installation fails for incompatible DKMS modules

Status in dkms package in Ubuntu:
  Fix Released
Status in dkms source package in Jammy:
  Confirmed
Status in dkms source package in Lunar:
  Fix Released
Status in dkms source package in Mantic:
  Fix Released

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 k...

[Juerg Haefliger (juergh)]

> I suppose it's possible that the particular dkms module that failed to build is essential for booting the
> system, so the new approach that hides this build failure could render the system unbootable without the
> user realizing it.

We still have the old kernel with the built DKMS around, so the system is not unbootable. Just the default kernel might be.

> I would like some sort of commitment on the follow-up work for the release upgrader to check the status
> of dkms builds after the upgrade. Can we get an LP bug for it please?

We can use bug 2020406 for that.

[Dimitri John Ledkov (xnox)]

On Thu, 31 Aug 2023 at 14:22, Andreas Hasenack
<email address hidden> wrote:
>
> I suppose it's possible that the particular dkms module that failed to
> build is essential for booting the system, so the new approach that
> hides this build failure could render the system unbootable without the
> user realizing it. A bit less catastrophic, but still very serious,
> would be for the machine to lose network access (wifi driver), which
> could pose a chicken an egg problem (need network to fix the problem).

I'm not sure that is possible. Because it means it was not possible to
boot the installer, or install the system. Because for example when
one assumes secureboot by default it is not possible to enroll a Mok
key without a reboot, and meaning having a successful install that at
least can boot (but might not have a weird wifi).

We haven't yet had any cases of drivers being dropped by a kernel,
that transition to be a 3rd party dkms. Or ability to complete install
with dkms module that is essential for boot (i.e. disk driver for disk
install, or network driver for network boot install).

To the point of, I am happy to assert that if dkms is required for
boot, the image for such a system was pre-built externally. And in
such cases, it should be possible to pre-built again.

>
> So what we have here is a balance between a system with an interrupted
> release-upgrade, requiring a lot of apt-foo to fix, or a system where
> dkms rebuilds might have failed, but otherwise upgraded successfully.
> Both cases could result in an unbootable system, but I tend to agree

Note quite. The completed upgrade system with missing dkms is bootable
with new kernel. Or also bootable with the old kernel (and old dkms
module) those are not purged and remain on disk.

So one can do successful boot using old kernel (and thus still have
access to weird wlan) to figure out how to update their 3rd party dkms
to be compatible with a new kernel.

So it is a massive improvement on the situation.

> that the first one (interrupted release-upgrade) is more likely to be
> much harder to recover (been there).
>

This is very true and the core point of this SRU.

> I would like some sort of commitment on the follow-up work for the
> release upgrader to check the status of dkms builds after the upgrade.
> Can we get an LP bug for it please?
>

That's this bug report that was opened in May and still being
discussed https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/2020406

--
okurrr,

Dimitri