modprobe eq3_char_loop fails on x64 ubuntu >= 21.10
Closed this issue · 4 comments
Hi,
i use a HB-RF-ETH, connected to raspberrymatic running via docker in a ubuntu vm on x64 hardware. pivccu-modules-dkms is installed like described in jens-maus/RaspberryMatic/wiki/Installation-Docker-OCI#debianubuntu-based-host-system, where pivccu is installed in the ubuntu vm and the raspberrymatic docker container is configured to have access to pivccu. Since i'm using the HB-RF-ETH i used ubuntu 21.04, which is now deprecated so i switched to ubuntu 21.10 and found out it doesn't work.
Running sudo modprobe eq3_char_loop shows modprobe: ERROR: could not insert 'eq3_char_loop': Exec format error and dmesg only shows module: x86/modules: Skipping invalid relocation target, existing value is nonzero for type 1, loc 0000000062f40c16, val ffffffffc09dd8d3.
I'm using ubuntu cloud-images and both ubuntu 21.10 (impish) and the pre-release 22.04 (jammy) show the same error message, when i switch to ubuntu 20.04 (focal, the last LTS) the modprobe eq3_char_loop works just fine. Installation of pivccu-modules-dkms was done through the same ansible script on all 3 ubuntu versions, so it was installed exactly the same way. I even compiled pivccu myself, but modprobe shows the same error.
Could you please help me resolve that issue?
Also i'm confused, because in your README.md you state "x64 is not supported", but clearly it worked under x64 with ubuntu 21.04 and older.
PS: i speak german in case it's easier for you to answer in german, but i usually write in english on github so everyone can read it
piVCCU is not supported on x64, the kernel modules are just a part of it, which run on x64.
I assume, you have secure boot enabled, which requires special signing of kernel modules, which is not implemented in my packages. For the time being, just disable secure boot as workaround.
Ok, but i'm pretty sure secure boot isn't active. The VM runs inside proxmox with the default SeaBIOS which afaik is a plain old BIOS, no modern UEFI, and therefore has no EFI keys, so it can't have secure boot.
Running mokutil shows the following output:
charlie@docker-test:~$ sudo mokutil --sb-state
EFI variables are not supported on this system
charlie@docker-test:~$ sudo mokutil --disable-validation
EFI variables are not supported on this system
charlie@docker-test:~$ sudo mokutil --enable-validation
EFI variables are not supported on this system
Just to prove that i even switched the VM to use the OVMF (UEFI) bios and added an EFI disk.
Then mokutil --sb-state shows SecureBoot enabled and
sudo modprobe eq3_char_loop shows modprobe: ERROR: could not insert 'eq3_char_loop': Operation not permitted and
dmesg shows Lockdown: modprobe: unsigned module loading is restricted; see man kernel_lockdown.7.
So it must be something else, not secure boot.
Here's some system info:
charlie@docker-test:~$ uname -a
Linux docker-test 5.13.0-30-generic #33-Ubuntu SMP Fri Feb 4 17:03:31 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
charlie@docker-test:~$ cat /etc/os-release
PRETTY_NAME="Ubuntu 21.10"
NAME="Ubuntu"
VERSION_ID="21.10"
VERSION="21.10 (Impish Indri)"
VERSION_CODENAME=impish
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=impish
I could reproduce the issue using a fresh installed VM with Ubuntu 21.10.
I got the "exec format error" using the eq3_char_loop module, but I got the same error using the official Ubuntu r8168-dkms package, too.
After reinstalling the kernel headers using the command sudo apt install --reinstall linux-headers-$(uname -r) and rebuilding the kernel using sudo dpkg-reconfigure pivccu-modules-dkms the error was gone and I could load the kernel modules wirhout any error. It seems, that the module signature verification will be enabled somewhere in the kernel headers while they are installed using the Ubuntu installer even if Secure Boot is not supported on the machine and installing/updating the kernel headers outside the installer will reflect the system status for the setting.
Thank you very much, it works now.