Nichtübereinstimmung der Sublevel-Version beim Versuch, den aktuellen Kernel zu kompilieren

Nichtübereinstimmung der Sublevel-Version beim Versuch, den aktuellen Kernel zu kompilieren

Ich versuche, das sound/usbModul unter Ubuntu 18.10 mit dem laufenden Kernel neu zu kompilieren. Ich erhalte keine Kompilierungsfehler, aber wenn ich versuche, das Modul zu laden, erhalte ich diesen Fehler:

Invalid module format

Ich führe den 4.18.0-21-lowlatencyKernel aus.

So erhalte ich den Kernelquell

apt source linux

Dadurch wird die Quelle des 4.18.0Kernels heruntergeladen und in den linux-4.18.0Ordner extrahiert.

Ich kopiere die .configund Module.symversDateien in /lib/modules/4.18.0-21-lowlatency/builddas Stammverzeichnis meines Kernel-Quellverzeichnisses.

Ich laufe make EXTRAVERSION=-21-lowlatency modules_prepare, und dannmake EXTRAVERSION=-21-lowlatency M=sound/usb

Beim Ausführen insmodwird der folgende Fehler ausgegebensyslog

snd_usb_audio: version magic '4.18.20-21-lowlatency SMP preempt mod_unload ' should be '4.18.0-21-lowlatency SMP preempt mod_unload '

Das Ausführen modinfo /lib/modules/von uname -r /kernel/sound/usb/snd-usb-audio.ko | grep vermagicgibt Folgendes zurück

vermagic:       4.18.0-21-lowlatency SMP preempt mod_unload

Beim Ausführen modinfoauf meinem neu kompilierten Modul wird dies zurückgegeben

vermagic:       4.18.20-21-lowlatency SMP preempt mod_unload

Ich habe das Problem bis zu den ersten Zeilen desMakefile

VERSION = 4
PATCHLEVEL = 18
SUBLEVEL = 20

Wenn ich das SUBLEVELin ändere 0und dann kompiliere, kann ich das Modul erfolgreich laden.

Obwohl ich also den Kernel ausführe 4.18.0und apt source linuxder Kernel scheinbar heruntergeladen wird 4.18.0, sind die heruntergeladenen Dateien versioniert 4.18.20.

Ist das normal oder übersehe ich etwas?

Antwort1

Ich hatte ein ähnliches Problem. Das Problem liegt in der Methode, wie man die Kernel-Quelle erhält und wie man den Kernel „baut“. Es gibt einen Link zur offiziellen Vorgehensweise. Ich bin ihm vonhttps://help.ubuntu.com/community/Kernel/Compile. Es scheint veraltet und eine langwierige Lektüre zu sein.

Aufgrund der Situation möchte ich den offiziell veröffentlichten Ubuntu-Kernel verwenden (nicht von woanders).apt-get source xxxxx . Es ist ein Ordner mit Debian-Ordner und einem Tarball. Dann folge ich teilweise den Anweisungen vonVersuch, Kernel auf 18.04 zu erstellen. Keine Editconfigs-Option

  1. Kernelquellen herunterladen ( deb-srcsollten auskommentiert sein /etc/apt/sources.list)

    $ apt-get install linux-source kernel-package
    
  2. Gehen Sie zum Ordner mit den Kernelquellen und entpacken Sie ihn

    $ cd /usr/src/linux-source-x.x.x
    $ tar jxvf linux-source-x.x.x.tar.bz2
    
  3. Inhalt in den aktuellen Ordner verschieben
    $ mv linux-source-x.x.x/* .
    $ rm -rf linux-source-x.x.x/
    
  4. Holen Sie sich die erforderlichen Pakete
    $ apt-get build-dep linux-source
    $ mkdir debian/stamps
    

Dann kann ich fakeroot debian/rules cleanund ausführen fakeroot debian/rules binary-headers binary-generic binary-perarch. Zwischendrin muss ich manuell eine AMD-GPU-Headerdatei an den fehlenden Speicherort kopieren, sonst schlägt die Kompilierung fehl. Auf diese Weise wird fakeroot debian/rulesIhre laufende Kernelkonfiguration verwendet ( uname -r).

Wenn ich die make menuconfigure.config-Datei verwende, habe ich das gleiche Problem wie Sie. Sie können also mein Beispiel verwenden, um den offiziell veröffentlichten Ubuntu-Kernel zu verwenden und fakeroot debian/ruleszu kompilieren. Die Version des Moduls könnte übereinstimmen.

Meine Version ist Ubuntu 18.04 und meine uname -rist 5.3.0-51. Ich verwende apt-get, um den Quellcode um den 15.04.2020 abzurufen.

Ich glaube, es gibt andere Möglichkeiten, makeanstelle von zu verwenden fakeroot debian/rules, und es könnte hilfreich sein, In-Tree-Module zu erstellen.

verwandte Informationen