eq3_char_loop: Exec format error

[gunterc]

Ich versuche RaspberryMatic in einem Container auf einem x86 Rechner zu installieren. Ich folge hierbei der Anleitung auf
"https://github.com/jens-maus/RaspberryM ... Docker-OCI".
Mein System ist

Code: Alles auswählen

g1905:~$ uname -a
Linux g1905 5.13.0-35-generic #40~20.04.1-Ubuntu SMP Mon Mar 7 09:18:32 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

und ich will einen HmIP-RFUSB verwenden.
Beim Installieren von eq3_char_loop erhalte ich eine Fehlermeldung:

Code: Alles auswählen

g1905:~$ sudo modprobe eq3_char_loop
modprobe: ERROR: could not insert 'eq3_char_loop': Exec format error

Am Rande sei bemerkt, dass ich das Ganze schon mal auf einem anderen System in einer VM gemacht habe. Also eine rudimentäre VM angelegt, den Stick durchgereicht und dann in der VM die Container-Installation durchgeführt. Hier kam diese Fehlermeldung nicht.
(So ganz richtig hat das zwar alles auch nicht funktioniert, aber das ist/wäre ein anderes Kapitel ..... )

Hat hier jemand eine Idee, was ich hier falsch gemacht haben kann?

[jmaus]

Welches Betriebssystem verwendest du denn als Host-OS für dein Docker?

[gunterc]

Ubuntu 20.04, 64-bit.

[deimos]

Hi,

der Fehler kommt u.A., wenn Secure Boot aktiviert ist und Kernel Module nicht signiert sind.

Viele Grüße
Alex

[jmaus]

der Fehler kommt u.A., wenn Secure Boot aktiviert ist und Kernel Module nicht signiert sind.

Interessanterweise bin ich in der GitHub CI Umgebung auf das gleiche Problem vor ein paar Tagen gestoßen. Siehe:

https://github.com/jens-maus/RaspberryM ... tep:14:308

Dort wurde bei GitHub anscheinend von Kernel 5.11 auf 5.13 geupdatet in deren Azure-Environment. Ich konnte diesbzgl. zwar ein Workaround einbauen, aber denkst du das du in den debian paketen die von deinem debian repository dort verteilt werden irgendetwas umbauen kannst das auch in diesem Fall man diese verwenden kann?

[deimos]

Hi,

da kann ich nichts machen, siehe die Zeilen https://github.com/jens-maus/RaspberryM ... tep:14:174
DKMS versucht einen Signing Key zu erstellen und scheitert.

Viele Grüße
Alex

[jmaus]

da kann ich nichts machen, siehe die Zeilen https://github.com/jens-maus/RaspberryM ... tep:14:174
DKMS versucht einen Signing Key zu erstellen und scheitert.

Ok, verstehe. Aber was ist in den Fällen die jetzt anscheinend immer mehr von Nutzerseite aufploppen? Hab mich selber mit diesem kernel module signing noch nicht beschäftigt, aber gibt es da keine Möglichkeit das man das irgendwie hinbekommt das das auf den neueren Systemen mit ModuleSigning das dann auch out-of-the-box wieder funktioniert?

[deimos]

Hi,

zumindest bei aktuellen Ubuntu und Debian Versionen funktioniert das bei meinen Tests bereits Out-Of-The-Box bei Bare Metall Systemen. Teilweise gibt es Probleme bei Ubuntu, wenn Secure Boot nicht aktiviert ist, aber EFI zum Booten genutzt wird und das Header Paket nicht per APT aktualisiert bzw. noch einmal reinstalliert wird, weil das Module Signging im Rahmen des Installers aktiv ist, aber später im echten System dann nicht.

Viele Grüße
Alex

[gunterc]

Also das mit dem Kernel scheint (selbstverständlich ) das Problem zu sein. In meiner VM hatte ich den Kernel 5.11.0-44-generic und da ging es, und in meinem gewünschten Zielsystem 5.13.0-35-generic und da geht es nicht.

Nun habe ich einfach plump das probiert, was deimos vorgeschlagen hat:

Code: Alles auswählen

sudo apt reinstall linux-headers-5.13.0-35-generic
sudo apt reinstall pivccu-modules-dkms
sudo service pivccu-dkms start
sudo modprobe eq3_char_loop

... und da kommt immerhin schon mal keine Fehlermeldung mehr.

Ob der Container nun funktioniert, kann ich noch nicht sagen. Aber das zeigt sich gleich...

[gunterc]

OK. Also das scheint jetzt zu funktionieren. Ich habe zwar gelegentlich Probleme mit der Verbindung der 'ccu' mit Modulen, aber hier fehlt mir einfach noch die Testtiefe. Aktuell 'spiele' ich mit zwei Modulen.

Ich habe auch noch mal diverse Versuche der Installation vom Container in einer VM unternommen, weil man die so schön schnell wieder in einen definierten Zustand setzen kann. Mir ist überhaupt nicht klar, was hier mit den Headerdateien abgeht. Warum man die ein zweites Mal installieren muss. Schließlich werden die bei einem 'distupgrade' ja auch schon geladen und sollten somit zur Verfügung stehen, wenn der korrespondierende Kernel verwendet wird. - Aber ich gebe zu, dass ich durch diese Detaills dann doch nicht durchblicke.

Wie auch immer: Das ist schon super, dass die ccu auf derart unterschiedlichen Systemen läuft!