Arch Linux User Repository

MANJARO USERS, READ ME

Manjaro does not create the /usr/src/linux symlink, which should point to the current kernel headers and is required for this package to build properly. If you wish to use this package, your options are to:

1. Manually edit the PKGBUILD before building and change the KDIR variable in build() to point to your kernel headers.

2. Create a pacman hook for the kernel header package which creates the symbolic link automatically. An example can be seen in this comment: https://aur.archlinux.org/packages/opensnitch-ebpf-module?O=30#comment-919081

This is the latest RELEASE version of opensnitch's eBPF module. It is meant to be used with the regular opensnitch package, not the -git version in the AUR. If you're using the -git version of opensnitch, you're looking for this version of the eBPF module package instead.

I intend to keep this up to date with the OpenSnitch releases (as soon as the main package updates).

don't take this the wrong way ...

not a problem! i realize i was suggesting a Manjaro specific change, though i didn't know whether the suggestion might be more 'correct' for Arch too

thanks

No, since that would attempt to use the currently running kernel headers and not actually the kernel headers which you have installed. This would make the package fail to build if you've updated your kernel but haven't rebooted yet, so uname still returns the old version.

Also, don't take this the wrong way, but this is the Arch user repository, Manjaro users are not really my concern.

@nns - 'stasadev' suggested the following on the page you linked (which is what i did in the build file)...

-KDIR="/usr/src/linux"
+KDIR="/usr/lib/modules/$(uname -r)/build"

...is doing the uname thing an option?

Yeah, the AUR comment pagination is a bit dumb and the link changes, correct link should be https://aur.archlinux.org/packages/opensnitch-ebpf-module?O=30#comment-919081

DKMS is not an option here - this is an eBPF program and not a kernel module and hence this package does not use DKMS.

@nns - dunno if you want to do this since the issue is Manjaro specific (although perhaps also other Arch derivatives that support multiple kernels), but a commenter in the Manjaro forum said the following...

Technically the maintainer could use dkms and thus avoid the whole debacle on where the headers are.

ref: https://forum.manjaro.org/t/usr-src-symlink/159421/10

@linux-aarhus - i understand, which is why i was interested in the content of the comment that no longer exists apparently (https://aur.archlinux.org/packages/opensnitch-ebpf-module?O=10#comment-919081) so that i could learn how to "2. Create a pacman hook for the kernel header package ..." as mentioned in the opening comment

Manjaro does not create the /usr/src/linux symlink, which should point to the current kernel headers and is required for this package to build properly.

Manjaro has several kernels in the format linuxMajorMinor e.g. linux66 or linux68 and any number of kernels can installed.

To avoid confusion and possible errors when the symlink point to linux68 and booted kernel is linux66 the symlink does not exist.

link is dead...

Create a pacman hook for the kernel header package which creates the symbolic link automatically. An example can be seen in this comment: https://aur.archlinux.org/packages/opensnitch-ebpf-module?O=10#comment-919081

I've just pushed 1.6.5-2 of the ebpf module on the AUR, which is really 1.6.4 in disguise, and should fix most issues with incompatible module/main package versions and the log messages being spammed, until 1.6.5 is actually released and the ebpf module package updated. Most people having issues right now should upgrade the opensnitch-ebpf-module package and it should in theory be fine for the time being.

Right, that makes sense. Since I'm depending on linux-headers anyways, I can modify the PKGBUILD to use that specifically and not the symlink. Although the symlink is by far the easiest method to build against the current kernel headers (especially if the kernel package has been upgraded but the system is still running on an older kernel), I guess it would be possible to use some heuristics to build against the latest headers.