Well, the build.sh code downloads a compressed tar file from kernel.org.
SOURCE_LINUX="https://www.kernel.org/pub/linux/kernel/v${MAJOR}.x/linux-${DL_VERSION}.tar.xz"
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. */
#endif
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
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
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. */
#endif
to
#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.
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!
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.
Sam
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
I have gotten very busy at work so I have not had much time of late to look at this. I did do the build on the Pi and it finished much faster than cross compiling in a VM. Assuming that this works, I was wondering:
I was also digging around the make headers_install stuff to understand what it’s for. I found this on LWN and this on Stackoverflow. Reading that and other related stuff leads me to understand that it’s to be used when you want to export kernel headers into /usr/include so that kernel APIs can be called from user-space libraries such as Glibc.
Is that your understanding @sam_nazarko?
DKMS can be used to rebuilt kernel modules when a new kernel version is installed, but doesn’t fit well with OSMC.
Unfortunately, DKMS will probably fail since (a) AFAICT there is no headers metapackage on OSMC that will automatically install the headers for a new kernel; and (b) we still need to create a symbolic link build under /lib/modules/$(uname -r)/ that points to /usr/src/rbp2-headers-$(uname -r). So, unless you can crack these issues, you’ll probably need to recompile manually – though it’s easy to repeat after the initial set up.
I don’t have plans to support DKMS for the forseeable future.
You’d need to build every release.
I will look in to the headers issue however
I would also love to get Wireguard working on my Vero 4k+. Have tried installing the Debian package from Unstable, which leads to:
E: Couldn't find any package by glob 'linux-headers-3.14.29-143-osmc'
E: Couldn't find any package by regex 'linux-headers-3.14.29-143-osmc'
Is this the right path, is there a working method yet?
Since Wireguard is a kernel module, it needs to be built for the specific kernel currently installed. To get this to work on OSMC is possible but you really need to read this thread from post #7, since the process requires a few workarounds.
Above kernel made Wireguard work beautifully for me.
For Wireguard to work, I had to install the wireguard-dkms package, and with this, even wg-quick works flawlessly.