Currently, Ubuntu uses the livepatch interface built into our kernels since 4.15.0. The kpatch interface is an older method for doing in-place patching that predates livepatch, but is included in our 4.4 kernels, so our livepatch users do not need or use the DKMS module on any of our kernels.
According to the upstream issue tracker for kpatch, the specific problem here is:
"tglx renovated the stack trace code for 5.2 (see patchset in lkml archive), changing struct stack_trace and its related APIs.
Sooner or later we're going to deprecate the kpatch core module since its functionality can be provided by the kernel livepatch API. But in case anyone wants to continue to using it with newer kernels, consider this a heads up that work will be required to build it for 5.2."
Since upstream is intending to deprecate the code and we don't use it, I think it would make the most sense to remove the kpatch-dkms package, and the test that failed, for eoan.
Currently, Ubuntu uses the livepatch interface built into our kernels since 4.15.0. The kpatch interface is an older method for doing in-place patching that predates livepatch, but is included in our 4.4 kernels, so our livepatch users do not need or use the DKMS module on any of our kernels.
According to the upstream issue tracker for kpatch, the specific problem here is:
"tglx renovated the stack trace code for 5.2 (see patchset in lkml archive), changing struct stack_trace and its related APIs.
Sooner or later we're going to deprecate the kpatch core module since its functionality can be provided by the kernel livepatch API. But in case anyone wants to continue to using it with newer kernels, consider this a heads up that work will be required to build it for 5.2."
https:/ /github. com/dynup/ kpatch/ issues/ 966
Since upstream is intending to deprecate the code and we don't use it, I think it would make the most sense to remove the kpatch-dkms package, and the test that failed, for eoan.