/usr/src symlink

[majik]

curious as to why Manjaro deviates from Arch regarding the /usr/src kernel symlink where a kernel version is added (linuxNN)

this can cause issues when installing a package or updating the kernel when a package depends on that symlink

AUR (en) - opensnitch-ebpf-module

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.

[soundofthunder]

I suspect there is a specific reason for this; in fact, it triggered a memory of a thread that mentioned it sometime recently. I don’t recall the specifics.

If it’s packaging-related @Yochanan might have an idea.

[Teo]

Well, manjaro is not entirely arch. AUR is unsupported, so such problems are not really problems.
That said, there are symlinks there, they are just with kernel numbers. And you can always make another symlink yourself, if that is critical for you.

[Nachlese]

Arch has/supports only one default linux kernel version at any one time - Manjaro has several to choose from.

[majik]

ah, that makes sense!

is there perhaps a work-a-round to avoid having to edit a PKGBUILD file that depends on the /usr/src/linux symlink?

[soundofthunder]

@majik

is there perhaps a work-a-round to avoid having to edit a PKGBUILD file that depends on the /usr/src/linux symlink?

Apart from creating the symlink manually, your best resolve is probably contacting the AUR maintainer of the package.

[linux-aarhus]

https://aur.archlinux.org/packages/opensnitch-ebpf-module?O=0#comment-965841

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.

[majik]

@soundofthunder

Apart from creating the symlink manually, your best resolve is probably contacting the AUR maintainer of the package.

creating the link would result in the problem i was attempting to solve in that the link would point to the wrong kernel version after a different version was installed

i’m guessing the link would have to be created by a script at log-on in order to automate the process, which is certainly doable, but i wanted to ask what the options are first

[linux-aarhus]

The pinned topic has the solution

build() {
	cd "${srcdir}/${_pkgname}-${_pkgver}/ebpf_prog"
	KDIR="/usr/src/linux"

This is one of the reasons why using AUR on Manjaro is frowned upon.

It requires knowledge to workaround such issues.

Change KDIR to active kernel - e.g. linux68 - also be sure to have the headers installed for that kernel - which is not default.

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

[majik]

thanks

i did: KDIR="/usr/lib/modules/$(uname -r)/build"

[majik]

@linux-aarhus

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

i overlooked that - thanks for the advice! i’ll inform them

[heyjo]

@majik

i did: KDIR="/usr/lib/modules/$(uname -r)/build"

This create a symlink to a kernel headers package that you you need to install, e.g.
linux68-headers if your current running kernel is linux68.
The /build subfolder is only created after you installed the kernel header package.

[majik]

yep, i’m aware of the kernel headers

i think what i’ll do instead though, until (if) the package maintainer uses a different method, is dump the header package, use the linuxNN in the build file and check that the symlink matches the running kernel with a log-on script (which will remind me to update the package build script in question on the next kernel update)