Control: tags 939845 + moreinfo On Wed 2019-09-11 00:33:19 -0400, Matthew Gabeler-Lee wrote: > On Wed, 11 Sep 2019, Matthew Gabeler-Lee wrote: > >> Not sure if the common dkms scripts might be passing the KERNELRELEASE var >> in a way that is messing up the build? In fairness, that seems ... unlikely >> to be the cause of an invalid relocation, and more likely to _fix_ having >> built the module for the new kernel before booting it :) > > Small addendum: indeed the module built for the new kernel while running > the old kernel indeed loaded correctly after booting into 4.19.0-6 -- I > did not need to rebuild the dkms module after rebooting. It was, > ironically, only the module built for the _running_ kernel that was bad.
IIUC, dkms should build different modules for different kernel ABIs. it
won't try to install the 4.19.0-6 module into the 4.19.0-5 kernel.
It sounds to me like you and David are saying this report is specific to
an interaction with 4.19.0-5 and wireguard 0.0.20190905-1, not that the
problem has to do with a generic upgrade path.
But hm, maybe the 4.19.0-5 ABI wasn't actually stable? do either of you
(Matthew or David) know what version of 4.19.0-5 was actually running on
your system, vs. what version of linux-headers-4.19.0-5 you had
installed when it was built? That would be a useful datapoint.
it looks like there were 8 different debian releases that claim this
ABI:
https://snapshot.debian.org/binary/linux-image-4.19.0-5-amd64/
https://snapshot.debian.org/binary/linux-headers-4.19.0-5-amd64/
If anyone has time to dig further, it would be great to try to replicate
this problem in a minimalist VM and report back which versions seem to
tickle the issue.
--dkg
signature.asc
Description: PGP signature
