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;
> importance=Undecided; assignee=None;
> Launchpad-Bug: distribution=ubuntu; distroseries=mantic;
> sourcepackage=dkms; component=main; status=Fix Released;
> importance=Undecided; assignee=None;
> Launchpad-Bug-Tags: patch verification-done-lunar verification-needed
> Launchpad-Bug-Information-Type: Public
> Launchpad-Bug-Private: no
> Launchpad-Bug-Security-Vulnerability: no
> Launchpad-Bug-Commenters: afredfactice janitor juergh racb tjaalton
> ubuntu-sru-bot xnox
> Launchpad-Bug-Reporter: Juerg Haefliger (juergh)
> Launchpad-Bug-Modifier: Robie Basak (racb)
> Launchpad-Message-Rationale: Subscriber
> Launchpad-Message-For: xnox
>
>