Has anybody tried to install Wireguard?


The error you’re seeing is very similar to the one in this post: Mantistek WA150, which I can reproduce.

The Mantistek WA150 code does not produce the error on Raspbian Jessie or Debian stretch (amd64) (I’ll look at Raspbian stretch when I have a bit more time).

So far, it looks like there might be a problem with the OSMC headers package.

Update: The problem does not occur with Raspbian stretch.


I worked out that the include directories are relative to the directory in which make is running (duh!). So on my Raspbian, that’s /lib/modules/4.14.79-v7+/build.

In my Raspbian build environment, I traced the sequence of includes from the error in the make.log and there’s a difference. The difference is that in Raspbian nf_conntrack_tuple_common.h comes from ./include/uapi/linux/netfilter/nf_conntrack_tuple_common.h instead of ./include/linux/netfilter/nf_conntrack_tuple_common.h as shown in the error message from the OSMC build environment.

When Raspbian gets to ./include/linux/netfilter.h it then includes ./include/uapi/linux/if.h instead of OSMC’s ./include/linux/if.h. The Raspbian file ./include/uapi/linux/if.h includes <linux/socket.h> rather than <sys/socket.h>.

A quick google tells me that the uapi directory is for the user-space API headers. Is this useful information?

Edited 2019-01-10: Made it clearer which is Raspbian vs OSMC.


I had a look at the osmc build script on github but I’m not that familiar with kernel build processes. Is the problem somehow related to the code that disassembles the kernel headers package here?


Shouldn’t be.
IIRC, make-kpkg doesn’t handle UAPI for arm in the same way it does for other platforms.


I’ve not managed to find an example of ./include/linux/if.h: on the 4.14.78 kernel image from kernel.org – and, as you already mentioned, it doesn’t appear in the Raspbian 4.14.79-v7+ headers. If @sam_nazarko can tell us the source of the kernel headers he’s using, that would be a step forward.


The kernel headers come from the tree itself.


Well, the build.sh code downloads a compressed tar file from kernel.org.


Are you referring to this file? That’s the “clean” Linux source tree without any distribution-related changes.


A correction to my last post: The file if.h does include <sys/socket.h> if __KERNEL__ is not defined:

#ifndef __KERNEL__
#include <sys/socket.h>			/* for struct sockaddr.		*/

For the Rasbian build, __KERNEL__ must be getting defined somewhere. I haven’t checked how this is getting defined - compiler flags or other explicit #define - but either way it seems strange that the OSMC header file(s) are ending up in different directories to what’s on kernel.org.


Hi there,

I’m also very interested in getting Wireguard running on osmc. I’m also stuck with the same error messages as @graza has mentioned above (sys/socket.h: No such file or directory). Tried creating different symbolic links from the existing socket.h files to probably used folders during make process, but still the socket.h can’t be found.

So if someone has hints or ideas how to sole this issue, I would be really grateful.


I’ve tracked down what I believe to be the source of the problem to the use of the make headers_install command in the kernel-osmc build. There’s a shell script at ./src/linux-4.14.78/scripts/headers_install.sh that contains this piece of code:

echo "Usage: headers_install.sh OUTDIR SRCDIR [FILES...]"
echo "Prepares kernel header files for use by user space, by removing"
echo "all compiler.h definitions and #includes, removing any"
echo "#ifdef __KERNEL__ sections, and putting __underscores__ around"
echo "asm/inline/volatile keywords."
echo "OUTDIR: directory to write each userspace header FILE to."
echo "SRCDIR: source directory where files are picked."
echo "FILES:  list of header files to operate on."

It take the uapi headers and changes code such as:

#ifndef __KERNEL__ 
#include <sys/socket.h>     /* for struct sockaddr. */ 


#include <sys/socket.h>			/* for struct sockaddr.		*/

thereby losing the #ifndef logic. This doesn’t happen on Raspbian – and I don’t understand why this logic is being stripped out. Perhaps @sam_nazarko can explain why it’s done this way.

It looks like the altered files are then copied from ./include/linux/uapi to ./include/linux, which is why you see two different versions of (for example) if.h. It’s not simply a matter of deleting everything from ./include/linux since it wasn’t originally empty.


Still exploring.



As a workaround for now, you can remove all dodgy headers in the include/linux directory, then re-copy from the kernel.org source:

sudo rm -r /usr/src/rbp2-headers-4.14.78-4-osmc/include/linux/*
sudo cp -ar ./linux-4.14.78/include/linux/* /usr/src/rbp2-headers-4.14.78-4-osmc/include/linux/

The WireGuard make sails through – though, in my case, I needed to add the package libmnl-dev.

osmc@osmc:~$ modinfo wireguard
filename:       /lib/modules/4.14.78-4-osmc/extra/wireguard.ko
alias:          net-pf-16-proto-16-family-wireguard
alias:          rtnl-link-wireguard
version:        0.0.20181218-13-g83a9318
author:         Jason A. Donenfeld <Jason@zx2c4.com>
description:    WireGuard secure network tunnel
license:        GPL v2
srcversion:     2D91A3D8F670D97E4F9BE3C
depends:        ipv6,udp_tunnel,ip6_udp_tunnel
name:           wireguard
vermagic:       4.14.78-4-osmc SMP preempt mod_unload modversions ARMv7 p2v8 

As for getting it to work, I’ll leave that to you!

Mantistek WA150

This is still an outstanding problem when producing armhf packages.
I think make-kpkg is causing this issue.

I thought I’d fixed this some time ago but will need to revisit as we should be shipping everything needed to build modules when the header packages are installed.


@dillthedog Thanks, I’ll try that and report back.

I created a VirtualBox VM and checked out the OSMC github repo to see if I can understand what’s going on with the packaging. While it was compiling everything for the rbpi2 target, I looked at the source tree and the headers are there as per the content of kernel.org.

I took quite a while to compile everything - maybe 28 hours or more? Not sure if that’s normal or if it would benefit from having more virtual CPUs in the VM?


That’s quite a long time; I’d assign some more CPUs if you can.
You can also build on the Pi itself.



You don’t mention what processor you used, but 28+ hours in a VM suggests that either your processor doesn’t have hardware-based virtualization support or it’s not been enabled in the BIOS.


It’s a 6yo MacbookPro. Perhaps the age of the machine has some inherent limits and is slowing things down? It’s a Core i7 (IvyBridge) running at 2.3GHz. No BIOS settings and I think VT-x is enabled by default. VirtualBox at least says it’s using VT-x. I’ve switched to KVM (instead of “Default”) paravirtualisation and will see what happens.

I will try on the Pi itself as well.

From the website, it’s not entirely clear what should be done to build the kernel package. I built and installed an ARMv7 toolchain. I then went to osmc/package/kernel-osmc to do a make rbpi2.

Is that correct?


make rbp2 is all you need to do to get the debs


Yeah I understood that the toolchain was an optional step. I will remove the one I built and I guess the debs will be downloaded…

Is that the correct directory in which to do the build - osmc/package/kernel-osmc?


Yes — to both