Solved Insecure kernel module load attempt rejected: /boot/kernel/lindebugfs.ko

youngunix

youngunix

Hello,

I just acquired a laptop, installed FreeBSD 14.1-STABLE and trying to get Xorg to work.

I will be using lightDM & icewm but the issue is that the module i915kms.ko will not load due to the following error(s):

Code: 
Insecure kernel module load attempt rejected: /boot/kernel/lindebugfs.ko
[224]  -> p_comm: kldload pid: 12790 ppid: 99185 p_pax: 0x58655<PAGEEXEC,MPROTECT,SEGVGUARD,ASLR,NOSHLIBRANDOM,DISALLOWMAP32BIT,<f15>,<f16>,<f18>>
[224] KLD drm.ko: depends on lindebugfs - not available or version mismatch
[224] iic0: detached
[224] iicbus0: <unknown card> at addr 0
[224] iic1: detached
[224] iicbus1: <unknown card> at addr 0
[224] KLD i915kms.ko: depends on drmn - not available or version mismatch
[495] iic0: <I2C generic I/O> on iicbus0

Suspect line:
Code: 
[224]  -> p_comm: kldload pid: 12790 ppid: 99185 p_pax: 0x58655<PAGEEXEC,MPROTECT,SEGVGUARD,ASLR,NOSHLIBRANDOM,DISALLOWMAP32BIT,<f15>,<f16>,<f18>>

Laptop specs according to fastfetch:

Code: 
Host: Precision 5510
Kernel: FreeBSD 14.1-STABLE
Packages: 431 (pkg)
Shell: zsh 5.9
Display: 1920x1080
Terminal: xterm-256color
CPU: Intel(R) Core(TM) i7-6820HQ (4) @ 2.70 GHz
GPU 1: Intel Device 191B (VGA compatible)
GPU 2: NVIDIA Device 13B1 (3D)
Memory: 904.92 MiB / 15.82 GiB (6%)
Swap: Disabled
Disk (/): 3.22 GiB / 449.61 GiB (1%) - zfs
Disk (/zroot): 96.00 KiB / 446.40 GiB (0%) - zfs

I spent the last couple of days trying to figure out how to solve the insecure module error to no avail.
 
youngunix said:
installed FreeBSD 14.1-STABLE
Click to expand...
Be advised, STABLE is a development and testing branch, not intended for production environments, including home user environments. System maintenance requires the ability to update/upgrade from source code.

youngunix said:
Code: 
 [224] KLD drm.ko: depends on lindebugfs - not available or version mismatch

 [224] KLD i915kms.ko: depends on drmn - not available or version mismatch
Click to expand...
There is a version mismatch between 14.1 kernel version and drm, i915kms modules. I bet you installed the driver from package.

drm-kmod pre-built packages (providing kernel modules as drm and i915kms) are incompatible with 14.1 kernel for the time being.

Background: Kernel modules require to be build against the running kernel version. Official pre-built packages for a branch are built for the least supported version of a branch, in this case for 14.0, until end-of-live of 14.0 (which is expected to be September 30, 2024).

For now the video driver for 14.1 needs to be build from ports, with 14.1-STABLE source code installed, but I see there are two GPUs on your system, and the Nvidia is Optimus.

I'm not sure how Optimus is handled on FreeBSD. Can you disable one of the GPUs?
 
T-Daemon said:
Be advised, STABLE is a development and testing branch, not intended for production environments, including home user environments. System maintenance requires the ability to update/upgrade from source code.


There is a version mismatch between 14.1 kernel version and drm, i915kms modules. I bet you installed the driver from package.

drm-kmod pre-built packages (providing kernel modules as drm and i915kms) are incompatible with 14.1 kernel for the time being.

Background: Kernel modules require to be build against the running kernel version. Official pre-built packages for a branch are built for the least supported version of a branch, in this case for 14.0, until end-of-live of 14.0 (which is expected to be September 30, 2024).

For now the video driver for 14.1 needs to be build from ports, with 14.1-STABLE source code installed, but I see there are two GPUs on your system, and the Nvidia is Optimus.

I'm not sure how Optimus is handled on FreeBSD. Can you disable one of the GPUs?
Click to expand...
I use STABLE for tinkering & testing purposes.

You are correct, the kernel was supposed to be 14.0 not 14.1. Not sure what I did or what was done for it to end up mismatched.

I was wondering about the NVIDIA GPU as well. It is not listed on the BIOS for me to disable it. I'm going to look for BIOS updates and see if that fixes it.

However, before I read your reply, I got impatient and decided to skip all the manual labor by installing GhostBSD. It definitely got better than the last time I tried it. Right now, I'm trying to figure out a way to control the brightness either via xbacklight, xbrightness, keyboard, or anything else for that matter. The brightness is stuck at max and I keep getting a headache staring at this thing.
 
youngunix said:
anything
Click to expand...

Gammy

1720325669800.png
 
youngunix said:
I'm trying to figure out a way to control the brightness either via xbacklight, xbrightness, keyboard, or anything else for that matter.
Click to expand...
Assuming the i915km driver is loaded, see if there is a backlight(8) device created.

On my system (ThinkPad laptop), to control backlight brightness, the video driver (amdgpu in my case) must be loaded.
Code: 
% ls -l /dev/backlight/*
lrwxr-xr-x  1 root wheel    23 Jul  5 18:06 /dev/backlight/amdgpu_bl00 -> ../backlight/backlight0
crw-rw----  1 root video 0x19c Jul  5 18:06 /dev/backlight/backlight0

I also need to load the acpi_ibm(4) driver for hotkey support (Fn + function key backlight, sound).

In your case, there is no special module for Dell, try acpi_video(4) instead for backlight brightness..

See also in BIOS if there is a setting for hotkeys to enable and disable.

I also use accessibility/gammy (set to start automatic on starting Xorg) . It can adapt the brightness and temperature after time of day automatically, or manually.
 
Cath O'Deray said:
No longer true. pkgbase negates the requirement.
Click to expand...
I wouldn't recommend pkgbase in good conscious to a novice user for the time being. The major obstacle are the /etc/*.pkgsave system configuration files and scripts, which require manual intervention.

Easy for a layman to break things there making a mistake and not knowing how to correct (this is also true for novice source maintained STABLE and CURRENT users).

pkgbase packages are also offered for those two development branches. Not sure for what reason wants a CURRENT user maintain the system by packages (referring here especially to developers).

There happens back and forth commit installations, how would that work to rollback the system for bisecting a commit for example. Same on STABLE.

At last, according to the wiki page, "Although packages are official: use of pkgbase remains somewhat experimental". That assessment hasn't change currently, giving the fact pkgbase is not advertised in FreeBSD news or announce mailing list.
 
T-Daemon said:
… novice … /etc/*.pkgsave …
Click to expand...

Attention to four files alone, for a novice.

In the seven months since packages became official, I have quietly ramped up testing.

pkgbase simplifies things. For someone who (backs things up appropriately and) tinkers or tests, without requiring things such as customisation of kernels, pkgbase can be ideal.

youngunix said:
I use STABLE for tinkering & testing purposes. …
Click to expand...

:)

T-Daemon said:
… Easy for a layman to break things …
Click to expand...

The same is true for freebsd-update with its various bugs and limitations.
 
I am far from a novice and I have been using FreeBSD since version 6. I've done all of this multiple times to the point I don't feel like dealing with them anymore and just want to tackle more complex challenges.

I'm not making excuses but facts cannot be avoided; 1) Due to some health issues that involve regular injections, I've found myself needing to be cautious about how much I use my hands, especially with activities like typing on a keyboard and using a mouse. This is to prevent further injury. That's why I didn't have as much time as I'd like to search for answers. 2) It became a bit dull making the sausage, so I want to get an already made one and spend the saved time making a variety of dishes with it ;). 3) I wanted the DE/WM to be ready so I don't have to use two PCs, one for browsing and the other for tinkering.

Disclaimer: the comment below is an observation only. It is not intended as a cheap shot or a negative view of FreeBSD.

OpenBSD appears to offer a simpler setup process compared to FreeBSD, particularly regarding desktop environments/window managers and audio configurations. However, FreeBSD excels in providing functionalities in a straightforward manner. Both systems serve distinct purposes in my usage.

GhostBSD stands out as an accessible entry point for newcomers to FreeBSD, mitigating the intimidation factor associated with FreeBSD. It seems to emulate the ease of use akin to Linux Mint, focusing on a "just install and use" approach.

Anyway, thank you gentlemen for your help and patience.
 
This wouldn't happen if ports (and only those) that contain kmods were built on the official poudriere infrastructure for all kernel versions supported. A simple way I can see this supported is by having a second repository especially and only for kernel modules:
Code: 
           FreeBSD-kmod: {
               url: "pkg+https://pkg.freebsd.org/${OSNAME}:${VERSION_MAJOR}.${VERSION_MINOR}:${ARCH}/latest",
               enabled: true,
               signature_type: "fingerprints",
               fingerprints: "/usr/share/keys/pkg",
               mirror_type: "srv",
               priority: 128 # higher prio than the FreeBSD repo
           }

Feel free to give me your input and if you think it's a good idea, try to get some of the devs or foundation members to give their own input.
 
malavon said:
This wouldn't happen if ports (and only those) that contain kmods were built on the official poudriere infrastructure for all kernel versions supported. A simple way I can see this supported is by having a second repository especially and only for kernel modules:
Code: 
           FreeBSD-kmod: {
               url: "pkg+https://pkg.freebsd.org/${OSNAME}:${VERSION_MAJOR}.${VERSION_MINOR}:${ARCH}/latest",
               enabled: true,
               signature_type: "fingerprints",
               fingerprints: "/usr/share/keys/pkg",
               mirror_type: "srv",
               priority: 128 # higher prio than the FreeBSD repo
           }

Feel free to give me your input and if you think it's a good idea, try to get some of the devs or foundation members to give their own input.
Click to expand...
That's probably what happened because I used HardenedBSD. Based on the devs' description of the project, it is as FreeBSD as it gets with a little bit of salt and spices on top. I did not review their code base to see what extra code/configs they've added, modified, or removed. The same goes for GhostBSD, they have their own addons (if I may call them that) on top of pure FreeBSD. However, both forks have their own repositories that host their homebrewed utilities in addition to FreeBSD's pkg/ports repos. I'm trying to make them work in unison but there is a lack of documentation and/or clarity on how things are done. Nonetheless, challenges is why I'm using them and they do not disappoint.
 
youngunix said:
… repositories … in unison …
Click to expand...

For combined use of a GhostBSD repo with the (misleadingly-named) FreeBSD repo: pkg should take of things. Pay attention to output from commands.

The usual: boot environment before any upgrade.

In a nutshell:
  1. use bectl to create and then mount an environment
  2. use option -r for pkg to upgrade the environment
  3. use bectl to unmount and then temporarily activate the environment
  4. restart the OS.
If the environment is good: make the activation non-temporary.

If not good: restart the OS.
 
You must log in or register to reply here.
Back
Top