Wireguard fails to install with November update

Installing wireguard with the 4.9.113-55-osmc kernel fails in the DKMS build phase.

DKMS make.log for wireguard-1.0.20210219 for kernel 4.9.113-55-osmc (aarch64)
Fri 26 Nov 2021 10:40:54 AM EST
make: Entering directory '/usr/src/vero364-headers-4.9.113-55-osmc'
arch/arm64/Makefile:27: ld does not support --fix-cortex-a53-843419; kernel may be susceptible to erratum
  LD      /var/lib/dkms/wireguard/1.0.20210219/build/built-in.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20210219/build/main.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20210219/build/noise.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20210219/build/device.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20210219/build/peer.o
gcc: error: unrecognized command line option ‘-mgeneral-regs-only’
gcc: error: unrecognized command line option ‘-mcmodel=large’
make[1]: *** [scripts/Makefile.build:334: /var/lib/dkms/wireguard/1.0.20210219/build/main.o] Error 1
make[1]: *** Waiting for unfinished jobs....
gcc: error: unrecognized command line option ‘-mgeneral-regs-only’
gcc: error: unrecognized command line option ‘-mgeneral-regs-only’
gcc: error: unrecognized command line option ‘-mcmodel=large’
gcc: error: unrecognized command line option ‘-mcmodel=large’
make[1]: *** [scripts/Makefile.build:334: /var/lib/dkms/wireguard/1.0.20210219/build/noise.o] Error 1
make[1]: *** [scripts/Makefile.build:334: /var/lib/dkms/wireguard/1.0.20210219/build/device.o] Error 1
gcc: error: unrecognized command line option ‘-mgeneral-regs-only’
gcc: error: unrecognized command line option ‘-mcmodel=large’
make[1]: *** [scripts/Makefile.build:334: /var/lib/dkms/wireguard/1.0.20210219/build/peer.o] Error 1
make: *** [Makefile:1618: _module_/var/lib/dkms/wireguard/1.0.20210219/build] Error 2
make: Leaving directory '/usr/src/vero364-headers-4.9.113-55-osmc'

This is using gcc (Debian 8.3.0-6) 8.3.0 (dpkg version 4:8.3.0-1).

Looks like you are building using the wrong tool chain. The kernel is Aarch64.

I think I’m confusing myself. Are these the expected results for a Vero4K?

$ dpkg --print-architecture
armhf
$ dpkg --print-foreign-architectures
arm64

i.e. Kernel packages are arm64 and userland packages are armhf?

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.

Verified.

$ dpkg -L vero364-image-4.9.113-55-osmc | grep wireguard.ko
/lib/modules/4.9.113-55-osmc/kernel/net/wireguard/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
https://packages.debian.org/buster-backports/wireguard-tools

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
https://packages.debian.org/bullseye/wireguard-tools

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

https://packages.debian.org/bullseye/wireguard-dkms

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.

Cheers

Sam

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