Wireguard fails to install with November update

That’s correct.

Ok, thanks for bearing with me. Then I guess I’m not following your first comment:

The error log above is from simply running apt install wireguard.

Relevant packages are I think of the correct architectures:

$ dpkg -l | egrep 'wireguard|dkms|gcc-8'
ii  dkms                                   2.6.1-4                             all          Dynamic Kernel Module Support Framework
ii  gcc-8                                  8.3.0-6                             armhf        GNU C compiler
ii  gcc-8-base:armhf                       8.3.0-6                             armhf        GCC, the GNU Compiler Collection (base package)
ii  libgcc-8-dev:armhf                     8.3.0-6                             armhf        GCC support library (development files)
iU  wireguard                              1.0.20210223-1~bpo10+1              all          fast, modern, secure kernel VPN tunnel (metapackage)
iF  wireguard-dkms                         1.0.20210219-1~bpo10+1              all          fast, modern, secure kernel VPN tunnel (DKMS version)
ii  wireguard-tools                        1.0.20210223-1~bpo10+1              armhf        fast, modern, secure kernel VPN tunnel (userland utilities)

The gcc: error: unrecognized command line option ‘-mgeneral-regs-only’ has me especially confused since -mgeneral-regs-only was added in gcc-7.

The Wireguard kernel module is already included. I added it some time ago.


$ dpkg -L vero364-image-4.9.113-55-osmc | grep wireguard.ko

Ok then maybe this is just a packaging issue?

$ apt-cache show wireguard | grep ^Depends
Depends: wireguard-modules (>= 0.0.20191219) | wireguard-dkms (>= 0.0.20200121-2), wireguard-tools (>= 1.0.20210223-1~bpo10+1)

If the OSMC kernel packages could be made to provide wireguard-modules, then installing wireguard would not need to pull in wireguard-dkms to unnecessarily recompile the kernel module.

(See for example linux-image-armmp.)

$ apt-cache show linux-image-armmp | grep wireguard
Provides: linux-image-generic, linux-latest-modules-5.10.0-0.bpo.9-armmp, wireguard-modules (= 1.0.0)

Attempted a pull request for this: [package] [kernel-osmc] Provide wireguard-modules

I’m not sure that this is the best approach, because it will prevent a user from taking the userland version of Wireguard DKMS modules, unless the Debian kernels themselves are taking this approach. But does this mean that we then should be doing this for other kernel modules which we provide in-tree?

Instead, the DKMS module can simply be installed / compiled but not used.
What’s it look like in Bullseye? That has a newer kernel which would ship Wireguard OOTB. So I’d be surprised if the Wireguard package in Bullseye still depends on DKMS packages.

That does seem to be what Bullseye is doing.

I can’t link to it directly, but if you search the virtual packages subsection for wireguard-modules you see it’s provided by all the linux-image-* packages.

AFAIU, this wouldn’t preclude users from installing wireguard-dkms if they wanted to.

It does seem to be a common idiom to provide alternate foo-dkms and foo-modules packages to satisfy a dependency. Although in most cases, the virtual foo-modules package is provided by actual foo-modules-<version>-<arch> packages rather than the kernel packages directly. I guess this is for modularity.

wireguard-modules appears to be a one-off deviation from this pattern.

Not sure if this answers your question.

Okay, we can take it. I need to check if the Provides version is high enough for Bullseye too.

From the buster-packports page

rec: wireguard-modules (>= 0.0.20171001)
    Package not available 
or wireguard-dkms (>= 0.0.20191219)
    fast, modern, secure kernel VPN tunnel (DKMS version) 

Shouldn’t that accept both dependencies?

Sure – but we’re talking about Bullseye.

That should be the same

rec: wireguard-modules (>= 0.0.20171001)
    Package not available 
or wireguard-dkms (>= 0.0.20191219)
    fast, modern, secure kernel VPN tunnel (DKMS version) 


Best to artificially inflate this version, because it’s > 1.0.0 already.

I’ve merged @mbarnes PR. Many thanks, but bumped the dependency version to prevent any surprises with upstream for the foreseeable.



Thank you!

FWIW, I’m still trying to figure out why wireguard-dkms is failing to install here. In the vero3-linux repo, the arm64 makefile adds -mgeneral-regs-only to KBUILD_CFLAGS. As I showed above, this option was supposedly added in gcc-7 and yet:

$ gcc-8 -mgeneral-regs-only
gcc-8: error: unrecognized command line option ‘-mgeneral-regs-only’

But I’ve confused myself enough for one day.

Our kernel is Aarch64
Userland is armhf

So any GCCv ia APT will be armhf and won’t work for the kernel.

Quickest way to get an aarch64 toolchain is sudo apt-get install aarch64-toolchain-osmc; but that’ll require you to chroot.

Ah, I (finally) understand now. And furthermore -mgeneral-regs-only is architecture-specific; present for aarch64 but not arm64. Sorry for being dense.

So it would seem installing any *-dkms package by way of APT is going to fail on OSMC. Based on other forum posts (1, 2) I take it this is a known issue.

In any case, thank you again for accepting the wireguard install fix.

1 Like

Yes – and that would happen anyway without headers (although we do provide them in APT)

@sam_nazarko After installing the latest OSMC update I realized the patch I gave you here wasn’t quite right, because it didn’t account for the kernel package architecture. My apologies.

The wireguard package on vero364 wants wireguard-modules:armhf, but the latest kernel is providing wireguard-modules:arm64, which apt ignores. So the dependency still isn’t satisfied.

Now that I’ve learned how to build the OSMC kernel, I fixed my original patch and actually tested it this time. On OSMC platforms where the kernel and user space architectures differ (which is just vero364 and rbp464, correct?), the “Provides” line needs to specify the user space architecture. That required hacking build.sh.

Thanks for the PR. I’ll check it out tomorrow.