________________________________
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?
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 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
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-070e4a3ea4 f8.png# logo]
Nicolas L'huillier
Brasserie La Cavalière Occitane
0608889301 <tel:0608889301> | <http:// www.brasseriela cavalièreoccitane.fr> www.brasseriela cavaliereoccita ne.fr<http:// www.brasseriela cavaliereoccita ne.fr>
<mailto: contact@ brasserielacava lièreoccitane. fr><email address hidden> <mailto: <email address hidden>><mailto: contact@ brasserielacava liè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! 1s0x12a91168d8f 11c93:0x341191e c8c4e5c2f! 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?
-- /bugs.launchpad .net/bugs/ 2028366
You received this bug notification because you are subscribed to a
duplicate bug report (2033408).
https:/
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 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
To manage notifications about this bug go to: /bugs.launchpad .net/ubuntu/ +source/ dkms/+bug/ 2028366/ +subscriptions
https:/