DietPi-Software | WireGuard: Lightweight modern in-kernel VPN

[MichaIng]

Creating a software request:

• Ref: https://dietpi.com/phpbb/viewtopic.php?f=12&t=4540
• @hd888 thanks for request!

Vote for it on FeatHub: https://feathub.com/MichaIng/DietPi/+14

Give us some formal software information:

• Software title | WireGuard
• Short description | Fast, modern, secure VPN tunnel
• GitHub URL (if available) | https://git.zx2c4.com/WireGuard/
• External URL (if available) | https://www.wireguard.com/
• (Official) install documentation | https://www.wireguard.com/install/
  
  
  
  • It is still experimental stage, but sounds promising.
  
  

Are there similar/alternative software titles available with DietPi-Software?

• 97 OpenVPN: vpn server
• 117 PiVPN: openvpn installer & management tool

What makes your requested software better than the above solutions, if available?

• Seems to be faster and more lightweight than OpenVPN, as it runs in kernel.
• But some testing makes sense.

Can you provide the installation steps that you would suggest DietPi-Software to do?

1. Add Debian Sid repo: https://packages.debian.org/sid/wireguard
2. Set priority of unstable/sid repo low enough to prevent any automated install.
3. G_AGI wireguard -t sid

[MichaIng]

A problem is, that the Raspbian repo does not have a sid/unstable repo, so no branch where wireguard is available: http://raspbian.raspberrypi.org/raspbian/dists/

Debian armhf usually works on Raspbian/RPi systems, so we can add Debian sid there as well and test, but all this makes it even more experimental 😜.

[thaihugo]

I have a fonctionning wireguard setup on my DietPi using this setup:
https://www.tnhh.net/posts/wireguard-router-firewalled-computer-raspberry-pi.html

It even updates itself nicely with new DietPi-updates with kernel updates

[MichaIng]

@thaihugo
Many thanks for this.

armel, not armhf - the Raspberry Pi's CPU doesn't have some of the features of the armhf arch in Debian, if you download and install the armhf package, it will crash

So just adding the Debian/sid repo would have not worked then. Needs to be checked on all RPi models, as they might behave differently?

But still, all this looks very hacky to me, in combination with wireguard considering itself as experimental and not even reaching testing repo.

Warning: WireGuard is currently under development, and therefore any installation steps here should be considered as experimental. We are rapidly working toward mainline inclusion, at which point we will consider this codebase non-experimental.

If we add it on the current stage to DietPi, it should be clearly marked for our users as experimental too. Hope it reaches Raspbian+Debian testing repo soon, which would also assure a well working version for RPi.

---

Issue on Rock64, needs investigation: https://dietpi.com/phpbb/viewtopic.php?f=11&t=4579

[thaihugo]

It is basically using the right binary with a wrong info for the packager. It is more complicated to force the armel armhf thing with a dpgk —force-architecture as it will block something down the line. I know it’s hackish but at least the solution is correctly integrated with apt and kernel updates.
As for the wireguard « unstable » status, You are the juge of this, but for my tests it feels more like a way to « underpromise, overdeliver »

[MichaIng]

Jep, the solution is great. We could use this for some other software titles as well, possibly. If I am not wrong, we add i386 repo arch to all x86_64 images, just for 1 or 2 software titles that have no x64 package. But adjusting the packages instead of adding the arch to all devices sounds cleaner to me. Also it reduces the time and data transfer for APT updates significantly.

So for now your solution indeed seem the best one can do. I am just not sure, if we should add WireGuard as long as it simple needs this hackish steps and considers itself as experimental. On the other hand, it seems to be very beneficial over OpenVPN in many ways, worth to push. If we then can help testing/debugging it for the devs and allow faster Beta/Release, even better 😃.

Let's wait for @Fourdee opinion here. He's a bid busy currently, so perhaps we need to be more patient compared to usual response time 😉.

[HiDef888]

Thanks @thaihugo Got mine setup on my VM with no issues with those instructions! Obviously with less trouble using the amd64 binaries. Im a little curious if those extra steps are even necessary with a RPi 3 or not! Apparently anytihng over armv7 is good to go with the armhf packages from what i gather.

[Micha-Btz]

On my Raspi 3b+ I can use the debian armhf package directly without modifying it.

[slim0287]

I'm looking forward to Wireguard in Dietpi as well. Currently I run an OpenVPN server on Dietpi, however from what I have read Wireguard will be a better implementation for my use case.

[MichaIng]

Added to FeatHub, feel free to vote for it: https://feathub.com/MichaIng/DietPi/+14

[MichaIng]

Install test on VM Stretch:

echo 'deb https://deb.debian.org/debian/ sid main' > /etc/apt/sources.d/dietpi-wireguard.list
echo -e 'Package: *\nPin: release n=sid\nPin-Priority: 99' > /etc/apt/preferences.d/dietpi-wireguard
G_AGI wireguard
...
Need to get 22.7 MB of archives.
After this operation, 96.5 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 https://cdn-aws.deb.debian.org/debian stretch/main amd64 binutils amd64 2.28-5 [3,770 kB]
Get:2 https://cdn-aws.deb.debian.org/debian stretch/main amd64 libisl15 amd64 0.18-1 [564 kB]
Get:3 https://cdn-aws.deb.debian.org/debian stretch/main amd64 libmpfr4 amd64 3.1.5-1 [556 kB]
Get:4 https://cdn-aws.deb.debian.org/debian stretch/main amd64 libmpc3 amd64 1.0.3-1+b2 [39.9 kB]
Get:5 https://cdn-aws.deb.debian.org/debian stretch/main amd64 cpp-6 amd64 6.3.0-18+deb9u1 [6,584 kB]
Get:6 https://cdn-aws.deb.debian.org/debian stretch/main amd64 cpp amd64 4:6.3.0-4 [18.7 kB]
Get:7 https://cdn-aws.deb.debian.org/debian stretch/main amd64 libcc1-0 amd64 6.3.0-18+deb9u1 [30.6 kB]
Get:8 https://cdn-aws.deb.debian.org/debian stretch/main amd64 libgomp1 amd64 6.3.0-18+deb9u1 [73.3 kB]
Get:9 https://cdn-aws.deb.debian.org/debian stretch/main amd64 libitm1 amd64 6.3.0-18+deb9u1 [27.3 kB]
Get:10 https://cdn-aws.deb.debian.org/debian stretch/main amd64 libatomic1 amd64 6.3.0-18+deb9u1 [8,966 B]
Get:11 https://cdn-aws.deb.debian.org/debian stretch/main amd64 libasan3 amd64 6.3.0-18+deb9u1 [311 kB]
Get:12 https://cdn-aws.deb.debian.org/debian stretch/main amd64 liblsan0 amd64 6.3.0-18+deb9u1 [115 kB]
Get:13 https://cdn-aws.deb.debian.org/debian stretch/main amd64 libtsan0 amd64 6.3.0-18+deb9u1 [257 kB]
Get:14 https://cdn-aws.deb.debian.org/debian stretch/main amd64 libubsan0 amd64 6.3.0-18+deb9u1 [107 kB]
Get:15 https://cdn-aws.deb.debian.org/debian stretch/main amd64 libcilkrts5 amd64 6.3.0-18+deb9u1 [40.5 kB]
Get:16 https://cdn-aws.deb.debian.org/debian stretch/main amd64 libmpx2 amd64 6.3.0-18+deb9u1 [11.2 kB]
Get:17 https://cdn-aws.deb.debian.org/debian stretch/main amd64 libquadmath0 amd64 6.3.0-18+deb9u1 [131 kB]
Get:18 https://cdn-aws.deb.debian.org/debian stretch/main amd64 libgcc-6-dev amd64 6.3.0-18+deb9u1 [2,296 kB]
Get:19 https://cdn-aws.deb.debian.org/debian stretch/main amd64 gcc-6 amd64 6.3.0-18+deb9u1 [6,900 kB]
Get:20 https://cdn-aws.deb.debian.org/debian stretch/main amd64 gcc amd64 4:6.3.0-4 [5,196 B]
Get:21 https://cdn-aws.deb.debian.org/debian stretch/main amd64 make amd64 4.1-9.1 [302 kB]
Get:22 https://cdn-aws.deb.debian.org/debian stretch/main amd64 patch amd64 2.7.5-1+deb9u1 [112 kB]
Get:23 https://cdn-aws.deb.debian.org/debian stretch/main amd64 dkms all 2.3-2 [74.8 kB]
Get:24 https://cdn-aws.deb.debian.org/debian sid/main amd64 wireguard-dkms all 0.0.20181218-1 [263 kB]
Get:25 https://cdn-aws.deb.debian.org/debian sid/main amd64 wireguard-tools amd64 0.0.20181218-1 [94.5 kB]
Get:26 https://cdn-aws.deb.debian.org/debian sid/main amd64 wireguard all 0.0.20181218-1 [20.3 kB]

🈯️ Only wireguard* packages are pulled from sid repo, which is what we want. Priority 100 however should allow APT upgrades of those.

[MichaIng]

Linux headers are required for wireguard-dkms to build it's kernel module.

/etc/network/interfaces could be used to setup the VPN interface via ifupdown/networking service. But wireguard comes with it's own systemd unit [email protected] which allows the VPN to be handled more independent from the network in general, so we an e.g. handle it via dietpi-services, while the remaining networking service is completely untouched by this.

To forward all traffic from the VPN clients to the servers internet interface, iptables works well. I am not too experienced and didn't manage to achieve this via route tables iproute2/ip r add... command... This would be actually the cleaner solution at first, to avoid the need to install iptables.

[MichaIng]

PR up: https://github.com/Fourdee/DietPi/pull/2398

[Fourdee]

Install tests:

• 🈯️ RPi stock + install
• ~RPi with rpi-update testing kernel + install~ | https://github.com/Fourdee/DietPi/issues/2052#issuecomment-453671953
• 🈯️ VM stock + install + reinstall + uinstall

[Fourdee]

To do (WEB):

• https://dietpi.com/software entry
• Forum entry

Misc:

• Add support for other devices? Odroids should be fine thanks to meverics kernel header packages?

[Fourdee]

🈯️ Drop official support for use of rpi-update in DietPi.
🈯️ Not keen on having rpi-update checks throughout our code, will simply add patch for end users.

[Fourdee]

Tests:

• Odroid C1/N1 | unable to test, lack boards.
• 🈯️ C2 | ~Package version mismatch~

linux-headers-arm64-odroid-c2 is already the newest version (3.16.61-1).
linux-image-arm64-odroid-c2 is already the newest version (3.16.57-1).

• 🈯️ XU4 | ~Package version mismatch~

linux-headers-4.14-armhf-odroid-xu4 is already the newest version (4.14.87-1).
linux-image-4.14-armhf-odroid-xu4 is already the newest version (4.14.66-1).

Seems we need to reinstall these to ensure updates, this works:

 G_AGP linux-image-arm64-odroid-c2; G_AGI linux-image-arm64-odroid-c2

--reinstall has no effect, we need to purge + install again to update.

[Fourdee]

Rock headers + kernel included in package linux-rock64

Although we need to reinstall headers as we remove /usr/src during PREP.
linux-rock64 linux-headers*; G_AGA; G_AGI linux-rock64

Hmm, still fails:

Unpacking wireguard-dkms (0.0.20181218-1) over (0.0.20181218-1) ...
Setting up qrencode (3.4.4-1+b2) ...
Setting up wireguard-dkms (0.0.20181218-1) ...
Loading new wireguard-0.0.20181218 DKMS files...
Building for 4.4.132-1075-rockchip-ayufan-ga83beded8524
Building initial module for 4.4.132-1075-rockchip-ayufan-ga83beded8524
Error! Bad return status for module build on kernel: 4.4.132-1075-rockchip-ayufan-ga83beded8524 (aarch64)
Consult /var/lib/dkms/wireguard/0.0.20181218/build/make.log for more information

root@DietPi:~# cat /var/lib/dkms/wireguard/0.0.20181218/build/make.log
DKMS make.log for wireguard-0.0.20181218 for kernel 4.4.132-1075-rockchip-ayu-ga83beded8524 (aarch64)
Sun 13 Jan 03:52:59 GMT 2019
make: Entering directory '/usr/src/linux-headers-4.4.132-1075-rockchip-ayufan83beded8524'
/usr/bin/env: ‘python’: No such file or directory
  LD      /var/lib/dkms/wireguard/0.0.20181218/build/built-in.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20181218/build/main.o
/usr/bin/env: ‘python’: No such file or directory
  CC [M]  /var/lib/dkms/wireguard/0.0.20181218/build/noise.o
scripts/Makefile.build:277: recipe for target '/var/lib/dkms/wireguard/0.0.20218/build/main.o' failed
make[1]: *** [/var/lib/dkms/wireguard/0.0.20181218/build/main.o] Error 127
make[1]: *** Waiting for unfinished jobs....
/usr/bin/env: ‘python’: No such file or directory
scripts/Makefile.build:277: recipe for target '/var/lib/dkms/wireguard/0.0.20218/build/noise.o' failed
  CC [M]  /var/lib/dkms/wireguard/0.0.20181218/build/device.o
make[1]: *** [/var/lib/dkms/wireguard/0.0.20181218/build/noise.o] Error 127
/usr/bin/env: ‘python’: No such file or directory
scripts/Makefile.build:277: recipe for target '/var/lib/dkms/wireguard/0.0.20218/build/device.o' failed
make[1]: *** [/var/lib/dkms/wireguard/0.0.20181218/build/device.o] Error 127
Makefile:1471: recipe for target '_module_/var/lib/dkms/wireguard/0.0.2018121uild' failed
make: *** [_module_/var/lib/dkms/wireguard/0.0.20181218/build] Error 2
make: Leaving directory '/usr/src/linux-headers-4.4.132-1075-rockchip-ayufan-3beded8524'

🈯️ G_AGI python, requires python, why? lol

[MichaIng]

Further tuning: https://github.com/Fourdee/DietPi/pull/2420

[Fourdee]

• 🈴 RockPro64 | Kernel panic after image PREP. Unstable board? Occurs on non-dietpi images.
• 🈴 Rock64 | Updated to ARMbian image (available after v6.20 release).

root@DietPi:~# dpkg-reconfigure wireguard-dkms

------------------------------
Deleting module version: 0.0.20181218
completely from the DKMS tree.
------------------------------
Done.
Loading new wireguard-0.0.20181218 DKMS files...
Building for 4.4.167-rockchip64
Building initial module for 4.4.167-rockchip64
Error! Bad return status for module build on kernel: 4.4.167-rockchip64 (aarch64)
Consult /var/lib/dkms/wireguard/0.0.20181218/build/make.log for more information.

root@DietPi:~# uname -r
4.4.167-rockchip64

root@DietPi:~# dpkg --get-selections | grep headers
linux-headers-rockchip64 

/usr/bin/env: /usr/bin/env: ‘python’‘python’: No such file or directory: No such file or directory

root@DietPi:~# /usr/bin/env
LC_ALL=en_GB.UTF-8
SSH_CONNECTION=192.168.0.5 61508 192.168.0.24 22
LANG=en_GB.UTF-8
USER=root
PWD=/root
HOME=/root
SSH_CLIENT=192.168.0.5 61508 22
SSH_TTY=/dev/pts/0
TERM=xterm
SHELL=/bin/bash
SHLVL=1
LOGNAME=root
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
_=/usr/bin/env

Still fails with python build-essential installed:

https://forum.armbian.com/topic/5883-wireguard-on-a20/

Done.
Loading new wireguard-0.0.20181218 DKMS files...
Building for 4.4.167-rockchip64
Building initial module for 4.4.167-rockchip64
Error! Bad return status for module build on kernel: 4.4.167-rockchip64 (aarch64)
Consult /var/lib/dkms/wireguard/0.0.20181218/build/make.log for more information.
root@DietPi:~# cat /var/lib/dkms/wireguard/0.0.20181218/build/make.log
DKMS make.log for wireguard-0.0.20181218 for kernel 4.4.167-rockchip64 (aarch64)
Sat 26 Jan 09:13:12 GMT 2019
make: Entering directory '/usr/src/linux-headers-4.4.167-rockchip64'
  CC [M]  /var/lib/dkms/wireguard/0.0.20181218/build/main.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20181218/build/noise.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20181218/build/device.o
  LD      /var/lib/dkms/wireguard/0.0.20181218/build/built-in.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20181218/build/peer.o
/bin/sh: 1: ./scripts/recordmcount: not found
scripts/Makefile.build:277: recipe for target '/var/lib/dkms/wireguard/0.0.20181218/build/main.o' failed
make[1]: *** [/var/lib/dkms/wireguard/0.0.20181218/build/main.o] Error 127
make[1]: *** Deleting file '/var/lib/dkms/wireguard/0.0.20181218/build/main.o'
make[1]: *** Waiting for unfinished jobs....
/bin/sh: 1: ./scripts/recordmcount: not found
scripts/Makefile.build:277: recipe for target '/var/lib/dkms/wireguard/0.0.20181218/build/peer.o' failed
make[1]: *** [/var/lib/dkms/wireguard/0.0.20181218/build/peer.o] Error 127
make[1]: *** Deleting file '/var/lib/dkms/wireguard/0.0.20181218/build/peer.o'
/bin/sh: 1: ./scripts/recordmcount: not found
scripts/Makefile.build:277: recipe for target '/var/lib/dkms/wireguard/0.0.20181218/build/device.o' failed
make[1]: *** [/var/lib/dkms/wireguard/0.0.20181218/build/device.o] Error 127
make[1]: *** Deleting file '/var/lib/dkms/wireguard/0.0.20181218/build/device.o'
/bin/sh: 1: ./scripts/recordmcount: not found
scripts/Makefile.build:277: recipe for target '/var/lib/dkms/wireguard/0.0.20181218/build/noise.o' failed
make[1]: *** [/var/lib/dkms/wireguard/0.0.20181218/build/noise.o] Error 127
make[1]: *** Deleting file '/var/lib/dkms/wireguard/0.0.20181218/build/noise.o'
Makefile:1493: recipe for target '_module_/var/lib/dkms/wireguard/0.0.20181218/build' failed
make: *** [_module_/var/lib/dkms/wireguard/0.0.20181218/build] Error 2
make: Leaving directory '/usr/src/linux-headers-4.4.167-rockchip64'

[Fourdee]

@MichaIng

Great work on this 👍

I believe we can now mark this as completed?

If interest peaks for additional SBC install support of WG, we can investigate at that time. For now, I believe RPi + x86_64 should cover >60% of our users.

[MichaIng]

@Fourdee
Jep and Odoids C1/C2/XU4 are already enabled as well. Other devices on demand and when we find reliable kernel + header packages.

I am currently writing the dietpi.com docs for WireGuard, so this can be closed.

[MichaIng]

@Fourdee
Online docs done, please review for wording and such: https://dietpi.com/phpbb/viewtopic.php?p=16308#p16308

• The image is made for white background, subtitle has no optimal contrast. However it looks somehow elegant like this 😄.

Will quickly add the link to dietpi-software array: https://github.com/Fourdee/DietPi/pull/2457/commits/42d60da56a72ce487c6b60e51c35b54d1b0c61c8

• NordVPN was missing too 😉.

[1activegeek]

Hey guys, I've been following this for a bit then got sidetracked. Thankfully made a note to check back in. Looks like this went live in 6.20? I'm running 6.21.1 on Rock64 (aarch64) - but I'm not finding this package in the dietpi-software search.

[MichaIng]

@1activegeek
It is not yet enabled for Rock64 since we need to install the kernel headers and build the WireGuard kernel module based on it.

But do a start, could you:

• Check whether kernel headers are already installed: ls -Al /lib/modules/$(uname -r)/
• Check the installed APT packages that might be kernel related: dpkg -l | grep -E '(^linux|rock64)'

[1activegeek]

Ahh, ok. I thought I had understood something I read that it was already supported for Rock64. My bad, I think I confused something. Happy to help if it can lead toward it being supported!!

Command output pasted below. It would seem for some reason, the name -r output does not match the modules path. In any case, let me know what else I may be able to help with. If it's of any use, I may be able to fire up my Pine64 as well.

root@rock64:~# ls -Al /lib/modules/$(uname -r)/
ls: cannot access '/lib/modules/4.4.172-rockchip64/': No such file or directory
root@rock64:~# ls -Al /lib/modules/4.4.174-rockchip64/
total 1344
drwxr-xr-x 10 root root   4096 Feb 18 13:19 kernel
-rw-r--r--  1 root root 405442 Feb 10 04:44 modules.alias
-rw-r--r--  1 root root 426465 Feb 10 04:44 modules.alias.bin
-rw-r--r--  1 root root  23781 Feb 10 04:44 modules.builtin
-rw-r--r--  1 root root  25409 Feb 10 04:44 modules.builtin.bin
-rw-r--r--  1 root root  74250 Feb 10 04:44 modules.dep
-rw-r--r--  1 root root 119335 Feb 10 04:44 modules.dep.bin
-rw-r--r--  1 root root    191 Feb 10 04:44 modules.devname
-rw-r--r--  1 root root  39388 Feb 10 04:44 modules.order
-rw-r--r--  1 root root     55 Feb 10 04:44 modules.softdep
-rw-r--r--  1 root root 101712 Feb 10 04:44 modules.symbols
-rw-r--r--  1 root root 129721 Feb 10 04:44 modules.symbols.bin
root@rock64:~# dpkg -l | grep -E '(^linux|rock64)'
ii  linux-stretch-root-rock64     5.73                              arm64        Armbian tweaks for stretch on rock64 (default branch)
ii  linux-u-boot-rock64-default   5.75                              arm64        Uboot loader 2017.09

[MichaIng]

@1activegeek
Ah your kernel has been updated recently (4.4.172 => 4.4.174) and the new one will be active after reboot.

Kernel headers are not present on your systems, but I found the related header package:
apt install linux-headers-rockchip64

I also found linux-image-rockchip64 for the kernel itself. That is most likely installed on your system and I used the wrong syntax abive to list it. It should have been:
dpkg -l | grep -E '(linux-|rock64)'

If you want to, we could go through the WireGuard install steps now. If it works, we can add it to DietPi-Software.

[1activegeek]

That makes sense, I do remember doing some updates recently but not having restarted since. Perhaps I'll do that tonight/tomorrow just to be fresh.

You are correct, that output provided what I believe is the expected linux-image-rockchip64.

root@rock64# dpkg -l | grep -E '(linux-|rock64)'
ii  linux-base                    4.5                               all          Linux image base package
ii  linux-dtb-rockchip64          5.75                              arm64        Linux DTB, version 4.4.174-rockchip64
ii  linux-image-rockchip64        5.75                              arm64        Linux kernel, version 4.4.174-rockchip64
ii  linux-libc-dev:arm64          4.9.144-3.1                       arm64        Linux support headers for userspace development
ii  linux-stretch-root-rock64     5.73                              arm64        Armbian tweaks for stretch on rock64 (default branch)
ii  linux-u-boot-rock64-default   5.75                              arm64        Uboot loader 2017.09

If you want to drop the steps I can walk through them, sure thing. I'm likely not going to get to doing this though until another day this week. Headed out in the AM to TX for the week.

I'm assuming it should be something along the lines of apt install linux-headers-rockchip64, restart to be sure they've applied, then apt update, and apt install wireguard?

[MichaIng]

@1activegeek
Ah I totally missed that Fourdee already tested it on Rock64 an failed: https://github.com/MichaIng/DietPi/issues/2052#issuecomment-457815683
However meanwhile the ARMbian Rock64 kernel as well as WireGuard had updates, so we could retry.

Steps:

# Install kernel headers
G_AGI linux-headers-rockchip64
# Add Debian Sid repo to APT sources
echo 'deb https://deb.debian.org/debian/ sid main' > /etc/apt/sources.list.d/dietpi-wireguard.list
# Block installs from Sid for all packages besides WireGuard
echo -e 'Package: *\nPin: release n=sid\nPin-Priority: -1\n\nPackage: wireguard wireguard-dkms wireguard-tools\nPin: release n=sid\nPin-Priority: 100' > /etc/apt/preferences.d/dietpi-wireguard
# Update APT lists
G_AGUP
# Install Python as pre-requirement
G_AGI python
# Install WireGuard
apt install wireguard

• As of above the last step might fail. It looks like a general issue when building kernel modules for rock chip since it failed with the Ayufan kernel (further above) as well. I will do some investigation.

---

Notes to self:

• ./scripts/recordmcount: not found: https://stackoverflow.com/questions/13766383/linux-scripts-recordmcount-no-such-file-or-directory
  
  
  
  • Trying make scripts manually?
  
  
  • Obviously from inside the kernel sources themselves: https://github.com/ayufan-rock64/linux-build/issues/252
  
  
• Okay Python is definitely required, since the Rock64 kernel sources contain several py scripts and calls within the Makefiles: https://github.com/ayufan-rock64/linux-kernel
  
  
  
  • (ARMbian uses the same base kernel)
  
  
• Aside that besides some pastebin results that show the same as above nothing to find about how to build a kernel module on Ayufan-based Rock64 kernel at all 🤔.

[1activegeek]

Just following up. I attempted just to see if some packages had actually been built yet that I could install via APT - which I'm sure you expected there are not at this point.

Unfortunately I'm not going to test the kernel level changes just to be sure I don't jack my current running config. Just become inundated with work lately, and can't afford the time right now to backup, run test, then restore - as this system runs my home automation right now. With my luck, something is bound to break. Sorry guys, but I'll stay tuned if there becomes some less risky testing that can be done. 😃

[MichaIng]

@1activegeek

Just following up. I attempted just to see if some packages had actually been built yet that I could install via APT - which I'm sure you expected there are not at this point.

We are installing WireGuard as APT package, as well as Rock64 kernel + headers, or what you mean? The problem is building the kernel module (which is done by the APT package install). Since WireGuard is an in-kernel VPN it requires a kernel module. This is build by the APT package via DKMS, which requires the kernel headers. The kernel headers define how generally kernel modules need to be build, which method, compiler (version) etc. It is basically a set of cascaded scripts/functions with a shared entry API that can be used by the modules make file.

On Rock64 kernel module builds require Python, which is already IMO quite a pain since Python is no usual system core component like C. And the kernel header APT package does not include that as dependency it seems + possible other requirements. E.g. on x86 when installing the kernel headers package, the exact required gcc (GNU C Compiler) version is pulled as dependency: https://packages.debian.org/stretch/linux-headers-4.9.0-8-amd64
So you never need something else to build kernel modules. But yeah on ARM this is usually not that easy, especially on non-RPi...

But aside from that, you can't really break your system, aside that with Python and kernel headers quite some data is installed. But all of it are APT packages, so you can easily remove and when the WireGuard modules fails to build this does not affect the kernel itself. It is a dedicated module and if it fails, WireGuard does not work but all other kernel/modules are not affected.

[1activegeek]

I understand the logic - unfortunately in the past I've had other dependency differences break things. It suddenly decides to use a slightly newer version of something, or something isn't marked properly and it alters to a different build of sorts for an app. I'm just hesitant since I don't have time in case something was to go wrong. Somehow I have the luck that ends with something unexpected when it comes to my Rock64 - thus has been its life since inception in my house. 🙄

If I get more bandwidth, I'll certainly circle back and go through the efforts to backup, test it out, revert or report as needed. I just can't at this time.

[khorsmann]

Hi, i have the same issue with rock64 and wireguard dkms kernel module breaks on build. I follow the instructions from @MichaIng but no luck.
Works wireguard with the "vanilla" install-kernel from the dietpi installation? I would then reinstall dietpi again.

[MichaIng]

@khorsmann
Many thanks for testing and yeah sad that it indeed is still an issue.

We leave the kernel from ARMbian base image untouched which again is based on the official Pine64 Ayufan-maintained kernel. There is no other reliable kernel out there currently, so all have the same issue. First we need to find out/verify how the in general build kernel modules with this kernel (for Rock64), so which libraries (+versions) are required etc and then which possibly additional steps are required to build the WireGuard module in particular. I am not too experienced with DKMS vs non-DKMS but perhaps there is a general issue using DKMS here and the module instead needs to be build manually. Would be a pain indeed, especially since the rebuild needs to be done manually with each kernel upgrade then. Nothing I am keen to ship for now 🤔.

[digitalsanity]

There's a problem with arch/arm/include/ files being excluded from arm64 kernel header deb-pkg builds.

The arch/arm/include from the source needs to be copied to the arch/arm/include of the installed headers in /usr/src/linux-headers-. The required arch/arm64/include/asm/opcodes.h (and likely others) include the arch/arm/include/asm/opcodes.h files, but those are not being packaged with the arm64 kernel builds.

A maintainable patch might be to simply copy the arch/arm/include/asm files over their arch/arm64/include/asm counterparts where the arm64 version is simply an include/redirect.

I have put together a quick build of an older mrfixit2001 kernel that worked properly with my old Silicon Image eSATA card (with port multiplier) whereas new releases didn't -- I am using DKMS/ZFS with that setup. DKMS/ZFS with arm64 userspace is working (need to disable pulseaudio/X or lspci crashes currently in this build) here. Testing armhf userspace build soon. There is also an arm-include.tgz you can try if that's all you need.

https://github.com/digitalsanity/rockchip-kernel/releases/tag/4.4.171-pcie-test

[MichaIng]

@digitalsanity
Since the kernel and header packages vary massively between SBCs and image versions, which SBC(s) and pre-image (respectively kernel/firmware repository) to you refer to?

I see rockchip, but we did not enable WireGuard in dietpi-software for any rockchip-based SBC so far, besides Odroid N1 which was never officially released and AFAIK all both systems we have listed in survey are from me and prior DietPi lead dev, hence no single end user known to run it :wink:.
For all other arm64 Odroids WireGuard install works pretty well with our shipped images, based on Meverics kernel/firmware repositories, e.g.: https://forum.odroid.com/viewtopic.php?f=179&t=35658

Last attempt to get WireGuard DKMS build on Armbian-based images indeed failed, but AFAIK for a very different reason. And they ship mainline Linux 5.4 currently.