Ich blicke nicht so ganz wo genau jetzt das Problem ist, baue aber gerne einen Patch ein
Der vtuner Kernel-Treiber lässt sich z.B. unter Ubuntu 22.04.4 einfach nicht ohne Änderungen z.B. bei /scripts/Makefile.build ...der Quellen vom Kernel erstellen.
Siehe den Lösungsansatz hier
Man könnte es mal mit make -d versuchen.
Vielleicht bekommt man dann ja eine Fehlermeldung, mit der man was anfangen kann.
Man könnte es mal mit make -d versuchen.
Vielleicht bekommt man dann ja eine Fehlermeldung, mit der man was anfangen kann.
Danke für die Unterstützung. -- hier die Ausgabe ohne Quellenänderung der Headers
root@BM2LTS-DD:/usr/src/vtuner-ng/kernel# make -d
GNU Make 4.3
Gebaut für x86_64-pc-linux-gnu
Copyright (C) 1988-2020 Free Software Foundation, Inc.
Lizenz GPLv3+: GNU GPL Version 3 oder später <http://gnu.org/licenses/gpl.html>
Dies ist freie Software: Sie können sie nach Belieben ändern und weiter verteilen.
Soweit es die Gesetze erlauben gibt es KEINE GARANTIE.
make-Steuerdateien werden gelesen …
„make“-Steuerdatei „Makefile“ wird gelesen...
make-Steuerdateien werden aktualisiert …
Betrachte Ziel-Datei „Makefile“.
Es wird nach einer impliziten Regel für „Makefile“ gesucht.
Muster-Regel mit Wurzel „Makefile“ wird probiert.
Implizite Voraussetzung „Makefile.o“ wird ausprobiert.
Muster-Regel mit Wurzel „Makefile“ wird probiert.
Implizite Voraussetzung „Makefile.c“ wird ausprobiert.
Muster-Regel mit Wurzel „Makefile“ wird probiert.
Implizite Voraussetzung „Makefile.cc“ wird ausprobiert.
Muster-Regel mit Wurzel „Makefile“ wird probiert.
Implizite Voraussetzung „Makefile.C“ wird ausprobiert.
Muster-Regel mit Wurzel „Makefile“ wird probiert.
Implizite Voraussetzung „Makefile.cpp“ wird ausprobiert.
Muster-Regel mit Wurzel „Makefile“ wird probiert.
...
./tools/objtool/objtool: /usr/local/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by ./tools/objtool/objtool)
Sammle erfolglosen Kindprozess 0x56c4c88ebd70 PID 4350
make[3]: *** [scripts/Makefile.build:244: /usr/src/vtuner-ng/kernel/vtunerc_main.o] Fehler 1
make[3]: *** Datei „/usr/src/vtuner-ng/kernel/vtunerc_main.o“ wird gelöscht
Entferne Kindprozess 0x56c4c88ebd70 PID 4350 aus der Kette.
Sammle erfolglosen Kindprozess 0x55dbe3b01880 PID 4341
make[2]: *** [/usr/src/linux-headers-6.9.1-x64v4-xanmod1/Makefile:2071: /usr/src/vtuner-ng/kernel] Fehler 2
Entferne Kindprozess 0x55dbe3b01880 PID 4341 aus der Kette.
Sammle erfolglosen Kindprozess 0x5dbc339c62a0 PID 4115
make[1]: *** [Makefile:240: __sub-make] Fehler 2
Entferne Kindprozess 0x5dbc339c62a0 PID 4115 aus der Kette.
make[1]: Verzeichnis „/usr/src/linux-headers-6.9.1-x64v4-xanmod1“ wird verlassen
Sammle erfolglosen Kindprozess 0x60f156e031a0 PID 4114
make: *** [Makefile:30: default] Fehler 2
Entferne Kindprozess 0x60f156e031a0 PID 4114 aus der Kette.Hier die Ausgabe vom make-d mit dem Austausch der Verzeichnisse /scripts und /tools in den Headers vom Kernel 6.9.1
Ausgabe ist dann OK
root@BM2LTS-DD:/usr/src/vtuner-ng/kernel# make -d
GNU Make 4.3
Gebaut für x86_64-pc-linux-gnu
Copyright (C) 1988-2020 Free Software Foundation, Inc.
Lizenz GPLv3+: GNU GPL Version 3 oder später <http://gnu.org/licenses/gpl.html>
Dies ist freie Software: Sie können sie nach Belieben ändern und weiter verteilen.
Soweit es die Gesetze erlauben gibt es KEINE GARANTIE.
make-Steuerdateien werden gelesen …
„make“-Steuerdatei „Makefile“ wird gelesen...
make-Steuerdateien werden aktualisiert …
Betrachte Ziel-Datei „Makefile“.
Es wird nach einer impliziten Regel für „Makefile“ gesucht.
Muster-Regel mit Wurzel „Makefile“ wird probiert.
Implizite Voraussetzung „Makefile.o“ wird ausprobiert.
Muster-Regel mit Wurzel „Makefile“ wird probiert.
Implizite Voraussetzung „Makefile.c“ wird ausprobiert.
Muster-Regel mit Wurzel „Makefile“ wird probiert.
...
Die Datei „FORCE“ wurde bereits betrachtet.
Fertig mit den Voraussetzungen für die Ziel-Datei „/usr/src/vtuner-ng/kernel/vtunerc.mod.o“.
Das Target „/usr/src/vtuner-ng/kernel/vtunerc.mod.o“ muss neu erzeugt werden.
Nehme Kindprozess 0x5a9d7e9f96d0 (/usr/src/vtuner-ng/kernel/vtunerc.mod.o) PID 6129 in die Kette auf.
Aktiver Kindprozess 0x5a9d7e9f96d0 (/usr/src/vtuner-ng/kernel/vtunerc.mod.o) PID 6129
CC [M] /usr/src/vtuner-ng/kernel/vtunerc.mod.o
Sammle erfolgreichen Kindprozess 0x5a9d7e9f96d0 PID 6129
Entferne Kindprozess 0x5a9d7e9f96d0 PID 6129 aus der Kette.
Die Zieldatei „/usr/src/vtuner-ng/kernel/vtunerc.mod.o“ wurde erfolgreich aktualisiert.
Betrachte Ziel-Datei „FORCE“.
Die Datei „FORCE“ wurde bereits betrachtet.
Fertig mit den Voraussetzungen für die Ziel-Datei „/usr/src/vtuner-ng/kernel/vtunerc.ko“.
Das Target „/usr/src/vtuner-ng/kernel/vtunerc.ko“ muss neu erzeugt werden.
Nehme Kindprozess 0x5a9d7e9fc690 (/usr/src/vtuner-ng/kernel/vtunerc.ko) PID 6135 in die Kette auf.
Aktiver Kindprozess 0x5a9d7e9fc690 (/usr/src/vtuner-ng/kernel/vtunerc.ko) PID 6135
LD [M] /usr/src/vtuner-ng/kernel/vtunerc.ko
Sammle erfolgreichen Kindprozess 0x5a9d7e9fc690 PID 6135
Aktiver Kindprozess 0x5a9d7e9fc690 (/usr/src/vtuner-ng/kernel/vtunerc.ko) PID 6137
BTF [M] /usr/src/vtuner-ng/kernel/vtunerc.ko
Skipping BTF generation for /usr/src/vtuner-ng/kernel/vtunerc.ko due to unavailability of vmlinux
Sammle erfolgreichen Kindprozess 0x5a9d7e9fc690 PID 6137
Entferne Kindprozess 0x5a9d7e9fc690 PID 6137 aus der Kette.
Die Zieldatei „/usr/src/vtuner-ng/kernel/vtunerc.ko“ wurde erfolgreich aktualisiert.
Fertig mit den Voraussetzungen für die Ziel-Datei „__modfinal“.
Das Target „__modfinal“ muss neu erzeugt werden.
Die Zieldatei „__modfinal“ wurde erfolgreich aktualisiert.
Sammle erfolgreichen Kindprozess 0x63606ffbcd80 PID 6128
Entferne Kindprozess 0x63606ffbcd80 PID 6128 aus der Kette.
Die Zieldatei „modules“ wurde erfolgreich aktualisiert.
Sammle erfolgreichen Kindprozess 0x5b8a0fa572a0 PID 5838
Entferne Kindprozess 0x5b8a0fa572a0 PID 5838 aus der Kette.
Die Zieldatei „__sub-make“ wurde erfolgreich aktualisiert.
Fertig mit den Voraussetzungen für die Ziel-Datei „modules“.
Das Target „modules“ muss neu erzeugt werden.
Die Zieldatei „modules“ wurde erfolgreich aktualisiert.
make[1]: Verzeichnis „/usr/src/linux-headers-6.9.1-x64v4-xanmod1“ wird verlassen
Sammle erfolgreichen Kindprozess 0x56a95a9361a0 PID 5837
Entferne Kindprozess 0x56a95a9361a0 PID 5837 aus der Kette.
Die Zieldatei „default“ wurde erfolgreich aktualisiert.objtool taucht im unteren Log gar nicht auf.... Ist das für eine andere glibc kompiliert? Was meldet es, wenn man es am Prompt aufruft, z.B. mit -h?
Quoteobjtool taucht im unteren Log gar nicht auf.... Ist das für eine andere glibc kompiliert?
ich denke ja für GLIBC 2.35 -- das aktuelle aus den Headers vom Kernel 6.9.x mit GLIBC 2.38. Ein nachträgliches Installieren unter Ubuntu 22.04.4 von
GLIBC 2.38 brachte keine Hilfe.
Kernel 6.9.x
./objtool -h
./objtool: /usr/local/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by ./objtool)nach Austausch von Kernel 6.8.9
root@BM2LTS-DD:/usr/src/linux-headers-6.9.1-x64v4-xanmod1/tools/objtool# ./objtool -h
Usage: objtool <actions> [<options>] file.o
Actions:
-h, --hacks[=<jump_label,noinstr,skylake>]
patch toolchain bugs/limitations
-i, --ibt validate and annotate IBT
-l, --sls validate straight-line-speculation mitigations
-m, --mcount annotate mcount/fentry calls for ftrace
-n, --noinstr validate noinstr rules
-o, --orc generate ORC metadata
-r, --retpoline validate and annotate retpoline usage
-s, --stackval validate frame pointer rules
-t, --static-call annotate static calls
-u, --uaccess validate uaccess rules for SMAP
--cfi annotate kernel control flow integrity (kCFI) function preambles
--dump[=<orc>] dump metadata
--prefix <n> generate prefix symbols
--rethunk validate and annotate rethunk usage
--unret validate entry unret placement
Options:
-v, --verbose verbose warnings
--backtrace unwind on error
--backup create .orig files before modification
--dry-run don't write modifications
--link object is a linked object
--mnop nop out mcount call sites
--module object is part of a kernel module
--no-unreachable skip 'unreachable instruction' warnings
--sec-address print section addresses in warnings
--stats print statisticsDieser Austausch reicht aber noch nicht für die Erstellung - nur wenn /scripts noch getauscht wird
LD [M] /usr/src/vtuner-ng/kernel/vtunerc.o
MODPOST /usr/src/vtuner-ng/kernel/Module.symvers
scripts/mod/modpost: /usr/local/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by scripts/mod/modpost)
make[3]: *** [scripts/Makefile.modpost:145: /usr/src/vtuner-ng/kernel/Module.symvers] Fehler 1
make[2]: *** [/usr/src/linux-headers-6.9.1-x64v4-xanmod1/Makefile:2023: modpost] Fehler 2
make[1]: *** [Makefile:240: __sub-make] Fehler 2
make[1]: Verzeichnis „/usr/src/linux-headers-6.9.1-x64v4-xanmod1“ wird verlassen
make: *** [Makefile:30: default] Fehler 2... weil modpost auch gegen die neuere glibc gelinkt ist.
Ein nachträgliches Installieren unter Ubuntu 22.04.4 von GLIBC 2.38 brachte keine Hilfe.
Vermutlich weil es z.B. in /etc/ld.so.conf nicht/nicht richtig eingebunden ist. Aber da würde ich nix dran ändern, das sollte eine Distribution konfigurieren, auch für neuere Versionen von Libraries. Mit ldd ./objtool bekommst Du übrigens angezeigt welche Libs er lädt bzw. nicht findet.
... weil modpost auch gegen die neuere glibc gelinkt ist.
Vermutlich weil es z.B. in /etc/ld.so.conf nicht/nicht richtig eingebunden ist. Aber da würde ich nix dran ändern, das sollte eine Distribution konfigurieren, auch für neuere Versionen von Libraries. Mit ldd ./objtool bekommst Du übrigens angezeigt welche Libs er lädt bzw. nicht findet.
ok
ldd ./objtool
./objtool: /usr/local/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by ./objtool)
linux-vdso.so.1 (0x0000760aa8d9c000)
libelf.so.1 => /usr/local/lib/x86_64-linux-gnu/libelf.so.1 (0x0000760aa8d2f000)
libc.so.6 => /usr/local/lib/x86_64-linux-gnu/libc.so.6 (0x0000760aa8000000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x0000760aa8d13000)
/lib64/ld-linux-x86-64.so.2 (0x0000760aa8d9e000)Ich denke ich habe ein Lösung einfach den Kernel 6.9.x und höher z.B. unter Ubuntu 22.04.4 einfach selber erstellen und das passt es auch mit der GLIBC Version. Ich denke das man hierfür dann keine Änderung in vtuner-ng benötigt.
Aber wer z.B. die Kernel aus: https://kernel.ubuntu.com/mainline/?C=N;O=D
z.B. unter Ubuntu 22.04.4 nutzt ist mit dem Kernel 6.8.x ENDE, dann passt die GLIC Version am Kernel 6.9.x nicht mehr
Danke für die Hilfe hier
Heute morgen getestet Fedora 40 glibc 2.39 kam heute Morgen als Update GCC 14.1.1 Kernel noch 6.8.9 keinerlei Probleme bei Kompilieren! Bin gespannt wenn Fedora den 6.9.x frei gibt.
Hat jemand zufällig eine Kopie von der SatIP-Spezifikation? http://www.satip.info ist derzeit (22.05.2024) nicht erreichbar...
Also das aktuelle vtuner-ng package aus dem seahawk repository ist bezüglich der systemd scripts kaputt.
Ich hab das mal überarbeitet und den Inhalt des debian-Verzeichnis im Anhang bereitgestellt.
Es werden jetzt wieder zwei Packete gebaut vtuner-ng-dkms und vtuner-ng-satip wobei diese ihre zugehörigen systemd Komponenten enthalten.
Die Konfiguration findet im Verzeichnis /etc/vtuner-ng statt.
Steuerung mit systemctl start|stop|enable|disable vtuner-ng
Hier noch eine wichtige Verbesserung des systemd script zum vtunerc-ng service.
Der vdr service wurde insbesondere beim booten des linux manchmal zu früh gestartet und hat deshalb nicht alle devices verwendet.
Im vtuner-ng service wird jetzt gewartet bis alle vtunerc devices "used" sind (satip daemon connected).
Implementierung leider nicht per systemd event sondern sleep loop. Mir ist nichts besseres eingefallen 
Weiterhin wird der vdr service jetzt mit beendet wenn der vtuner-ng service beendet wird.
[Unit]
Description=vtuner-ng kernel module loader
Before=vdr.service
[Service]
Type=exec
EnvironmentFile=/etc/vtuner-ng/vtunerc.conf
ExecStart=/usr/sbin/modprobe vtunerc devices=${DEVICES} $OPTS
ExecStartPost=/bin/bash -c "while [ ! -e /proc/vtunerc$(($DEVICES - 1)) ] || grep -q -e 'vtunerc. used by : 0' /proc/vtunerc? ; do sleep 0.2; done"
ExecStop=/usr/sbin/modprobe -r vtunerc
RemainAfterExit=true
[Install]
RequiredBy=vdr.service
- Änderung in VDR, so dass nicht benötigte Devices mit cDvbTuner::CloseFrontend() geschlossen werden. Wenn sie wieder benötigt werden, werden sie mit cDvbTuner::OpenFrontend() wieder geöffnet.
- vtuner-ng gibt nur etwas frei, wenn VDR cDvbTuner::CloseFrontend() gerufen hat.
Hi,
ich habe dazu einen Patch für VDR geschrieben, s. [Patch] Frontends schließen, wenn tuner nicht verwendet
Bitte testen.
~ Markus
mit dem aktuellem Kernel 6.10 bekomme ich diesen Fehler beim erstellen des Treibers vom vtuner
You are using: gcc (Ubuntu 13.1.0-8ubuntu1~22.04) 13.1.0 CC [M] /usr/local/src/01-Master-BM2LTS/VDR/PLUGINS/vtuner-ng_v21/kernel/vtunerc_main.o
/usr/local/src/01-Master-BM2LTS/VDR/PLUGINS/vtuner-ng_v21/kernel/vtunerc_main.c: In function ‘vtunerc_init’:
/usr/local/src/01-Master-BM2LTS/VDR/PLUGINS/vtuner-ng_v21/kernel/vtunerc_main.c:606:28: error: implicit declaration of function ‘vmalloc’; did you mean ‘kvmalloc’? [-Werror=implicit-function-declaration] 606 | ctx->mem = vmalloc(DVR_BUFFER_SIZE); | ^~~~~~~ | kvmalloc
/usr/local/src/01-Master-BM2LTS/VDR/PLUGINS/vtuner-ng_v21/kernel/vtunerc_main.c:606:26: warning: assignment to ‘void *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion] 606 | ctx->mem = vmalloc(DVR_BUFFER_SIZE); | ^
/usr/local/src/01-Master-BM2LTS/VDR/PLUGINS/vtuner-ng_v21/kernel/vtunerc_main.c: In function ‘vtunerc_exit’:
/usr/local/src/01-Master-BM2LTS/VDR/PLUGINS/vtuner-ng_v21/kernel/vtunerc_main.c:731:17: error: implicit declaration of function ‘vfree’; did you mean ‘kvfree’? [-Werror=implicit-function-declaration] 731 | vfree(ctx->mem); | ^~~~~ | kvfree
cc1: some warnings being treated as errors
make[3]: *** [scripts/Makefile.build:244: /usr/local/src/01-Master-BM2LTS/VDR/PLUGINS/vtuner-ng_v21/kernel/vtunerc_main.o] Fehler 1
make[2]: *** [/usr/src/linux-headers-6.10.0-x64/Makefile:2087: /usr/local/src/01-Master-BM2LTS/VDR/PLUGINS/vtuner-ng_v21/kernel] Fehler 2
make[1]: *** [Makefile:240: __sub-make] Fehler 2
make[1]: Verzeichnis „/usr/src/linux-headers-6.10.0-x64“ wird verlassen
make: *** [Makefile:30: default] Fehler 2Ja "meine" Kernel-Freunde haben mal einfach vmalloc ersatzlos gestrichen und durch vmalloc_noprof ersetzt...
Lustigerweise gibt es einen Patch, der ist aber nirgendwo drin: https://lore.kernel.org/linux-…36-1-surenb@google.com/T/
Bitte mal den letzten GIT-Stand kompilieren versuchen...
Hm, das bedeutet man muß jeden folgende Unterversion von Kernel 6.10 neu patchen -> Hm also ca. jede Woche ?
Hm, das bedeutet man muß jeden folgende Unterversion von Kernel 6.10 neu patchen -> Hm also ca. jede Woche ?
Verstehe ich nicht.
Im vtuner hab ich das mal mit if LINUX_VERSION_CODE >= KERNEL_VERSION(6,10,0) eingetragen, d.h. gilt für größer gleich 6.10.0
Wenn jetzt irgendwer bei 6.10.x wieder auf die Idee kommt vmalloc als #define zu setzen muss eben ein >= und <= mit rein...
P.S.: Ob's jetzt kompiliert weiß ich von Dir aber immer noch nicht 
Don’t have an account yet? Register yourself now and be a part of our community!