Hi,
I am facing the same issue with linux-image-4.19.0-5-amd64 /
linux-headers-4.19.0-5-amd64, when installing our customed driver
module: x86/modules: Skipping invalid relocation target, existing value is
nonzero for type 1, loc 4235e5ed, val c165c821
Found also similar issu
On 2019-10-02 19:25, Daniel Kahn Gillmor wrote:
If anyone has any clearer diagnostics about what version of wireguard
introduced the errors for the older kernels, or (even better) what
specific change seems to cause the incompatibility, then that might be
useful for further debugging.
I actuall
On Wed 2019-10-02 16:05:06 +0800, Aron Xu wrote:
> I tried more to reproduce this bug, the problem only affect linux
> 4.19.0-0.bpo.4 and 4.19.0-0.bpo.5 (while I haven't tried earlier bpo
> versions), and does not affect 4.9 or 4.19.0-0.bpo.6
From Michel Meyers messages in this thread, it looks li
On 2019-10-02 10:05, Aron Xu wrote:
I tried more to reproduce this bug, the problem only affect linux
4.19.0-0.bpo.4 and 4.19.0-0.bpo.5 (while I haven't tried earlier bpo
versions), and does not affect 4.9 or 4.19.0-0.bpo.6
Since the affecting surface is small so far, I would suggest anyone
run
I tried more to reproduce this bug, the problem only affect linux
4.19.0-0.bpo.4 and 4.19.0-0.bpo.5 (while I haven't tried earlier bpo
versions), and does not affect 4.9 or 4.19.0-0.bpo.6
Since the affecting surface is small so far, I would suggest anyone
run into this problem on stretch(-bpo) to
Appears that I have encountered this problem as well. Running kernel
is 4.19.0-0.bpo.4-rt-amd64, which is the only installed kernel,
relevant kernel headers are also installed (and are the only headers
packages).
# dpkg -l 'linux-headers-*' 'linux-image-*'
Desired=Unknown/Install/Remove/Purge/Hold
Hello,
I'm seeing the same issue with kernel 4.19.0-2-amd64.
Trying to manually compile the module also gives this result:
root@server:/usr/src/wireguard-0.0.20190905# uname -a
Linux server 4.19.0-2-amd64 #1 SMP Debian 4.19.16-1 (2019-01-17) x86_64
GNU/Linux
root@server:/usr/src/
On September 11, 2019 3:45:45 PM UTC, Daniel Kahn Gillmor
wrote:
>Over on https://bugs.debian.org/939845, On Wed 2019-09-11 00:26:18
>-0400, Matthew Gabeler-Lee wrote:
>> Having a system update disable a network interface and fail to
>restore it is
>> ... bad. Luckily I wasn't accessing the s
Hi David--
On Wed 2019-09-11 17:36:29 +0200, David Raison wrote:
>> 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 wh
On Wed, 11 Sep 2019, Daniel Kahn Gillmor wrote:
But hm, maybe the 4.19.0-5 ABI wasn't actually stable?
Thinking about this a bit more ... the issue wasn't a symvers mismatch,
which is what I'd have expected if the ABI was not actually stable, and
in my case the module headers exactly matched
On Wed, 11 Sep 2019, Daniel Kahn Gillmor wrote:
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.
Right, but it looks like the Makefile(s) for wireguard might have been
buggy. Of course, I dont know if
On 11/09/2019 17:30, Daniel Kahn Gillmor wrote:
>
> 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 actuall
Over on https://bugs.debian.org/939845, On Wed 2019-09-11 00:26:18 -0400,
Matthew Gabeler-Lee wrote:
> Having a system update disable a network interface and fail to restore it is
> ... bad. Luckily I wasn't accessing the systems in question over that vpn!
i totally agree that this is bad. Plea
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 ... unli
Package: wireguard-dkms
Version: 0.0.20190905-1
Followup-For: Bug #939845
Same problem here.
Seems pretty normal to install updates before activating a new kernel
I notice that systems that have hand-configured wireguard intefaces, the
upgrade scripts won't reload the module, but systems
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 t
Thanks for looking into this, Daniel.
On 10/09/2019 02:24, Daniel Kahn Gillmor wrote:
> I note here that you're not running the latest kernel -- 4.19.0-5-amd64
> is not 4.19.0-6-amd64. is it possible that you don't have
> linux-image-4.19.0-5-amd64 or its headers installed any more, despite
> ru
Control: tag 939845 + moreinfo unreproducible
Hi David--
On Mon 2019-09-09 14:52:48 +0200, David Raison wrote:
> I upgraded the wireguard-dkms package during a regular apt upgrade,
> which seems to have produced an invalid module:
>
> Unpacking wireguard-dkms (0.0.20190905-1) over (0.0.20190702-3
Package: wireguard-dkms
Version: 0.0.20190905-1
Severity: normal
Dear Maintainer,
I upgraded the wireguard-dkms package during a regular apt upgrade,
which seems to have produced an invalid module:
Unpacking wireguard-dkms (0.0.20190905-1) over (0.0.20190702-3) ...
Setting up wireguard-dkms (0.0
19 matches
Mail list logo
