DietPi-Software | WireGuard: Install on Odroids fails due to missing symlinks

Created on 31 May 2020  路  20Comments  路  Source: MichaIng/DietPi

ADMIN EDIT

Workaround (Odroid C2): https://github.com/MichaIng/DietPi/issues/3577#issuecomment-636503473


Creating a bug report/issue

Required Information

  • DietPi version | cat /boot/dietpi/.version

dietpi 6.30

  • Distro version | echo $G_DISTRO_NAME or cat /etc/debian_version

10.4

  • Kernel version | uname -a
    Linux wireguard 3.16.82+ #1 SMP PREEMPT Tue Mar 17 18:33:26 CET 2020 aarch64 GNU/Linux

  • SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)
    ordoid c2

  • Power supply used | (EG: 5V 1A RAVpower)

  • SDcard used | (EG: SanDisk ultra)

Additional Information (if applicable)

  • Software title | (EG: Nextcloud)
    wireguard
  • Was the software title installed freshly or updated/migrated?
    brand new install of dietpi / wirguard

  • Can this issue be replicated on a fresh installation of DietPi?
    yes i think so

  • Bug report ID | echo $G_HW_UUID

Steps to reproduce

  1. install dietpi on odroid c2
  2. install wireguard
  3. attempt to configure / use wireguard
  4. not working

Expected behaviour

wireguard interface should be available
built within linux headers
etc

Actual behaviour

not working. no interface, won't start

Extra details

commands used:

wg-quick up wg0
[#] ip link add wg0 type wireguard
RTNETLINK answers: Operation not supported
Unable to access interface: Protocol not supported
[#] ip link delete dev wg0
Cannot find device "wg0"

modprobe wireguard
modprobe: FATAL: Module wireguard not found in directory /lib/modules/3.16.82+

dpkg-reconfigure wireguard-dkms


Deleting module version: 1.0.20200506

completely from the DKMS tree.

Done.
Loading new wireguard-1.0.20200506 DKMS files...
Building for 3.16.82+
Module build for kernel 3.16.82+ was skipped since the
kernel headers for this kernel does not seem to be installed

External Bug OdroidMeveric Workaround available

All 20 comments

Hi,

many thanks for your report. Looks like you are missing the correct kernel headers to be able to build wireguard completly. pls can you do following to check if the package is available.

uname -r
apt search linux-headers-$(uname -r)

thanks for super quick response.

root@wireguard:~# uname -r
3.16.82+

root@wireguard:~# apt search linux-headers-$(uname -r)
Sorting... Done
Full Text Search... Done
linux-headers-3.16.82+/unknown,now 3.16.82-20200317-C2 arm64 [installed]
Header files related to Linux kernel, specifically

some other commands:
root@wireguard:~# cat /proc/version
Linux version 3.16.82+ (root@odroid-stretch64) (gcc version 6.3.0 20170516 (Debi an 6.3.0-18+deb9u1) ) #1 SMP PREEMPT Tue Mar 17 18:33:26 CET 2020

maybe you can try to reinstall the kernel headers package

apt update
apt reinstall linux-headers-$(uname -r)
dpkg-reconfigure wireguard-dkms

Just FYI; this is a brand new image pulled from dietpi website yesterday for the odroid c2. I think we found the root of the issue below:

root@wireguard:~# apt reinstall linux-headers-$(uname -r)
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 6,980 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://fuzon.co.uk/meveric all/c2 arm64 linux-headers-3.16.82+ arm64 3.16.                                                         82-20200317-C2 [6,980 kB]
Fetched 6,980 kB in 5s (1,374 kB/s)
(Reading database ... 33563 files and directories currently installed.)
Preparing to unpack .../linux-headers-3.16.82+_3.16.82-20200317-C2_arm64.deb ...
Unpacking linux-headers-3.16.82+ (3.16.82-20200317-C2) over (3.16.82-20200317-C2                                                         ) ...
Setting up linux-headers-3.16.82+ (3.16.82-20200317-C2) ...
Examining /etc/kernel/header_postinst.d.
run-parts: executing /etc/kernel/header_postinst.d/dkms 3.16.82+ /boot/vmlinuz-3                                                         .16.82+
Error! echo
Your kernel headers for kernel 3.16.82+ cannot be found at
/lib/modules/3.16.82+/build or /lib/modules/3.16.82+/source
root@wireguard:/lib/modules/3.16.82+# ls -l
total 1380
drwxr-xr-x 8 root root   4096 Mar 19 21:06 kernel
-rw-r--r-- 1 root root 423606 Mar 19 21:07 modules.alias
-rw-r--r-- 1 root root 437371 Mar 19 21:07 modules.alias.bin
-rw-r--r-- 1 root root  15707 Mar 17 17:51 modules.builtin
-rw-r--r-- 1 root root  16812 Mar 19 21:07 modules.builtin.bin
-rw-r--r-- 1 root root  81000 Mar 19 21:07 modules.dep
-rw-r--r-- 1 root root 129241 Mar 19 21:07 modules.dep.bin
-rw-r--r-- 1 root root    209 Mar 19 21:07 modules.devname
-rw-r--r-- 1 root root  41879 Mar 17 17:51 modules.order
-rw-r--r-- 1 root root     55 Mar 19 21:07 modules.softdep
-rw-r--r-- 1 root root 105169 Mar 19 21:07 modules.symbols
-rw-r--r-- 1 root root 132393 Mar 19 21:07 modules.symbols.bin

Hmm probably a problem with the kernel from Meveric. Maybe @MichaIng could have a look.

Probably the configuration scripts are called in wrong order:

  • Headers postinst would place the /lib/modules/3.16.82+/build symlink
  • But /etc/kernel/header_postinst.d/dkms is called first, expecting the symlink already.

Please try the following:

mv /etc/kernel/header_postinst.d/dkms /root/dkms_bak
apt reinstall linux-headers-$(uname -r)
mv /root/dkms_bak /etc/kernel/header_postinst.d/dkms
/etc/kernel/header_postinst.d/dkms
apt -f install

fails at: /etc/kernel/header_postinst.d/dkms

root@wireguard:/lib/modules/3.16.82+# mv /etc/kernel/header_postinst.d/dkms /root/dkms_bak
root@wireguard:/lib/modules/3.16.82+# apt reinstall linux-headers-$(uname -r)
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 6,980 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://fuzon.co.uk/meveric all/c2 arm64 linux-headers-3.16.82+ arm64 3.16.82-20200317-C2 [6,980 kB]
Fetched 6,980 kB in 6s (1,116 kB/s)
(Reading database ... 33563 files and directories currently installed.)
Preparing to unpack .../linux-headers-3.16.82+_3.16.82-20200317-C2_arm64.deb ...
Unpacking linux-headers-3.16.82+ (3.16.82-20200317-C2) over (3.16.82-20200317-C2) ...
Setting up linux-headers-3.16.82+ (3.16.82-20200317-C2) ...
Examining /etc/kernel/header_postinst.d.
root@wireguard:/lib/modules/3.16.82+# mv /root/dkms_bak /etc/kernel/header_postinst.d/dkms
root@wireguard:/lib/modules/3.16.82+# /etc/kernel/header_postinst.d/dkms
Error! echo
Your kernel headers for kernel 3.16.82+ cannot be found at
/lib/modules/3.16.82+/build or /lib/modules/3.16.82+/source.

Okay no idea, somehow the package does not create those symlinks then. I checked the postinst scripts and it is no shell script so I do not fully understand it. It defines two variables that from name and comment should check the symlinks, but within the script those variables are not called anymore, not sure if there is some external trigger in dpkg or what... However let's create one manually :):

ln -s /usr/src/linux-headers-3.16.82+ /lib/modules/3.16.82+/build
/etc/kernel/header_postinst.d/dkms
apt -f install

Just replicated on Odroid C4: Installing linux-headers-arm64-odroid-c4 as well there does not create the symlink. I'll see if Meveric can add this quickly, else we'll do this as workaround for DietPi v6.31.

Hey guys - thanks for the quick support. I've confirmed work around is working for wireguard now.

root@wireguard:~# wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.9.0.1/24 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] sysctl net.ipv4.conf.wg0.forwarding=1 net.ipv4.conf.$(mawk 'NR==3' /run/dietpi/.network).forwarding=1
net.ipv4.conf.wg0.forwarding = 1
net.ipv4.conf.eth0.forwarding = 1
[#] sysctl net.ipv6.conf.$(mawk 'NR==3' /run/dietpi/.network).accept_ra=2
net.ipv6.conf.eth0.accept_ra = 2
[#] sysctl net.ipv6.conf.wg0.forwarding=1 net.ipv6.conf.$(mawk 'NR==3' /run/dietpi/.network).forwarding=1
net.ipv6.conf.wg0.forwarding = 1
net.ipv6.conf.eth0.forwarding = 1
[#] iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o $(mawk 'NR==3' /run/dietpi/.network) -j MASQUERADE
[#] ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -A POSTROUTING -o $(mawk 'NR==3' /run/dietpi/.network) -j MASQUERADE
root@wireguard:~# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 00:1e:06:33:6a:7f brd ff:ff:ff:ff:ff:ff
3: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default
    link/none

Great, I'll keep the issue open until there is either an upstream solution (all Odroids are affected) or we implemented a workaround. Or we simply missed something our side 馃槃, I already informed Meveric.

the build symlink is created by the linux-image package NOT by the linux-header package.
The linux-image package checks if the linux-headers are installed and if so it creates the build symlink.
So installing the header later on does not create the symlink, but you can always trigger a:
apt install --reinstall linux-image-$(uname -r) to create the symlink afterwards.

btw there's a second dkms postinst script located under: /etc/kernel/postinst.d/dkms
which is triggered when a new linux-image is installed, and it's triggered AFTER the build symlink was created :)

Ah great to know you're on GitHub as well and thanks for the info. Wouldn't it be good if the headers package as well checked for a matching installed kernel and create the symlink then? At least I guess it is not uncommon to install headers later to build a module, and currently this will always fail. So for postinst scripts (before running /etc/kernel/postinst) in shell this would be:
Kernel

[ -d /usr/src/linux-headers-$version ] && [ ! -e /lib/modules/$version/build ] && ln -sf /usr/src/linux-headers-$version /lib/modules/$version/build

Headers

[ -d /lib/modules/$version ] && [ ! -e /lib/modules/$version/build ] && ln -sf /usr/src/linux-headers-$version /lib/modules/$version/build

These are the official Kernel and Header packages build by debian build systems.
I don't want to change the automated scripts that are created during the build process.

The scripts are actually quite long, and it's probably easy to make mistakes here, which makes it hard to automate a change on these scripts to include something like this.
But I'll see if I can find something about this, as headers should also be able to create the build link in my opinion.

Edit:
I checked other linux-header packages and they include a symlink inside the header package directly. So it should be "created" when the headers are extracted.
This link is missing on the 3.16 Kernel for C2 (while it was present on the 3.14 headers).
As well as on the C4 headers.
I will try to investigate why these are missing on these particular header files, and not on others.

I checked other linux-header packages and they include a symlink inside the header package directly. So it should be "created" when the headers are extracted.
This link is missing on the 3.16 Kernel for C2 (while it was present on the 3.14 headers).
As well as on the C4 headers.
I will try to investigate why these are missing on these particular header files, and not on others.

Nice find! Totally makes sense, to ship the links as part of the archive instead of creating them via postinst, since the headers belong to a fixed kernel package (hence modules path) anyway.

I know it's slightly off topic, but I fixed the packages for ODROID C4.
Instead of the debian kernel build system I now use the build system that comes directly with the Kernel, had to adjust some of my build scripts but apparently it worked fine.

Since there weren't any commits for the C2 lately I haven't tried building a new Kernel for that, but if HK doesn't update the Kernel soon, I will try to rebuild the current Kernel with the new build system and see if I can fix C2 Kernel as well that way.

Great many thanks! No worries about the symlinks from our side, I'll implement a workaround (create them manually) with next DietPi release in case.

@meveric
I can confirm it works on C4 and I think the following postinst step is the issue on C2 (+N1+N2):

Setting up linux-image-3.16.82+ (3.16.82-20200317-C2) ...

 Hmm. There is a symbolic link /lib/modules/3.16.82+/build
 However, I can not read it: No such file or directory
 Therefore, I am deleting /lib/modules/3.16.82+/build


 Hmm. The package shipped with a symbolic link /lib/modules/3.16.82+/source
 However, I can not read the target: No such file or directory
 Therefore, I am deleting /lib/modules/3.16.82+/source

In /var/lib/dpkg/info/linux-image-3.16.82+.postinst:

######################################################################
## Fix the build link
######################################################################
...
    # Determine what the real file name is, and test that for existence
    $real_target = abs_path($build_target) if defined($build_target);
    if ( !defined($build_target) || !-d "$real_target" ) {    # Danglink link
      warn qq(
 Hmm. There is a symbolic link $modules_base/$version/build
 However, I can not read it: $!
 Therefore, I am deleting $modules_base/$version/build\n
);
      my $num = unlink "$modules_base/$version/build";
...
######################################################################
## Fix the source link
######################################################################
...
    # Determine what the real file name is, and test that for existence
    $real_target = abs_path($source_target) if defined($source_target);
    if ( !defined($source_target) || !-d "$real_target" ) {    # Danglink link
      warn qq(
 Hmm. The package shipped with a symbolic link $modules_base/$version/source
 However, I can not read the target: $!
 Therefore, I am deleting $modules_base/$version/source\n
);
      my $num = unlink "$modules_base/$version/source";
...

The two links are shipped with the package but they are removed if headers are not installed already. So practically the headers need to be installed first, the kernel afterwards, otherwise one is left without links. If the kernel ships the symlinks but removes them as postinst step when no headers are available, which somehow makes sense, then the header package needs to create them, if the matching kernel is found. Probably something that can be suggested for all Hardkernel kernels if they share the same scripts in general.


On Odroid XU4 /lib/modules/4.14.180+/build is shipped with the headers package btw, so no issue there.

Kernel 4.14 also uses the newer build system I was referring to, so it's part of the header package.
My next Kernels will all use the new build system but I need to adjust and test my build and postinst scripts first.

C4 and XU4 prove the system works, I just need to adjust accordingly.
The C4 also comes with additional linux-firmware-image package which I need to consider for other platforms as well to not miss important drivers, like firmware for VPU and things of that nature.

I also want to make sure that an update works from the old build system Kernel and Header files to the new ones without breaking anything.

Workaround is implemented with: #3620
Quick check for new build system: http://fuzon.co.uk/meveric/pool/c4/l/

  • If linux-<version>/ contains the current headers, the new build system is in plaec
  • If linux-source-<version>/ contains the current headers, the old one is (which requires the workaround)

Missing on:

Final test:

Setting up linux-image-4.9.219+ (4.9.219-20200414-N2) ...

 Hmm. There is a symbolic link /lib/modules/4.9.219+/build
 However, I can not read it: No such file or directory
 Therefore, I am deleting /lib/modules/4.9.219+/build


 Hmm. The package shipped with a symbolic link /lib/modules/4.9.219+/source
 However, I can not read the target: No such file or directory
 Therefore, I am deleting /lib/modules/4.9.219+/source
...
[ INFO ] DietPi-Software | APT install for: linux-image-arm64-odroid-n2 linux-headers-arm64-odroid-n2, please wait...
Selecting previously unselected package linux-headers-4.9.219+.
(Reading database ... 20543 files and directories currently installed.)
Preparing to unpack .../linux-headers-4.9.219+_4.9.219-20200414-N2_arm64.deb ...
Unpacking linux-headers-4.9.219+ (4.9.219-20200414-N2) ...
Selecting previously unselected package linux-headers-arm64-odroid-n2.
Preparing to unpack .../linux-headers-arm64-odroid-n2_4.9.219-1_arm64.deb ...
Unpacking linux-headers-arm64-odroid-n2 (4.9.219-1) ...
Selecting previously unselected package linux-image-arm64-odroid-n2.
Preparing to unpack .../linux-image-arm64-odroid-n2_4.9.219-1_arm64.deb ...
Unpacking linux-image-arm64-odroid-n2 (4.9.219-1) ...
Setting up linux-image-arm64-odroid-n2 (4.9.219-1) ...
Setting up linux-headers-4.9.219+ (4.9.219-20200414-N2) ...
Examining /etc/kernel/header_postinst.d.
Setting up linux-headers-arm64-odroid-n2 (4.9.219-1) ...
[  OK  ] DietPi-Software | APT install for: linux-image-arm64-odroid-n2 linux-headers-arm64-odroid-n2
# ------- Here we create the symlink manually ----------
'/lib/modules/4.9.219+/build' -> '/usr/src/linux-headers-4.9.219+'
[ INFO ] DietPi-Software | APT install for: wireguard-dkms wireguard-tools iptables qrencode, please wait...
...
Building initial module for 4.9.219+
Done.

wireguard.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/4.9.219+/kernel/net/

depmod...

DKMS: install completed.

馃埊 馃憤

Was this page helpful?
0 / 5 - 0 ratings